Public Web App Foundation Lab

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 is an Application Load Balancer?
• Target groups for Application Load Balancers
• Use Elastic Load Balancing with an Auto Scaling group
• Reliability pillar - AWS Well-Architected Framework