AWS Labs
Public Web App Foundation Lab
Design a public AWS web application foundation with VPC subnets, Application Load Balancer, Auto Scaling, RDS Multi-AZ, CloudFront, WAF, observability, and cost controls.
After this, you will understand
This lab turns a familiar public web app into a structured AWS architecture decision exercise instead of a pile of service names.
Design the edge, load balancer, compute tier, database tier, security boundaries, alarms, and cost controls for a basic production web app.
Learners put everything in public subnets, skip health checks, confuse scaling with failover, or add expensive global patterns before the requirement needs them.
Draw the request path first, then decide which subnet, security group, scaling, failover, and monitoring control belongs at each hop.
Think before readingWhat is the main design habit this lab is practicing?
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 public and private subnet placement
- Application Load Balancer routing and health checks
- Auto Scaling group integration
- RDS Multi-AZ database resilience
- CloudFront and WAF edge protection
- Security group boundaries
- CloudWatch alarms and logs
- Cost and overbuild review
- SAA-C03 design reasoning
1. Lab Goal
Design a production-ready baseline for a public web application on AWS.
The goal is not to click through every console screen. The goal is to practice the architecture decisions that matter before anyone opens the console:
internet user -> edge -> load balancer -> application tier -> database tier
By the end, you should be able to explain where the public boundary is, where private compute belongs, how health checks affect traffic, why the database needs Multi-AZ for availability, what CloudFront and WAF add, and which cost controls prevent a small app from becoming unnecessarily expensive.
2. Scenario Brief
A small SaaS team is launching a public web application. Users access the app over HTTPS. The app has a web/API tier and a relational database.
The team expects moderate traffic at launch but wants room for bursts. The app should remain available if one application instance fails. The database should tolerate an Availability Zone failure. Security wants the database isolated from the internet. The business wants a practical architecture, not a huge Multi-Region design on day one.
Your task is to create an architecture plan, not a production migration runbook.
3. Architecture Decision Targets
Decide these items before implementation:
- VPC layout: at least two Availability Zones, public subnets for internet-facing load balancer components, private subnets for application instances, and isolated/private database subnets.
- Entry point: HTTPS through an Application Load Balancer, with ACM-managed certificates when using a real domain.
- Compute tier: Auto Scaling group using launch templates and health checks.
- Database tier: RDS with Multi-AZ for managed failover.
- Edge layer: CloudFront when global caching, TLS edge termination, or WAF-at-edge patterns are useful.
- Security layer: security groups that allow only necessary traffic between tiers.
- Operations layer: CloudWatch alarms for target health, request errors, latency, CPU, database metrics, and log volume.
Write down the reason for each decision. If you cannot explain the reason, the service choice is probably memorized rather than understood.
4. Design Constraints
Use these constraints:
- The application must be reachable from the public internet.
- Application instances should not be directly reachable from the internet.
- The database must not be public.
- The design should tolerate one application instance failure.
- The database should tolerate an Availability Zone failure.
- The design should avoid unnecessary Multi-Region complexity.
- The team wants useful monitoring without turning logs into a surprise cost center.
These constraints deliberately mix security, resilience, performance, and cost. That is why this is a lab and not only a service note.
5. Guided Build Plan
Start with the network sketch.
Create a VPC with at least two Availability Zones. Place public subnets in each AZ for the load balancer path. Place private application subnets in each AZ for EC2 instances. Place database subnets where the RDS subnet group can span AZs.
Next, place the entry point. Use an Application Load Balancer for HTTP/HTTPS routing. The ALB sends requests to a target group. The target group health check decides which instances are eligible to receive traffic.
Then place the application tier. Use an Auto Scaling group with instances in private subnets. Attach the Auto Scaling group to the ALB target group so instances are registered and deregistered as capacity changes.
Then place the database tier. Use RDS Multi-AZ when the requirement is managed database availability across AZ failure. Do not use read replicas as the primary answer for failover.
Finally, decide whether CloudFront belongs in front. If users are global, static content is cacheable, WAF should sit closer to the edge, or origin load should be reduced, CloudFront is a strong addition. If this is a small internal beta in one geography, document why ALB-only may be enough for now.
6. Security Review
Use security groups as tier boundaries.
The ALB security group allows inbound HTTPS from the internet. The application security group allows inbound traffic only from the ALB security group on the application port. The database security group allows inbound database traffic only from the application security group.
Use IAM roles for instances instead of long-lived credentials. Store secrets in Secrets Manager or another approved secret system rather than putting passwords in user data, AMIs, or source code.
Use AWS WAF when the requirement mentions protection from common web exploits such as SQL injection or cross-site scripting against supported web entry points. WAF is not a replacement for security groups, IAM, or application validation.
7. Resilience Review
The ALB should span multiple Availability Zones. The Auto Scaling group should have capacity across at least two AZs. Target group health checks should detect unhealthy instances and remove them from rotation.
RDS Multi-AZ addresses database availability and failover. It is not the same as a read replica. Backups and point-in-time recovery protect against data loss and accidental change, but they do not provide the same user-facing failover behavior as Multi-AZ.
Document the expected failure behavior:
- one application instance fails: ALB routes around it after health checks fail
- one AZ loses app capacity: Auto Scaling and ALB continue in remaining healthy AZs if capacity exists
- primary database AZ fails: RDS Multi-AZ performs managed failover
- bad deployment breaks all instances: Auto Scaling alone does not fix bad code
8. Performance Review
The ALB distributes traffic across healthy targets. Auto Scaling responds to demand using metrics such as CPU, request count per target, or application-specific indicators.
CloudFront can reduce latency and origin load for cacheable content. It does not make uncached database-heavy requests magically cheap or fast.
If database reads become the bottleneck, consider query tuning, indexes, caching, or read replicas depending on freshness requirements. Do not add read replicas just because the phrase "high availability" appears.
9. Cost Review
Cost comes from load balancer usage, EC2 capacity, RDS instance size and Multi-AZ storage/standby behavior, NAT Gateways if used, CloudFront requests and transfer, WAF rules, logs, metrics, and backups.
For a baseline app, avoid overbuilding active-active Multi-Region unless the RTO/RPO and business criticality require it.
Right-size the initial instance choices. Add Auto Scaling policies that match traffic. Set log retention deliberately. Use budgets or cost alerts for learning accounts.
10. Validation Checklist
Before calling the design complete, answer:
- Can users reach the app over HTTPS?
- Are application instances private?
- Is the database private?
- Does each tier allow only the previous tier that needs access?
- What happens when one instance fails?
- What happens when one AZ has no healthy app targets?
- What happens when the primary database AZ fails?
- Which metrics show bad deployment, overload, high latency, and database pressure?
- Which parts of the design are optional for day one?
11. Exam Connections
SAA-C03 will often turn this lab into service comparisons.
"Public web app with HTTP routing" points to ALB, not NLB, unless the requirement is layer 4, extreme TCP/UDP, static IP style, or other NLB-specific behavior.
"Automatic database failover across AZs" points to RDS Multi-AZ, not read replicas.
"Protect a public web app from common web attacks" points to AWS WAF on a supported endpoint.
"Serve global static content with lower origin load" points to CloudFront.
"Private instances need software updates" might introduce NAT Gateway, VPC endpoints, Systems Manager, or image baking depending on the exact wording.
12. Cleanup And Next Steps
If you implement this in a real AWS account, delete unused load balancers, NAT Gateways, EC2 instances, RDS databases, snapshots, WAF web ACLs, and CloudWatch log groups when finished. NAT Gateways and RDS are common sources of accidental lab cost.
Next, review Private S3 Access Lab, Public Web App On AWS, and CloudFront WAF Protected Web Edge.
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.