Key features
- Choose the geographic region your services will deploy to.
- Configurable release grades geared toward cost-performance in development and performance and observability in production.
- Dual-stack VPC that communicates over both IPv6 and IPv4, making environments future-proof and more cost-efficient than IPv4 VPCs.
- Best practices for subnet configuration and selection, CIDR block allocation.
- Choose your own network security posture balancing cost-savings against layered security.
- Use cheaper NAT instances in development and staging environments, highly available managed NAT gateways in production
- 1-Click ECS cluster, service discovery, and service RBAC.
- Easy to import and extend with CDK and Terraform
How it works
FlexStack environments are created for scale. Regardless of your target availability or release grade, we make sure that your VPC is ready to adapt at any time.
For example, if you create an environment with 99% availability we will still opt to provision subnets into 3 availability zones on your behalf should you decided later that you need 99.9%. In spite of the extra zones, we will only provision your resources into a single AZ in the case of a 99% availability target - saving you the initial expense while preparing you for growth and change.
Creating an environment always creates the following resources:
- Dual-stack VPC
- Public subnet in 3 availability zones with a 2048 IPv4 address range per availability zone
- Private subnet with egress in 3 availability zones with a 8192 IPv4 address range per availability zone
- Private isolated subnet in 3 availability zones with a 1024 IPv4 address range per availability zone
- Internet gateway
- Egress-only internet gateway used by IPv6 traffic, bypassing any NAT gateways and therefore saving on processing fees.
- S3 gateway endpoint
- DynamoDB gateway endpoint
- Elastic container service cluster
When using "enhanced" network security, an environment creates:
- One AWS managed NAT gateway per availability zone in production environments
- OR an IPv6-capable NAT instance in one availability zone in development/staging environments
When using a "high traffic" web service:
CIDR block selection
FlexStack environment CIDR blocks are identifiable by region and their original release grade which makes environments easily identifiable and debuggable at scale, for example when you have several environments spanning multiple regions.
When originally deployed to production grade:
Region | CIDR Block |
---|---|
us-west-2 | 10.10.0.0/16 |
us-east-1 | 10.11.0.0/16 |
us-east-2 | 10.12.0.0/16 |
eu-central-1 | 10.13.0.0/16 |
eu-west-1 | 10.14.0.0/16 |
eu-west-2 | 10.15.0.0/16 |
eu-west-3 | 10.16.0.0/16 |
ca-central-1 | 10.17.0.0/16 |
ap-northeast-1 | 10.18.0.0/16 |
ap-south-1 | 10.19.0.0/16 |
ap-southeast-1 | 10.20.0.0/16 |
ap-southeast-2 | 10.21.0.0/16 |
When originally deployed to staging grade:
Region | CIDR Block |
---|---|
us-west-2 | 172.20.0.0/16 |
us-east-1 | 172.21.0.0/16 |
us-east-2 | 172.22.0.0/16 |
eu-central-1 | 172.23.0.0/16 |
eu-west-1 | 172.24.0.0/16 |
eu-west-2 | 172.25.0.0/16 |
eu-west-3 | 172.26.0.0/16 |
ca-central-1 | 172.27.0.0/16 |
ap-northeast-1 | 172.28.0.0/16 |
ap-south-1 | 172.29.0.0/16 |
ap-southeast-1 | 172.30.0.0/16 |
ap-southeast-2 | 172.31.0.0/16 |
When originally deployed to development grade:
Region | CIDR Block |
---|---|
us-west-2 | 192.168.0.0/16 |
us-east-1 | 192.168.0.0/16 |
us-east-2 | 192.168.0.0/16 |
eu-central-1 | 192.168.0.0/16 |
eu-west-1 | 192.168.0.0/16 |
eu-west-2 | 192.168.0.0/16 |
eu-west-3 | 192.168.0.0/16 |
ca-central-1 | 192.168.0.0/16 |
ap-northeast-1 | 192.168.0.0/16 |
ap-south-1 | 192.168.0.0/16 |
ap-southeast-1 | 192.168.0.0/16 |
ap-southeast-2 | 192.168.0.0/16 |
CIDR ranges by subnet
At scale, most IP addresses will be in private subnets, so we bias CIDR blocks to reserve more space in the private subnets than in public ones. We intentionally leave 31,744 addresses available for additional subnets you may want to create in the future.
The ranges for each subnet type are as follows:
Subnet name | CIDR range | Addresses per AZ |
---|---|---|
Public | x.x.x.x/20 | 2048 |
Private w/ egress | x.x.x.x/19 | 8192 |
Private isolated | x.x.x.x/22 | 1024 |
Create an environment
Selecting a region
The first step in creating an environment is selecting an appropriate AWS region. Regions are geographical locations around the world where your network resources will reside. FlexStack supports multiple regions, selected based on criteria that ensure optimal performance, disaster recovery capabilities, and service availability that allows FlexStack to perform its magic.
Choose the region that best suits your needs based on the location of your users, legal requirements, or other criteria important to your organization. It is generally considered good practice to distribute environments (development, staging, production) across different regions.
It is important to note, however, that region selection has cost implications. If you are in or near the US, we strongly recommend us-west-2
, us-east-2
, and us-east-1
in that order, considering price, latencies, and wear of hardware. That's why we default to us-west-2
.
Selecting a release grade
Selecting the appropriate release grade in FlexStack is crucial for aligning your deployment with operational priorities, budget constraints, and the lifecycle phase of your application. FlexStack categorizes deployments into three release grades: Development, Staging, and Production. Each grade is tailored to different stages of application development and deployment, affecting cost, resource scaling, monitoring, and operational features.
Overview of Release Grades
- Development: Optimized for early-stage application development and testing. This grade focuses on cost efficiency by deploying cheaper resource alternatives and does not enable autoscaling. Log retention, metric reporting, and alert thresholds are configured with development and cost-saving in mind, making it ideal for non-critical, experimental, or development workloads. Environments created with this grade will also tend to deploy much faster than Staging and Production grades, optimizing the development feedback loop.
- Staging: Serves as an intermediate step between development and production. Staging environments mirror production settings but are scaled down to manage costs. Autoscaling may be limited or disabled, but log retention, metric reporting, and alert thresholds are closer to production standards. This grade is suitable for pre-production testing, load testing, and quality assurance processes, ensuring applications behave as expected in a production-like environment.
- Production: Designed for live applications requiring high availability, performance, and scalability. Production-grade environments enable autoscaling, ensuring services can respond dynamically to workload changes. They feature extended default log retention periods, frequent metric reporting, and sensitive alert thresholds to maintain performance and reliability. This grade incurs the highest cost due to its use of robust, scalable resources and enhanced monitoring capabilities.
Choosing the right release grade
When deciding on a release grade, consider the following:
- Application Lifecycle Stage: Select a grade that matches the current phase of your application, from development and testing (Development Grade) to final pre-production checks (Staging Grade) and live operation (Production Grade).
- Cost vs. Performance: Balance the need for a cost-effective environment for testing and development against the performance and reliability required for your live application.
- Operational Requirements: Consider the level of monitoring, log retention, and alerting necessary for your application at each stage. Development environments may require less intensive monitoring compared to staging and production, which need closer oversight to ensure they perform as expected under real-world conditions.
Don't ruminate too much on this selection. You can change the Release Grade in your environment dashboard at a later date if your needs change.
Selecting target availability
Target availability is critical for planning the deployment and operational phases of your services. It refers to the desired uptime and reliability of your services, often expressed as a percentage (e.g., 99.9% uptime, or three-nines).
Considerations
- Analyze Requirements: Consider the criticality of your service. How much downtime can you afford without significant impact?
- Understand the Implications: Higher availability often requires more complex and costly solutions. For example, a service running in
us-west-2a
that accesses data in a service running inus-west-2b
incurs a data transfer fee of $0.01/GB, while there is no data transfer fee for communication between services within the same availability zone. Thus, if you run all of your services in the same availability zone (as is the case with the two-nines target) you will not incur data transfer fees. Many businesses are surprised when they see these charges showing up on their bill, so we thought it was important to call it out specifically. - Set the Target: Based on your analysis, set a realistic target availability for each service. Include this in your service level agreements (SLAs).
It's possible, if not likely, that you'll find a target availability of 99% to deliver >99% availability . These numbers are by no means guarantees, they are primarily guides to architecting for reliability. You should always align technical requirements with business expectations, ensuring that your infrastructure meets the needs of your users.
In general, we recommend a selection of 99% for Development and Staging grade environments and 99.9% for Production grade environments, though 99% is also suitable for many production environments, especially in the early stages of a product.
Connecting your AWS account
Follow our Deploy on FlexStack article for a step-by-step guide to connecting your FlexStack environments to AWS. If you run into any issues, our support team is here to help.
Enhanced network security
Because it is secure, affordable, and more simple, FlexStack deploys your on public subnets by default. This is a suitable, reasonable option for almost all applications. If we detect that you are using a number of public IP addresses that exceeds the likely cost of a NAT gateway provider, we will automatically move you to the enhanced network security option unless you've specifically chosen the "basic" option.
For some production use cases where security and isolation are paramount, FlexStack provides the flexibility to deploy services exclusively on private subnets. This option is integrated seamlessly, ensuring that sensitive workloads are protected without sacrificing the ease of use and cost-efficiency that FlexStack promises. By supporting both public and private subnet deployments, FlexStack caters to a wide range of security requirements, offering organizations the ability to tailor their infrastructure to specific needs while maintaining a strong security posture.
To enable enhanced security, open your environment's configuration page and turn on the "enhanced security" switch.
In Production environments, the enhanced security option incurs a fee of $0.045 per hour and $0.045 per gigabyte processed through its NAT gateway, per each availability zone in your target availability (1 for 99%, 2 for 99.9%, 3 for 99.99%).
In Development and Staging environments, the enhanced security option uses a t4g.nano
NAT instance in one availability zone instead of the more expensive NAT gateway.
CloudFormation exports
The CloudFormation stack created for environments contains many useful exports that can be imported by other stacks you create, for example if you use CDK or CloudFormation to supplement your FlexStack usage.
Export pattern | Description |
---|---|
AvailabilityZone:[AZ]:[ENVIRONMENT_ID] | Each availability zone the environment VPC is attached to |
CloudMapNamespaceARN:[ENVIRONMENT_ID] | The ARN of the default Cloud Map namespace created for the environment. |
CloudMapNamespaceID:[ENVIRONMENT_ID] | The ID of the Cloud Map namespace created for the environment. |
CloudMapNamespaceName:[ENVIRONMENT_ID] | The name of the Cloud Map namespace created for the environment (flexstack.internal) |
ClusterARN:[ENVIRONMENT_ID] | The ARN of the ECS cluster created for the environment. |
ClusterName:[ENVIRONMENT_ID] | The name of the ECS cluster created for the environment. |
DatabaseSecurityGroupID:[ENVIRONMENT_ID] | The ID of a security group that can be used to give this environment's services access to RDS databases. |
EnvironmentSecurityGroupID:[ENVIRONMENT_ID] | The ID of the security group that allows this environment's services to communicate with each other. |
PrivateIsolatedSubnetIPv4CIDR:[AZ]:[ENVIRONMENT_ID] | The CIDR range for the private isolated subnet in each availability zone. |
PrivateWithEgressSubnetIPv4CIDR:[AZ]:[ENVIRONMENT_ID] | The CIDR range for the private with egress subnet in each availability zone. |
PublicSubnetIPv4CIDR:[AZ]:[ENVIRONMENT_ID] | The CIDR range for the public subnet in each availability zone. |
VPCARN:[ENVIRONMENT_ID] | The ARN of the VPC created for this environment. |
VPCCIDRBlock:[ENVIRONMENT_ID] | The CIDR block created for the VPC in this environment. |
VPCDefaultSecurityGroupID:[ENVIRONMENT_ID] | The ID of the default security group for the VPC. |
VPCID:[ENVIRONMENT_ID] | The ID of the VPC created for this environment. |
VPCIPv6CIDRBlock:0:[ENVIRONMENT_ID] | The IPv6 CIDR block created for this VPC. |
If the environment contains an Application Load Balancer, these exports will be present:
Export pattern | Description |
---|---|
LoadBalancerARN:[ENVIRONMENT_ID] | The ARN of the load balancer created for this environment. |
LoadBalancerDNSName:[ENVIRONMENT_ID] | The DNS name of the load balancer created for this environment. |
LoadBalancerCanonicalHostedZoneID:[ENVIRONMENT_ID] | The canonical hosted zone ID of the load balancer created for this environment. |
LoadBalancerSecurityGroupID:[ENVIRONMENT_ID] | The security group ID of the load balancer created for this environment. |
LoadBalancerHTTPListenerARN:[ENVIRONMENT_ID] | The ARN of the HTTP listener attached to the load balancer. |
LoadBalancerHTTPSListenerARN | The ARN of the HTTPS listener attached to the load balancer if you have custom domain names in use. |