Cost Review and Final Production Architecture

Concept

You have built a complete production system. This last lesson does two things that every engineer does at the end of a build: count the cost and review the whole design. They are one job. In the cloud, the bill is a description of your design, line by line. Every hour a server runs, every gigabyte of logs and every idle IP address appears on it.

Do not treat cost as something to fix in a hurry at the end. Treat it as a property of the design, like latency. Measure it, set a budget for it and review it.

The five ways AWS charges you

Almost every line on the invoice follows one of five patterns. If you know the pattern, you can guess the cost of a service you have never used:

The main idea: AWS bills for existing, not for using. A server with zero visitors costs the same as a busy one. This is the big difference from the per-request pricing of Lesson 0. It is also why forgotten resources are the biggest source of waste.

What the final architecture costs

Here is an honest total for three sizes of the same design. The prices are for the Mumbai Region, on-demand, running 24 hours a day. They are estimates for planning, not quotes. Prices change and traffic varies. The AWS Pricing Calculator (a free AWS web tool where you enter your resources and get a monthly price) gives a more exact number for any line.

• Compare with Lesson 0. It said “$15 to $25” for one small server plus one small database. That counted only the server and the database. The Starter column also adds the disk, the IP address, logging and backups that a real deployment needs. It is still small. The build now happens in CI (Lesson 14), so a t3.micro server is enough to run the app.
• The big step is the load balancer tier. Going from Starter to Production roughly triples the bill. Servers are not the reason. Each new part (load balancer, second server, cache, security services) has a fixed monthly charge. This is the moment to ask honestly whether you need it yet (the warning from Lesson 12).
• Costs that depend on usage stay small at this scale. Requests, CDN traffic and log volume matter much more once you have thousands of daily users.
• Compare with the alternative. A platform (Vercel Pro, Railway, Render) often costs $20–100 a month for a project of this size once you add a database. That price also includes the operations work. So do not compare AWS line items with platform line items only. Compare the AWS line items plus your time (see the honest verdict below).

The cost levers, ranked by payoff

A cost lever is one change that lowers the bill. Work down this list in order. The top items have no risk. The bottom ones need care. Most bills drop 30–50% after the first five.

Right-sizing with evidence

Right-sizing means moving each server to the smallest size that still copes. Compute Optimizer is a free AWS service that does this analysis for you. You opt in, and it needs at least 30 hours of CloudWatch metrics from the last 14 days. Then it marks each instance as over-provisioned (too big), optimized (about right) or under-provisioned (too small), and suggests a size. You can also check by hand: look at two weeks of daily average and maximum CPU for the Auto Scaling group in CloudWatch. An average of 8% and a maximum of 30% means a smaller size is safe.

Watch memory as well as CPU (you get memory numbers from the agent in Lesson 17). CPU alone can mislead you. An app that needs a lot of memory but little CPU should move to a type with a better memory-to-CPU ratio, not to a smaller one.

Data transfer: the most overlooked cost

You cannot avoid all of these costs, but you can see them. In Cost Explorer (the AWS tool that charts your spending), filter by a usage type that contains DataTransferto find the cause.

Savings Plans and Reserved Instances

On-demand pricing is the highest price. You pay it because you promise nothing. If you know a resource will run for a year anyway, you can promise that and get a discount. A Savings Plan is a promise to spend a fixed amount per hour for 1 or 3 years. A Reserved Instance (RI) is a promise to run one specific instance type for 1 or 3 years. In both cases AWS gives you a lower price in return:

Seeing the bill: tags, Cost Explorer, budgets, anomalies

You cannot manage a cost if you cannot tell what caused it. Four tools help, in order of value:

1. Tag everything — Terraform did most of it already

   A tag is a label (a key and a value) that you attach to a resource. The default_tags block from Lesson 15 already puts Project, Environment and ManagedBy on every resource. One more step makes them useful: activate them as cost allocation tags in Billing → Cost allocation tags. They show up in reports about a day later, and only for costs after you activate them. Then the bill splits by project and environment.

2. Cost Explorer — read it weekly at first

   Cost Explorer is the AWS tool that charts your spending over time. Group by Service first. Then open the biggest one and group by Usage type. Switch to daily view to find the day the cost jumped. Then match that day to a deploy or a change.

