Cost and Good Architecture

You've come a long way since part one. In this final part we answer two questions that apply to everything we built: how much does it cost? and is it designed well? Then we turn it all into a file you can rebuild with one command.

Where does the network money go? #

Most people plan for servers and storage, then get surprised by data transfer. Prices here are approximate for US Regions:

Small numbers add up quickly. Six things that cut them:

• Use private IPs inside the VPC instead of public ones, and note that every public IPv4 address also has an hourly charge.
• Put CloudFront in front of your application. Data from AWS to CloudFront is free, and out through it costs less than going out directly.
• Add a gateway endpoint for S3 and DynamoDB. It's free, and it spares you NAT charges per GB.
• One NAT gateway per Availability Zone, so traffic doesn't cross zones to reach it.
• Keep chatty services close. Balance this against availability, though, as splitting across zones is worth paying for.
• Compress what you send, and cache it as far forward as you can.

Where's the caching? #

Each layer saves work for the ones behind it, so the further forward the better, and we've seen them all:

Tools that watch your bill #

And the first step is tags: without an env or team tag, you won't know who's spending what. And tags only reach your cost reports once you activate them as cost allocation tags in the billing console.

Quick savings #

The Well-Architected Framework #

AWS has summarized what it's learned from its customers in six pillars. Consider it a review for any design:

The pillars pull against each other at times: more copies mean better reliability and higher cost. The aim isn't to max out everything, but to make the trade-off knowingly.

• AWS Well-Architected Tool: a free tool in the console that asks you questions about your workload and shows the risks.
• Trusted Advisor: checks your account against best practices. On the free plan you get service limits and a few security and fault-tolerance checks, and the rest need a paid support plan. Note that AWS is changing its support plans, with Developer and Business ending on January 1, 2027 in favor of Business Support+.

CloudFormation: your infrastructure in a file #

So far we've created everything by hand or by command. What if you could describe it all in a file? AWS CloudFormation reads a template and builds a stack of resources, in the right order, and:

• Repeatable: the same environment for development, testing and production.
• Reviewable: the template sits in Git like code, and you review its changes.
• Controlled: a change set shows what will change before it happens, and drift detection reveals manual changes.
• Clean: deleting a stack deletes everything in it, so nothing's left billing you.
• Free: you pay only for the resources it creates.

Infrastructure Composer lets you draw a template visually, and AWS CDK writes it in Python or TypeScript. A service role lets a developer deploy a stack without having permission over the resources themselves.

Systems Manager: running your servers #

AWS Systems Manager manages fleets of servers through an agent, already installed on Amazon Linux, and an IAM role:

Applications you can't change #

Not every application can be rewritten, and you can often make an old one more reliable from the outside, without touching its code:

Services worth knowing #

A last group that deserves a line each:

If you read older articles, Amazon Pinpoint reached its end of support on October 30, 2026. AWS points to SES for email, and to AWS End User Messaging for SMS and push notifications. AWS Proton also reached its end of support, on October 7, 2026, though the exam guide still lists it.

High performance computing #

When you need thousands of processors working together:

Hands-on: a whole stack from a file, and a budget you'll keep #

Write a small template with a bucket and an SNS topic. From CloudShell:

cat > stack.yaml <<'EOF'
AWSTemplateFormatVersion: "2010-09-09"
Description: A small stack from the AWS series
Parameters:
  Env:
    Type: String
    Default: dev
Resources:
  Files:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled
      Tags:
        - Key: env
          Value: !Ref Env
  Alerts:
    Type: AWS::SNS::Topic
Outputs:
  BucketName:
    Value: !Ref Files
EOF

aws cloudformation deploy --stack-name series-stack --template-file stack.yaml

aws cloudformation describe-stack-resources --stack-name series-stack \
  --query "StackResources[].[LogicalResourceId,ResourceType,ResourceStatus]" \
  --output table

CloudFormation built both resources and named them itself. Now change one value. It updates only what changed, without touching the rest:

aws cloudformation deploy --stack-name series-stack \
  --template-file stack.yaml --parameter-overrides Env=prod

BUCKET=$(aws cloudformation describe-stacks --stack-name series-stack \
  --query "Stacks[0].Outputs[0].OutputValue" --output text)

aws s3api get-bucket-tagging --bucket $BUCKET \
  --query "TagSet[?Key=='env'].Value" --output text

It prints prod. Now the nicest part, deleting everything with one command:

aws cloudformation delete-stack --stack-name series-stack
aws cloudformation wait stack-delete-complete --stack-name series-stack
echo "Everything is gone"

Finally, one thing to keep: a budget of $10 a month that warns you when you're forecast to exceed 80% of it. Replace the email address with yours:

EMAIL=[email protected]
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

cat > budget.json <<'EOF'
{
  "BudgetName": "series-monthly",
  "BudgetLimit": {"Amount": "10", "Unit": "USD"},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}
EOF

cat > notify.json <<EOF
[{
  "Notification": {
    "NotificationType": "FORECASTED",
    "ComparisonOperator": "GREATER_THAN",
    "Threshold": 80,
    "ThresholdType": "PERCENTAGE"
  },
  "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "$EMAIL"}]
}]
EOF

aws budgets create-budget --account-id $ACCOUNT \
  --budget file://budget.json \
  --notifications-with-subscribers file://notify.json

aws budgets describe-budgets --account-id $ACCOUNT \
  --query "Budgets[].[BudgetName,BudgetLimit.Amount,BudgetLimit.Unit]" --output table

If you get AccessDenied, your IAM user may need billing access, which the root user enables from the account settings.

Summary #

• Data transfer is the hidden cost: between zones, between Regions, and out to the internet.
• Budgets and Cost Anomaly Detection warn you before the bill does.
• The Well-Architected Framework has six pillars, and the point is to make trade-offs knowingly.
• CloudFormation turns your infrastructure into a reviewable, deletable file.
• Systems Manager manages your servers without SSH.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

What you've learned #

Twenty-nine parts in nine sections. Look at what you can do now:

Where to go from here #

• Build something real. A small project of your own teaches you more than any article, even a little site with an API.
• Try the comprehensive test. It picks random questions from every part, so you can see what's stuck and what to review.
• Read the FAQs. Each service's FAQ page is a short, rich and accurate summary.
• Consider a certification. Solutions Architect Associate covers most of what's in this series, and the exam tests how you choose between services. Read each question for its deciding phrase, such as "lowest cost" or "least operational effort", and eliminate the wrong answers first. Its official exam guide lists every domain and service.
• Follow the changes. AWS changes quickly, and several things in this series changed even as it was being written. Check the docs before any decision.

Thanks for coming along to the end, and good luck with what you build.