Deploying & Debugging a Full-Stack App on AWS

The plain-language idea

A real full-stack app on AWS isn't one service — it's every piece from this track, each doing the one job it's actually good at:

1. S3 + CloudFront serve the built frontend — content-hashed assets cached long, index.html invalidated on deploy.
2. ECS/Fargate (or Lambda, depending on the API's shape) runs the backend, in a private subnet — never directly internet-reachable.
3. RDS or DynamoDB holds the data, in an even more restricted private subnet, reachable only from the backend's own security group.
4. IAM roles, not hardcoded keys, give each piece exactly the permissions it needs and nothing more.
5. CI/CD authenticates via OIDC, builds once, and promotes the same artifact through environments.
6. CloudWatch alarms watch the metrics that matter, ready to catch a problem before a user reports it.
7. Cost reasoning from the previous lesson governs which compute and capacity choices were made in the first place.

See it in a real thing: "the site is down," start to finish

CloudWatch: is there an active alarm, and what does it name — frontend, API, or database?

BackNext

A user reports the app is unreachable. The check, in the order this track built the pieces:

1. CloudWatch — is there an active alarm? What does it name — the frontend, the API, the database?
2. Compute — if it's the API: is the ECS service's task count where it should be, or did tasks fail their health check and get replaced repeatedly (a crash loop)?
3. Networking — if tasks are healthy but still unreachable: is the load balancer's security group actually allowing traffic in, and does its target group point at the right port?
4. IAM — if the API is up but erroring: does its execution role actually have permission for whatever it just tried to do (a common cause of a sudden new error after weeks of working — a permission was never wrong, something the code does changed)?
5. Storage/database — if the API can't reach RDS or DynamoDB: is the database's security group still scoped to allow the API's security group specifically?

What people usually miss

Watch out

• The order of the checklist matters — start from what CloudWatch already knows, not from guessing. An alarm firing already narrows "the whole app is down" to a specific component; starting there is faster than checking all five layers from scratch every time.
• A single piece being healthy doesn't mean the request path through it is healthy. The API can be running perfectly and still be unreachable if the networking layer in front of it is misconfigured — each layer has to be checked, not just the one that seems most likely to be broken.
• A cost anomaly is itself a debugging signal, not just a billing concern. An unexpected spike in Lambda invocations or data transfer is very often the first observable sign of the same retry loop or misconfiguration a functional bug report would eventually surface — the cost lesson's billing alarms and the monitoring lesson's CloudWatch alarms are watching for overlapping symptoms of the same underlying problems.
• "It worked yesterday" is a real, useful clue, not a dismissal. Something in the environment changed — a deploy, an IAM policy edit, an expired certificate, a dependency's new version — and the debugging job is finding what changed, not re-verifying architecture that was already working.

Why this matters in interviews

A systems-design or debugging round that hands over "the app is down, what do you check" is testing exactly this synthesis — not one fact in isolation, but whether a candidate can move through a real infrastructure stack in a sane order, using specific, checkable signals at each layer instead of guessing. That's the arc of this whole track: from IAM's single permission model in lesson one to this five-layer checklist, spanning everything in between.