3. Budgets — the smoke detector

   A budget is a limit you set for your spending. AWS sends an alert when you get near it. Lesson 5 set one budget for the whole account. Now make one for the project, with alerts at 50%, 80% and 100% of actual spending and at 100% of forecast. The forecast alert fires early, when AWS predicts that you will go over the limit, not after you have.

   Billing → Budgets → Create: monthly cost budget for myapp, with email alerts to the team address at 80% of actual and 100% of forecast.

4. Cost Anomaly Detection — the tripwire

   Cost Anomaly Detection is a free AWS feature that learns your normal spending for each service and alerts you when it sees something unusual. Examples are a runaway log group, or a crypto-miner running in a Region you never use. Create a monitor for all services in Billing → Cost Anomaly Detection. Send the alert to the same SNS topic (a messaging channel that can email you) as your operational alarms. It would have caught most of the costly mistakes described in Lesson 5 within a day.

Unit economics: what does one customer cost?

A multi-tenant SaaS is one software service (SaaS means software sold as a service) that many customers, called tenants, share. For this kind of product, the total bill is not the most useful number. The useful number is cost per tenant, because you compare it with what each tenant pays you. This is called unit economics: the cost and income of one unit, here one customer.

Monthly infrastructure (Production column)        ≈ $130
Active tenants                                    40
Fixed cost per tenant                             130 / 40 = $3.25

Add per-tenant variable costs:
  S3 storage (avg 2 GB × $0.025)                  $0.05
  Data out via CloudFront (avg 5 GB × $0.11)      $0.55      (after free tier)
  Email, SMS, third-party APIs                    $0.40
  Support and your time are NOT here yet.

≈ $4.25 per tenant per month.   Price of a plan: $29   →   ~85% gross margin on infrastructure

The exact numbers do not matter. What matters is that you can now answer two questions. The first is “what happens when we have 400 tenants?” The fixed part barely moves, while storage and transfer grow. The second is “which customers lose us money?” One example is a customer who stores 500 GB of video on a $29 plan. Use tenant names in S3 key prefixes and tenant IDs in logs (Lessons 11 and 17) to measure real storage and traffic for each tenant. Then set plan limits that protect your margin. (Gross margin is the share of the price left after the direct costs.)

The orphan sweep: finding what you forgot

An orphan is a resource that nothing uses any more but that still bills you. Everything you create keeps billing until you delete it. A sweep every three months pays for itself. Check these:

The final architecture, box by box

Here is everything the series built, in one place. First you see the path a user's request takes. Then you see the network it runs in. Then you see the path a code change takes to get there.

Here is the same system as a table. It shows what each piece does, what breaks when it fails (the question that shows whether you really understand it) and what it costs:

Single points of failure left in this design

A single point of failure is one part that, if it breaks, stops the whole system. An honest review lists them, so you can decide what to spend money on next:

• The database is single-AZ. It runs in one Availability Zone only. If that zone fails, you must restore from a backup, and that takes time. Fix: Multi-AZ, which keeps a standby copy in a second zone (it doubles the RDS line).
• One Region. If a whole Region fails, you are down. Fix: keep backup copies in another Region (advised earlier) so you can recover. Active-active (running live in two Regions at the same time) is a large, costly step that most products never need.
• One AWS account. Production, staging and backups share one blast radius (the amount of damage one mistake or breach can cause). Fix: AWS Organizations, a service that manages many separate accounts together. This is the usual next step.
• One cache node (sessions are lost if it fails). Fix: add a replica, a second copy that takes over automatically.
• One person who understands it. Fix: use the runbooks (step-by-step guides for incidents), the Terraform repository and the drills you wrote. Also train a second person who has really run them.

Go-live readiness checklist

Before a real launch, go through this table with another person. Each row turns a whole lesson into one question:

Honest verdict: AWS or a platform?

After nineteen lessons, you can say something a beginner cannot: most projects should not run on raw AWS. A platform (a service such as Vercel, Railway or Render that runs your app for you) does the work of Lessons 6–18 when you run git push. Now you know exactly what it does for you and what control you give up. Compare them with real numbers:

