AWS Scenarios
Public Web App On AWS
Design a highly available public web application using VPC subnets, an Application Load Balancer, Auto Scaling, EC2, RDS, S3, IAM, and monitoring.
After this, you will understand
This is the base AWS architecture pattern behind many SAA-C03 questions: public entry, private compute, managed database, and health-based scaling.
Put the load balancer in public subnets, keep app servers and databases private, and spread everything important across Availability Zones.
Learners put one public EC2 instance and one public database on the internet because it feels like normal hosting.
Separate public ingress from private workload execution, then add Auto Scaling, Multi-AZ database placement, least privilege, and monitoring.
Think before readingWhat should be internet-facing in a basic EC2-based public web app?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Public web application architecture
- VPC subnet tiers
- Internet-facing Application Load Balancer
- EC2 Auto Scaling group
- Private application subnets
- RDS Multi-AZ database
- S3 for durable objects
- Security group chaining
- Health checks and replacement
- SAA-C03 web app variants
1. Situation
You need to host a public web application on AWS.
The application receives HTTP and HTTPS traffic from users, runs server-side application code, stores relational data, and accepts user-uploaded files. It should tolerate an Availability Zone failure, scale with traffic, avoid exposing the database to the internet, and avoid storing AWS credentials on servers.
This is one of the most important AWS scenario patterns because it combines foundations, services, and exam wording:
users -> public entry point -> private compute -> private database
The exact services can vary. The app tier might use EC2, ECS, Elastic Beanstalk, or another compute service. This scenario uses EC2 because it exposes the core architecture decisions clearly: VPC, subnets, security groups, load balancing, Auto Scaling, IAM roles, RDS, and S3.
2. Naive Design
The naive design is one public EC2 instance:
internet -> public EC2 instance -> local app and database
The EC2 instance has a public IP address. The app, uploaded files, and database all run on the same machine. SSH is open for administration. The server has AWS access keys stored on disk so it can write files to S3 or call other AWS APIs.
This design feels simple because it resembles a traditional small VPS deployment. It may even work for a demo.
But it is a poor AWS production pattern. It makes the server the public entry point, app tier, storage tier, database tier, deployment target, and failure boundary at the same time.
3. What Breaks
The first problem is availability. If the instance fails, the application fails. If the Availability Zone has an issue, the application fails. If the instance is replaced during patching, deployment, or scaling, the app may go down.
The second problem is security. The database is too close to the public internet. SSH may be exposed. Application credentials and AWS access keys can leak. There is no clean separation between user traffic, application traffic, database traffic, and administrative access.
The third problem is scaling. A single server can only grow vertically for so long. If traffic spikes, you cannot add capacity cleanly. If you manually add a second instance, local files and sessions become inconsistent.
The fourth problem is operations. Health checks, replacement, monitoring, backups, logs, and deployments all require custom work. The architecture does not use AWS-managed control points where they matter.
4. AWS Architecture
A healthier first AWS architecture looks like this:
Route 53
-> internet-facing Application Load Balancer in public subnets
-> EC2 Auto Scaling group in private app subnets
-> RDS Multi-AZ database in private database subnets
-> S3 bucket for uploaded objects and static assets
Create a VPC across at least two Availability Zones. In each AZ, create public subnets for the load balancer and NAT gateways, private app subnets for EC2 instances, and private database subnets for RDS.
The Application Load Balancer is the public entry point. It terminates HTTPS or forwards HTTPS depending on the design, performs health checks, and routes only to healthy app targets.
The Auto Scaling group launches EC2 instances from a launch template across private subnets. Instances receive an IAM role through an instance profile. They do not store access keys.
RDS stores relational data. Use Multi-AZ when high availability is required. Store uploaded objects in S3, not on instance disks.
5. Request Or Data Flow
A user resolves the application domain through Route 53. The DNS record points to the Application Load Balancer.
The user sends HTTPS traffic to the load balancer. The ALB listener routes the request to a target group. The target group health checks decide which EC2 instances should receive traffic.
The EC2 instance processes the request. If it needs relational data, it connects to the RDS endpoint through a database security group rule that allows traffic only from the application security group.
If the user uploads a file, the application writes the object to S3 using the instance role. For larger or direct uploads, the application can issue pre-signed URLs so the browser uploads to S3 without sending the entire object through the app server.
Logs and metrics flow to CloudWatch or another monitoring system. CloudTrail records AWS API activity. Auto Scaling replaces unhealthy instances and adjusts capacity based on policy.
6. Security Controls
Use security group chaining:
- ALB security group allows HTTPS from the internet.
- App security group allows inbound app traffic only from the ALB security group.
- Database security group allows database traffic only from the app security group.
Do not make the RDS database publicly accessible. Do not place the database in public subnets for a normal web application.
Attach an IAM role to EC2 instances for AWS API calls. Scope permissions to the specific S3 bucket, KMS key, log group, or parameter path the app needs.
Store secrets in AWS Secrets Manager or Systems Manager Parameter Store. Avoid secrets in AMIs, user data, or source code.
Use TLS for public traffic. Encrypt RDS and S3 data where required. Use S3 Block Public Access unless the bucket is intentionally public, which is rare for application uploads.
7. Resilience Controls
Spread the load balancer and app tier across multiple Availability Zones. Enable at least two AZs for the ALB and Auto Scaling group.
Use health checks. ALB target group health checks route traffic away from unhealthy instances. Auto Scaling health checks can replace failed instances.
Use RDS Multi-AZ for database high availability. This is not read scaling; it is failover support.
Keep app instances stateless when possible. Store durable data in RDS, S3, DynamoDB, EFS, or another managed service rather than on local instance disks.
Use backups and point-in-time recovery for RDS. Use versioning and lifecycle policy for important S3 data when the requirement calls for accidental deletion protection.
8. Performance Controls
Scale the app tier horizontally with Auto Scaling. Choose metrics that match load, such as request count per target, CPU, queue depth, or custom application metrics.
Use CloudFront in front of the ALB or S3 when global users need lower latency or static content caching.
Move uploaded objects and static assets to S3 and CloudFront so EC2 instances do not waste capacity serving large files.
Tune RDS with indexes, connection pooling, instance sizing, and read replicas when read traffic is the bottleneck.
Use ElastiCache when repeated reads or session state need low-latency caching, but do not use it as the only copy of important durable data.
9. Cost Controls
Auto Scaling reduces overprovisioning, but it must have sensible minimum, desired, and maximum capacity.
Use Savings Plans or Reserved Instances for predictable EC2 and RDS usage. Use On-Demand for flexibility and Spot only for interruptible app components that can tolerate replacement.
Watch NAT gateway cost. Private instances that only need S3 or DynamoDB can often use gateway VPC endpoints instead of routing all traffic through NAT.
Use S3 lifecycle rules for old uploads, logs, and backups. Right-size RDS and EC2 instances rather than scaling blindly.
CloudFront can reduce origin load and improve latency, but it adds its own cost model.
10. Exam Variants
"Highly available web application" usually means ALB plus targets across multiple AZs, Auto Scaling, and a managed database with Multi-AZ.
"Database must not be publicly accessible" points to private database subnets and security groups.
"Application instances need S3 access without credentials on disk" points to an EC2 IAM role.
"Scale based on demand" points to Auto Scaling and load balancing.
"Global users need lower latency for static content" adds CloudFront.
"Least operational overhead" may shift compute from EC2 to Elastic Beanstalk, ECS Fargate, App Runner, or serverless options depending on wording.
11. Common Traps
Do not make EC2 instances public just because the application is public. The load balancer can be public while compute stays private.
Do not put RDS in public subnets for normal app access.
Do not store user uploads on local instance storage.
Do not place AWS access keys on EC2. Use an instance role.
Do not choose read replicas when the requirement is automatic database failover. Use Multi-AZ.
Do not forget health checks. A load balancer without meaningful health checks can route to broken instances.
12. Related Topics
Review Public vs Private Subnets, Security Groups vs NACLs, Amazon EC2, Amazon RDS, and Application Load Balancer vs Network Load Balancer vs Gateway Load Balancer.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.