Tracing One Request Through Every Layer

Step 1 — DNS resolution: the browser looks up the domain via Route 53, which returns an Alias record resolving to the CloudFront distribution's address (not a raw IP, since Alias records track CloudFront's actual current endpoints automatically).

Step 2 — CDN edge: the request arrives at the nearest CloudFront edge location. If it matches a cached, still-valid static asset (an image, a JS bundle), CloudFront returns it immediately — the request never travels any further, and the origin infrastructure never even sees it. If it's a dynamic API request (a cache behavior configured for no/minimal caching), CloudFront forwards it toward the origin.

Step 3 — Load balancing: the request reaches the Application Load Balancer, which terminates SSL (using an ACM certificate) and, based on the configured listener rules, routes it to the appropriate target group.

Step 4 — Compute: the target group forwards the request to one of the healthy EC2 instances in the Auto Scaling Group (only instances currently passing the target group's health check receive traffic). That instance's application code processes the request.

Step 5 — Data access: the application queries RDS for structured data (using credentials retrieved from Secrets Manager at instance startup, cached in memory, not re-fetched on every single query) and, if the request involves a file, either reads it from S3 directly or issues a pre-signed URL for the client to fetch it directly.

Step 6 — Response: the response travels back through the same chain — EC2 to ALB to CloudFront (which may cache it if the cache behavior allows) to the user's browser — completing the round trip.