This knowledge is still useful if you stay on a platform. You can find problems that it hides, read its bill, judge its limits and leave when you must. That was the goal from Lesson 0.

Where to go next

You now have the foundations. Here are sensible next steps, by direction:

If you are early in your career: do the series again from an empty account, using only Terraform, and destroy everything at the end. Doing it twice turns understanding into skill. If you have several years of experience: focus on the judgement this series tried to teach. That means what not to build, where things can fail, how to measure, and how to say “not yet” to a new component. This judgement, not the console clicks, is what seniority looks like.

The whole course in twenty sentences

Interview corner

These last questions are open questions about a whole system. Senior interviews are often built around them. Answer aloud, in a clear order, before you open the answer.

Capstone task

The final exercise is the whole course in one go. Do it in your own AWS account, with a budget alert set, and keep notes — they become your portfolio piece.

1. Draw the architecture from memory on paper, labelling each box with its lesson number and Security Group rules. Compare with the figures above; fix the gaps.
2. Rebuild it from Terraform in a fresh region (or a new account). Time it. Note everything that needed a manual step and bring it into code.
3. Deploy an app through the pipeline, then break it with a bad release and recover with the rollback workflow. Record the time to recover.
4. Run a game day (a planned practice session where you break things on purpose): kill a server under load, stop Redis, fill a disk, revoke a key. For each one, write down which alarm fired (or failed to) and how long it took to notice.
5. Do the restore drill and write down the RTO and RPO you measured.
6. Price it with the AWS Pricing Calculator, compare with your actual first-week bill in Cost Explorer, and explain any difference over 10%.
7. Write the README a new teammate would need: architecture diagram, how to deploy, roll back, get a shell, restore, and who to call. Ask someone to follow it cold.
8. Tear it down (next section) and confirm the bill returns to zero.

Tear it all down safely

When you finish practising, remove everything so that nothing bills while you are not looking. Follow this order:

1. Export anything you want to keep

   Keep your notes, the Terraform code (in Git) and any snapshot you still want. After you delete something, it is gone.

2. Destroy what Terraform created

   InfrastructureCopy all

   • cd infra && terraform plan -destroy -var-file=prod.tfvarsCopy

     Read the list of what will be deleted — this is the plan you most want to read

   • terraform destroy -var-file=prod.tfvarsCopy

     Remove prevent_destroy and deletion_protection on the database first if this really is a practice account (Lesson 15)

3. Delete what you made by hand

   • S3 buckets: empty them including old versions, then delete them. Delete the CloudTrail and Terraform state buckets last.
   • ECR repositories and their images; CloudWatch log groups.
   • RDS manual snapshots, EBS snapshots and cross-region copies.
   • The Route 53 hosted zone (it bills $0.50 a month while it exists) and any domain you no longer want (a domain renews by itself unless you turn that off).
   • IAM roles, policies, users, the OIDC provider and access keys created for the exercise.
   • GuardDuty detector, AWS Config recorder, CloudFront distributions (disable first, then delete).

4. Run the orphan sweep in every region, and check the bill tomorrow

   Use the orphan sweep table above. Then look at Cost Explorer the next day and again after a week. Keep the billing alert from Lesson 5 for good. It is free, and it warns you on the day you forget something.

Conclusion

You started this series knowing how to git push. Now you can design, build, secure, watch, price and rebuild a production system. More importantly, you can explain why every piece is there and what happens when it breaks.

• AWS bills for existing, not for using: compute, storage, requests, transfer and addresses. Read the bill like a diagram.
• Cost levers in order: delete waste, right-size, Graviton, commit to the baseline, turn off non-prod, remove NAT, control logs, tier storage, use the CDN.
• Make it visible: tags, Cost Explorer, budgets with forecast alerts, anomaly detection, and cost per tenant.
• Know your design's weak points — single-AZ database, single region, single account, single person — and spend deliberately on the ones that matter.
• Choose the platform on evidence, including the value of your own time.

Servers, networks, databases and pipelines are only tools. The lasting skill is the way of thinking behind them. Understand the layer below you. Automate what you have done by hand. Expect things to fail. Measure before you decide. Go and build something, destroy it, and build it again.

End of Lesson 19 — and the end of DevOps, From Zero. Return to the series index or the glossary any time.