Q292: AWS Frontend Architecture CloudFront S3 Lambda and Edge Tradeoffs

What Interviewers Want To Evaluate

Interviewers want to know whether you can explain cloud architecture in frontend terms.

They are checking static hosting, CDN behavior, serverless APIs, edge compute, object storage, routing, security headers, invalidation, cost, and operational trade-offs.

Short Interview Answer

An AWS frontend architecture often uses S3 for static assets, CloudFront for CDN delivery, Route 53 for DNS, ACM for TLS, Lambda or API Gateway for backend-for-frontend APIs, and edge functions for lightweight request logic. The design must define cache rules, invalidation strategy, origin security, environment variables, logging, deployment automation, and what belongs at the edge versus regional serverless compute.

Detailed Interview Answer

AWS is not one product.

It is a set of building blocks.

For frontend systems, the common pieces are:

Route 53
ACM
CloudFront
S3
Lambda
API Gateway
Lambda@Edge or CloudFront Functions
CloudWatch
WAF
IAM
Secrets Manager

A good answer connects each service to a product responsibility.

Static Site Delivery

Static assets can be stored in S3.

Examples:

HTML
CSS
JavaScript bundles
images
fonts
PDF exports
manifest files

CloudFront sits in front of S3 to cache assets globally.

The browser should not usually access the S3 bucket directly.

CDN Responsibilities

CloudFront can handle:

global caching
TLS termination
compression
HTTP/2 and HTTP/3
origin routing
cache key control
header forwarding
geographic distribution
basic request normalization
security headers

The biggest design decision is the cache key.

If the cache key includes too many headers or cookies, cache hit rate drops.

If it includes too little, users may receive incorrect content.

Cache Rules

Typical rules:

hashed JS/CSS assets -> cache for a long time
HTML routes -> short cache or revalidation
API responses -> cache only when safe
private responses -> no shared CDN cache
images -> long cache with versioned URLs

Cache invalidation is useful, but versioned assets are usually better for predictable frontend releases.

Serverless APIs

API Gateway plus Lambda can support backend-for-frontend endpoints.

Examples:

save progress
generate PDF
validate code execution request
fetch signed upload URL
aggregate profile data
proxy a private provider API

Lambda is useful for event-driven or request-driven work, but cold starts, execution limits, and observability must be considered.

Edge Compute

CloudFront Functions and Lambda@Edge can run logic near the user.

Good edge use cases:

redirects
header normalization
security headers
A/B routing
locale routing
bot filtering hints
lightweight auth checks

Poor edge use cases:

heavy database work
large dependency bundles
long-running processing
complex business workflows
secret-heavy integrations

Edge compute is powerful, but it should stay small and deterministic.

Origin Security

S3 origins should be private when possible.

CloudFront can use origin access controls so users cannot bypass the CDN.

This matters because bypassing CloudFront can skip:

security headers
WAF checks
cache behavior
logging
rate limits
TLS policy

IAM and Secrets

IAM should grant only the permissions needed.

Frontend build systems often need permission to:

upload assets
invalidate CloudFront
write deployment metadata
read selected configuration

Runtime Lambdas may need different permissions.

Secrets should live in a secret manager or deployment platform, not in source control or browser bundles.

Observability

Cloud architecture needs logs and metrics.

Track:

CloudFront cache hit rate
origin error rate
Lambda errors
Lambda duration
API Gateway latency
WAF blocked requests
deployment version
region-level anomalies
cost spikes

Frontend metrics should connect back to cloud metrics.

If LCP regresses, check asset size, CDN cache misses, origin latency, and image delivery.

Cost Trade-offs

AWS frontend costs may come from:

data transfer
CloudFront requests
Lambda invocations
API Gateway calls
CloudWatch logs
WAF rules
invalidations
image transformations

More caching usually lowers origin cost, but unsafe caching creates correctness bugs.

Interview Framing

Say:

I would start with user-facing routes and freshness needs, then choose static hosting, CDN caching, serverless APIs, and edge logic per route.

Then mention:

I would keep private data and secrets out of the browser bundle and design cache keys carefully so CloudFront improves performance without leaking user-specific content.

Common Mistakes

• Making S3 public when CloudFront should be the entry point.
• Treating every route as cacheable.
• Putting heavy business logic at the edge.
• Forgetting cache key correctness.
• Forgetting source maps and deployment identifiers.
• Ignoring CloudWatch cost and log volume.
• Exposing private environment variables to client code.

Learning Studio Example

Learning Studio could map like this:

static handbook pages -> CDN cached
hashed assets -> long-lived CloudFront cache
PDF exports -> generated and stored as objects
practice transpile API -> serverless endpoint
future logged-in progress -> authenticated API
security headers -> CDN or app layer

The important part is not naming AWS services.

The important part is explaining ownership, cache safety, and failure recovery.

Final Mental Model

AWS frontend architecture is a placement problem.

Place static assets in object storage, global delivery at the CDN, lightweight request logic at the edge, private workflows in serverless or regional services, and secrets outside the browser.