Public Web App On AWS — Quick Learn
An online store must run server-side code, read relational data, and accept file uploads. Traffic can spike, and one failed server or Availability Zone must not take down the application.
The tempting design—one public EC2 instance containing the application, database, uploads, sessions, and AWS keys—combines every responsibility into one failure boundary. Making that server larger delays failure; it does not remove the boundary.
The durable pattern is:
one public entrance → private replaceable compute → private durable state
Read The Architecture By Responsibility
- Route 53 answers DNS so the browser can find the public entry point. Request bytes do not pass through Route 53.
- An internet-facing Application Load Balancer (ALB) accepts HTTPS in public subnets. Its listener selects a target group—the set of application backends eligible for traffic—and forwards each request to a healthy instance.
- EC2 instances in an Auto Scaling group run the application in private subnets across multiple Availability Zones (AZs), which are isolated locations inside one Region.
- Amazon RDS keeps relational state in private database subnets. A Multi-AZ deployment maintains a synchronous standby in another AZ for managed database failover.
- Amazon S3 stores uploaded objects outside replaceable EC2 disks.
- An EC2 IAM role supplies rotating temporary credentials for AWS API calls instead of long-lived access keys on the server.
- Security groups admit only the required network path from one tier to the next.
A VPC is the application's regional private network. A subnet is public because its route table has a direct route to an internet gateway, not because of its name. Private application instances need no public IP: the public client connection ends at the ALB, and the ALB opens a separate VPC connection to a target's private IP.
One Request, End To End
Route 53 returns the ALB address
↓
Browser connects to the ALB over HTTPS
↓
Listener rule chooses the application target group
↓
ALB sends the request to one healthy private EC2 instance
↓
Application reads or writes through the RDS endpoint
↓
Response returns through the ALB
The database and file stores are not extra public entry points. The application security group accepts its port only from the ALB security group; the database security group accepts its port only from the application security group.
For a large upload, the application can authorize the user and create a short-lived S3 presigned URL for one object operation. The browser sends the file directly to S3 without receiving general AWS credentials. The URL is usable by whoever holds it until expiry, so keep its object key, action, and lifetime narrow.
Routing Around Failure Is Not Replacing Capacity
These related mechanisms have different jobs:
- A target fails the target group's health check.
- The ALB stops sending new requests to that target, preserving service through the remaining healthy capacity.
- When the Auto Scaling group uses the relevant load-balancer health signal, it launches a replacement from a launch template, the configuration describing new instances.
- The replacement enters service only after it passes health checks.
- Separately, a scaling policy raises or lowers desired capacity when demand changes.
Selecting subnets in two AZs does not create resilience by itself. Healthy instances and enough remaining capacity must actually run across those AZs.
Read deeper into ALB health checks, launch templates, and Auto ScalingReplaceable Compute Cannot Own Durable State
If one user uploads a file to instance A and the next request reaches instance B, local-only storage loses the shared view. In-memory sessions create the same coupling. Durable relational data belongs in RDS; durable objects belong in S3; shared sessions require an appropriate external store.
This is what stateless application tier means here: an EC2 instance is not the only durable owner of information a future request needs. It can be replaced without losing the application's source of truth.
RDS Multi-AZ protects database availability, but it does not replace backups. A destructive write can replicate to the standby. Backups and point-in-time recovery preserve historical states for a different failure.
Keep Identity, Reachability, And Direction Separate
An IAM role answers, “Which AWS API actions may this application perform?” A security group answers, “Which network connections may reach this resource?” Permission does not create a route, and a route does not grant permission.
If private EC2 instances need public package repositories or third-party APIs, a NAT gateway can carry connections they initiate. NAT is outbound egress, not the user's inbound path. Traffic to supported services such as S3 or DynamoDB can instead use gateway VPC endpoints when appropriate.
Read deeper into inbound ALB traffic versus outbound NAT accessSAA Recognition And Traps
- Highly available dynamic web application → ALB + Auto Scaling capacity across multiple AZs, because routing and replacement handle different parts of an instance failure.
- Only the load balancer should be public → internet-facing ALB in public subnets; EC2 and RDS in private tiers.
- EC2 needs AWS API access without stored keys → an instance role through an instance profile, because the SDK can obtain temporary credentials.
- Automatic relational database failover → RDS Multi-AZ. A classic read replica is primarily a separate read-scaling target.
- Uploads must survive instance replacement → S3, because replaceable compute must not hold the only durable copy.
- Private instances need general internet egress → NAT gateway; do not place NAT in the inbound user path.
Do not confuse Route 53 with an HTTP proxy, an ALB with a capacity-replacement service, Multi-AZ with backup history, or private placement with automatic authorization.
One-Minute Review
Public HTTPS → ALB
Healthy dynamic compute → private EC2 across AZs
Routing around failure → ALB health checks
Replacing and scaling compute → Auto Scaling
Relational state → private RDS Multi-AZ + separate backups
Object state → S3
AWS permissions → IAM role
Tier reachability → security groups
Private outbound Internet → NAT, only when needed
If you remember only one thing: keep one public entrance, make private compute replaceable, and move durable state outside the instances.