SkarpSkarp

Chapter 21 of 26

End-to-End Design Workshop: Secure and Resilient Web Application on AWS

Bring together everything you’ve learned by designing a full-stack web application that is secure, resilient, high-performing, and cost-aware. This module walks through a realistic scenario from requirements to architecture diagram, mirroring how exam questions are framed.

27 min readen

Scenario Setup and Well-Architected Lens

Your Design Scenario

You are designing a two-tier web app on AWS: EC2-based web front end, relational database back end, and global users accessing `https://app.example.com` with static assets that must load quickly.

Business and Technical Needs

Requirements: handle traffic spikes, survive an AZ outage, protect sensitive data, and stay within a tight budget. You must balance security, reliability, performance, and cost.

Well-Architected Framework

The AWS Well-Architected Framework provides a consistent set of best practices and questions to evaluate how well an architecture is aligned to AWS best practices.

Key Pillars in Focus

We emphasize four pillars: Security, Reliability, Performance efficiency, and Cost optimization. We also keep the Sustainability pillar in mind as a secondary lens.

Exam Mindset

On the exam, scenarios look like this. Practice mapping each design choice to the pillar it primarily improves and understanding the trade-offs with other pillars.

Step 1: High-Level Architecture and Shared Responsibility

High-Level Pattern

We use a common exam pattern: Route 53 + CloudFront + ALB (public), EC2 Auto Scaling in private subnets (app), and RDS + S3 in private/data layer.

Traffic Flow Overview

Visualize the path: User → Route 53 → CloudFront → ALB → EC2 app instances → RDS database and S3 buckets for static files and uploads.

Shared Responsibility Model

The AWS shared responsibility model describes how AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including the configuration of their services and data.

AWS vs You

AWS secures facilities, hardware, and managed service infrastructure. You secure VPC design, SGs, IAM, app code, and encryption settings for your data.

Common Exam Trap

If a question asks who patches the EC2 guest OS or configures security groups, the answer is you, not AWS. AWS handles only the underlying infrastructure.

Step 2: VPC, Subnets, and Network-Level Security

VPC Structure

Create one VPC (e.g., 10.0.0.0/16) with at least two AZs. Use public subnets for ALB and NAT, private app subnets for EC2, and private DB subnets for RDS.

Public and Private Subnets

Public subnets route to an Internet Gateway. Private app subnets use NAT gateways for outbound internet. Private DB subnets have no direct internet route.

Security Groups Basics

Security groups are stateful, attached to ENIs, and usually use allow-list rules. Return traffic is automatically allowed if the request was permitted.

NACLs Basics

Network ACLs are stateless, attached to subnets, and require explicit rules for both directions. They are not your first tool for tier isolation.

Tier-to-Tier Protection

Use SG references: ALB SG allows 443 from internet, app SG allows inbound only from ALB SG, DB SG allows inbound only from app SG on the DB port.

Step 3: Security Groups – A Concrete Rule Set

ALB Security Group

sg-alb: allow inbound TCP 443 from 0.0.0.0/0, and allow outbound traffic to the app SG on the app port (e.g., 80 or 8080).

App Security Group

sg-app: allow inbound only from sg-alb on the app port, optional SSH from a trusted source, and outbound to sg-db on 3306 plus HTTPS to AWS APIs.

DB Security Group

sg-db: allow inbound on the DB port (e.g., 3306) only from sg-app, with outbound using default or tightened rules as needed.

Security and Reliability Impact

This SG chain enforces least privilege, hides EC2 and RDS from the internet, and supports both the Security and Reliability pillars.

Exam Pattern

When asked how to restrict DB access to app servers, choose SG rules that reference the app SG rather than broad CIDR ranges.

Step 4: IAM Roles and Data Protection (At Rest and In Transit)

IAM Roles for EC2

Assign an EC2 instance role so the app can access S3, CloudWatch Logs, and Secrets Manager without embedding long-lived access keys.

Least Privilege in IAM

Grant only needed actions such as s3:GetObject or logs:PutLogEvents, avoiding wildcard permissions that break the Security pillar.

