Deployment, Cost Awareness, and Resource Cleanup

Module 11 covered CloudFormation's Parameters, Resources, and Outputs, along with the update process, in depth — this lesson applies that same workflow to the capstone as a whole rather than re-teaching it. This capstone's S3 bucket, CloudFront distribution, API Gateway, Lambda functions, DynamoDB table, and SQS queue are all expressed as Resources in a template (conceptually — no real credentials or a runnable stack are part of this course), so the entire architecture can be reproduced or updated by deploying that template rather than by clicking through the console by hand.

Requirement: this architecture should be reproducible, and changes to it should be reviewable before they reach a real environment. Decision: define it in a CloudFormation template, kept in version control, validated and change-previewed before any stack update. Reason: this catches a mistaken or unintended change before it reaches production, and lets the whole environment be torn down and rebuilt reliably. Alternative: create and modify all these resources by hand through the AWS Console. Trade-off: writing and maintaining a template is more upfront work than clicking through a console — accepted here because reproducibility and reviewability matter more for this application than initial convenience.

Every meaningful cost in this architecture traces back to a specific requirement — the useful discipline is asking, for any line item, which architectural requirement is causing this cost?, not simply "how do we make this cheaper."

• Lambda invocations and duration trace back to the requirement to handle API traffic without maintaining always-on servers — cost scales with actual usage rather than being fixed regardless of traffic.
• DynamoDB read/write capacity traces back to the requirement to serve progress and certificate lookups at low, predictable latency as learners grow.
• CloudFront data transfer and requests trace back to the requirement to serve the frontend quickly and globally over HTTPS.
• SQS and the certificate worker's compute trace back to the requirement that certificate generation not block the learner's request.
• CloudWatch and CloudTrail trace back to the requirement to detect problems before learners report them, and to audit changes after the fact.

No dollar figures are quoted here — actual AWS pricing changes over time and by Region, and this course teaches the reasoning, not a memorized price sheet. The reasoning itself is durable: every cost should be traceable to a requirement, and a cost that can't be traced to any requirement is a candidate for removal.

Tearing this capstone's resources down safely means respecting dependency order and never assuming deletion is harmless. A practical, non-destructive sequence: first confirm nothing still depends on the stack (no other environment pointing at this DynamoDB table or this API's endpoint); back up or export any data worth keeping — this DynamoDB table may hold learner progress and certificate records that shouldn't simply vanish; then delete the CloudFormation stack, letting it remove its own resources in the correct dependency order (CloudFront distributions in particular can take time to fully disable before deletion, and generally must be disabled before they can be removed); then confirm afterward that no orphaned resources — an S3 bucket, a leftover queue — were left outside the stack's own management.

This course does not execute any destructive script against a real environment, and neither should a capstone submission without first warning whoever owns the data about exactly what's about to be deleted.