Building blocks
Design goal
Remove single-instance dependencies and keep application and database tiers private while the workload remains available through routine infrastructure failure.
Architecture
An internet-facing load balancer distributes traffic across application instances in multiple AZs; the database uses managed resilience appropriate to the chosen engine and deployment option.
Architecture decisions
Scale stateless compute horizontally
WhyKeep session/state outside individual application instances where possible.
Trade-offStateless compute makes replacement and scaling easier, but sessions and durable state must move into external services that are resilient themselves.
Separate public ingress from private application tiers
WhyExpose only the load-balancing layer and keep application/database tiers private.
Trade-offPrivate tiers reduce exposure, but introduce load-balancing, NAT/endpoint, DNS, and troubleshooting dependencies.
Security
Protect the control and data paths deliberately. Use security groups by tier, WAF where required, IAM roles, encrypted storage, secrets management, and centralized logging.
Availability
Design for the failure domain that must be survived. Distribute load balancer targets across AZs and use Auto Scaling health replacement. Choose the appropriate RDS high-availability option for the workload.
Disaster recovery
Treat regional recovery as a separate operating state. Regional DR is a separate design decision; use backups, replicas, or secondary-region infrastructure according to RPO/RTO.
Cost drivers
- EC2 instance hours
- ALB LCUs
- RDS engine/size/storage
- NAT Gateway
- data transfer
- WAF/logging
Design assumptions
- Application can run on multiple instances
- State is externalized or replicated
- Database requirements are defined
Implementation plan
- Create public ingress and private application/data subnets across at least two Availability Zones in the workload VPC.
- Place the Application Load Balancer on the public ingress path and keep application instances or tasks on private subnets.
- Configure Auto Scaling with a minimum healthy footprint across Availability Zones and health checks that can replace failed application capacity.
- Deploy the database privately using the high-availability option appropriate to the selected engine and recovery objectives.
- Apply tier-specific security groups, IAM roles, secrets handling, and centralized telemetry, then test instance and Availability Zone failure.
Validate the design
- Terminate an application instance and confirm healthy capacity is replaced without user-visible loss of service.
- Generate traffic across the load balancer and verify requests are distributed across the intended Availability Zones.
- Perform a controlled database failover and measure application reconnection behavior.
- Attempt direct access to private application/database tiers and confirm the security-group and routing boundaries block it.