Encryption at Rest

Enable KMS-based encryption for RDS, default encryption for S3 buckets, and EBS volume encryption for EC2 to protect stored data.

Encryption in Transit

Use HTTPS from users to CloudFront, from CloudFront to ALB, and ideally from ALB to EC2; manage TLS certs via AWS Certificate Manager.

Secrets Handling

Avoid hardcoding passwords in code or user data. Store secrets in Secrets Manager or Parameter Store and access them via IAM roles.

Step 5: Multi-AZ, ALB, and Auto Scaling for Resilience

RDS Multi-AZ

Enable RDS Multi-AZ so your DB has a synchronous standby in another AZ and can automatically fail over during an AZ outage.

Role of the ALB

Use an internet-facing ALB in public subnets to distribute traffic across EC2 instances in multiple AZs and to perform health checks.

Auto Scaling Group Basics

Create an ASG across private app subnets, with min=2, desired=2, max>2, and attach it to the ALB target group for resilience and elasticity.

Scaling Policies

Configure scaling on metrics like average CPU or requests per target so instances are added during spikes and removed when demand drops.

Common Exam Trade-off

Multiple smaller instances across AZs plus ALB and ASG usually beats one big instance for both reliability and performance efficiency.

Step 6: Route 53, CloudFront, and Global Performance

Route 53 Role

Use Route 53 with a public hosted zone for example.com and create an A/AAAA alias record for app.example.com pointing to the CloudFront distribution.

CloudFront as CDN

CloudFront caches content at edge locations worldwide, improving latency and offloading traffic from your ALB and S3 origins.

Origins and Behaviors

Use S3 as the origin for static paths like /static/* with long TTLs, and ALB as the origin for dynamic paths with shorter cache lifetimes.

Securing S3 Origins

Restrict S3 bucket access so only CloudFront can read objects, using Origin Access Control or an Origin Access Identity.

Exam Angle

When you see requirements for global performance and added DDoS protection, CloudFront in front of S3 or ALB is often the correct choice.

Step 7: Cost-Aware Choices and Trade-Offs Across Pillars

Cost-Aware EC2 and RDS

Right-size EC2 instances, use Auto Scaling to match demand, choose appropriate RDS instance and storage types, and consider long-term discounts.

Data Transfer Economics

CloudFront can reduce expensive data transfer out from the Region; watch inter-AZ charges from ALB to EC2 and RDS Multi-AZ replication.

Trade-Off: RDS Multi-AZ

Multi-AZ improves Reliability through failover but increases cost; exam answers often favor Multi-AZ when availability is a key requirement.

Trade-Off: Using CloudFront

CloudFront boosts performance and resilience but adds CDN charges; it is usually justified when you have global users or heavy static content.

Balancing Pillars

Read exam questions for hints about which pillar dominates: security, reliability, performance efficiency, or cost optimization, then choose accordingly.

Step 8: Design Walkthrough – Build the Diagram in Your Head

Use this guided thought exercise to mentally assemble the full architecture. Do this slowly; being able to “see” the design is powerful for the exam.

Activity: Layer-by-Layer Build

  1. Start with the Region and AZs
  • Imagine one AWS Region with two Availability Zones, A and B.
  • Sketch (mentally or on paper) two columns: AZ A on the left, AZ B on the right.
  1. Add the VPC and Subnets
  • Draw a big box around both AZs labelled “VPC 10.0.0.0/16”.
  • In each AZ, draw three sub-boxes:
  • Top: Public subnet (ALB + NAT).
  • Middle: Private app subnet (EC2 ASG).
  • Bottom: Private DB subnet (RDS).
  1. Place Core Resources
  • In public subnets: ALB nodes and NAT gateways.
  • In private app subnets: EC2 instances (ASG) in both AZs.
  • In private DB subnets: RDS Multi-AZ instance (primary in AZ A, standby in AZ B, for example).
  1. Add Edge and DNS
  • Outside the VPC, at the top, draw CloudFront.
  • Above that, draw Route 53 pointing to the CloudFront distribution.
  • Off to the side, draw an S3 bucket as another origin for CloudFront.
  1. Add Security Layers
  • Label SGs: sg-alb, sg-app, sg-db.
  • Draw arrows showing allowed flows: internet → sg-alb → sg-app → sg-db.
  1. Reflect
  • Which components directly face the internet?
  • Which components are Multi-AZ?
  • Where does encryption at rest and in transit apply?

Pause here and, if you can, quickly sketch this on a notepad. This is almost exactly the kind of diagram you’ll need to reason about on the Solutions Architect - Associate exam.

Quiz 1: Security and Network Design

Test your understanding of security groups, subnets, and encryption choices in this architecture.

You are designing the database tier for this application. Which option best restricts access to the RDS instance while supporting a Multi-AZ, highly available design?

  1. Place RDS in public subnets with a security group that allows inbound MySQL from 0.0.0.0/0 so all app servers can connect.
  2. Place RDS in private DB subnets across two AZs with a security group that allows inbound MySQL only from the app servers' security group.
  3. Place RDS in private app subnets and use a NACL to block all inbound traffic except MySQL from 0.0.0.0/0.
  4. Place RDS in a single private subnet with a security group that allows inbound MySQL from the ALB security group.
Show Answer

Answer: B) Place RDS in private DB subnets across two AZs with a security group that allows inbound MySQL only from the app servers' security group.

The best option is to place RDS in dedicated private DB subnets across two AZs (for Multi-AZ) and use a DB security group that allows inbound on the DB port only from the app tier security group. This enforces least privilege and keeps the DB isolated from the internet. Public subnets or 0.0.0.0/0 access violate the Security pillar, and a single subnet design reduces reliability.

Quiz 2: Route 53, CloudFront, and Cost Trade-Offs

Check how well you understand DNS, CDN, and cost-aware decisions.

Your app serves mostly static images and JavaScript to users worldwide. The CTO wants lower latency and reduced load on the origin while staying cost-aware. Which design best meets these goals?

  1. Point a Route 53 A record directly to the ALB and increase the EC2 instance sizes to handle more traffic.
  2. Place CloudFront in front of the ALB and S3, configure cache behaviors for static content, and point a Route 53 alias record to the CloudFront distribution.
  3. Host the static site directly from an S3 website endpoint and create a Route 53 record pointing to the bucket URL.
  4. Create a second ALB in another Region and use Route 53 weighted routing between the two ALBs.
Show Answer

Answer: B) Place CloudFront in front of the ALB and S3, configure cache behaviors for static content, and point a Route 53 alias record to the CloudFront distribution.

Using CloudFront in front of the ALB and S3, with Route 53 aliasing to the CloudFront distribution, caches static content at edge locations. This reduces origin load and improves latency for global users. It aligns with the Performance efficiency and Cost optimization pillars better than simply scaling EC2 or duplicating ALBs without a CDN.

Key Term Review: Architecture and Well-Architected Pillars

Flip through these cards to reinforce core concepts and definitions you will see on the exam.

AWS Well-Architected Framework
The AWS Well-Architected Framework provides a consistent set of best practices for customers and partners to evaluate architectures, and a set of questions you can use to evaluate how well an architecture is aligned to AWS best practices.
Security pillar
The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture.
Reliability pillar
The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle.
Performance efficiency pillar
The performance efficiency pillar focuses on the efficient use of computing resources to meet requirements and maintain that efficiency as demand changes and technologies evolve.
Cost optimization pillar
The cost optimization pillar includes the continual process of refinement and improvement of a system over its entire lifecycle to build and operate cost-aware systems that achieve business outcomes and minimize costs.
Sustainability pillar
The sustainability pillar focuses on minimizing the environmental impacts of running cloud workloads by maximizing utilization and minimizing the resources required, and by reducing the energy required to deliver business value.
shared responsibility model
The AWS shared responsibility model describes how AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including the configuration of their services and data.
Multi-AZ RDS
A deployment option where RDS maintains a synchronous standby in a different Availability Zone, providing automatic failover and improved availability at a higher cost.
Application Load Balancer (ALB)
A Layer 7 load balancer that distributes HTTP/HTTPS traffic across multiple targets (such as EC2 instances) in one or more Availability Zones and supports advanced routing and health checks.
EC2 Auto Scaling Group
A group of EC2 instances managed together, which can scale the number of instances in or out automatically based on policies, health checks, and schedules.
Amazon CloudFront
A global content delivery network service that caches content at edge locations to reduce latency and offload traffic from your origins such as S3 or ALB.

Step 9: Mini Design Challenge – Adjust for a New Requirement

Apply what you have learned by adapting the architecture to a new constraint.

New Requirement

Your startup now faces a stricter budget. Management says:

  • “We can tolerate a few minutes of downtime if an AZ fails, but we must reduce monthly costs.”

Using only mental reasoning (no console), answer these questions for yourself:

  1. RDS Design Change
  • Would you keep RDS Multi-AZ, or switch to Single-AZ with regular automated backups and cross-AZ read replicas?
  • Which option better balances the Reliability and Cost optimization pillars under the new requirement?
  1. Auto Scaling Settings
  • Could you lower the minimum number of EC2 instances from 2 to 1 outside business hours using scheduled scaling?
  • How does that affect cost vs resilience?
  1. CloudFront and S3
  • If most users are in one geographic region, would you still keep CloudFront, or serve directly from ALB and S3?
  • What performance and cost changes would you expect?
  1. Your Recommendation
  • Write down (mentally or on paper) one change you would definitely make, and one you would not make because the risk to reliability or security is too high.

Compare your reasoning with the pillars: did you explicitly think about Security, Reliability, Performance efficiency, Cost optimization, and even Sustainability when proposing changes?

In the Skarp path, your next mock exam will surface where these trade-off decisions are still fuzzy. The gap guide after that attempt will dive deeper into the specific domain (like Design Resilient Architectures) where you struggled.

Key Terms

VPC
Amazon Virtual Private Cloud, a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network you define.
IAM role
An AWS Identity and Access Management entity that defines a set of permissions and can be assumed by trusted entities such as AWS services or users.
Multi-AZ
A deployment pattern where resources such as RDS instances or ALBs span multiple Availability Zones to improve availability and fault tolerance.
Amazon S3
Amazon Simple Storage Service, an object storage service offering scalability, data availability, security, and performance.
Amazon RDS
Amazon Relational Database Service, a managed service that makes it easier to set up, operate, and scale a relational database in the cloud.
Network ACL
A stateless, subnet-level firewall that controls inbound and outbound traffic using ordered allow and deny rules.
Security group
A stateful virtual firewall attached to network interfaces that controls inbound and outbound traffic for AWS resources like EC2, ALB, and RDS.
Amazon Route 53
A highly available and scalable Domain Name System (DNS) web service used for domain registration, DNS routing, and health checking.
Security pillar
The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture.
Amazon CloudFront
A content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency.
Auto Scaling group
A logical group of EC2 instances that can automatically scale capacity based on demand, health checks, and schedules.
Reliability pillar
The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle.
Sustainability pillar
The sustainability pillar focuses on minimizing the environmental impacts of running cloud workloads by maximizing utilization and minimizing the resources required, and by reducing the energy required to deliver business value.
Cost optimization pillar
The cost optimization pillar includes the continual process of refinement and improvement of a system over its entire lifecycle to build and operate cost-aware systems that achieve business outcomes and minimize costs.
Application Load Balancer
An Elastic Load Balancing option operating at Layer 7 that routes HTTP/HTTPS traffic across targets in one or more Availability Zones.
shared responsibility model
The AWS shared responsibility model describes how AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including the configuration of their services and data.
Performance efficiency pillar
The performance efficiency pillar focuses on the efficient use of computing resources to meet requirements and maintain that efficiency as demand changes and technologies evolve.
AWS Well-Architected Framework
The AWS Well-Architected Framework provides a consistent set of best practices for customers and partners to evaluate architectures, and a set of questions you can use to evaluate how well an architecture is aligned to AWS best practices.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself