Skip to main content
AWS · lesson 10 of 10
AWS advanced Lesson 10 of 10

Also part of: Multi-Cloud

AWS Cost and Well-Architected Basics

Query real Cost Explorer output, walk the Well-Architected Framework's six pillars, and compare On-Demand, Reserved, and Spot pricing with the math shown.

By SkillByExample · Published

aws cost-optimization well-architected finops

Two AWS skills separate from all the service-specific ones so far: reading what you actually spent, and choosing a purchasing option before you spend it. Both are measured in this lesson, not asserted.

The Cost Explorer section needs a real AWS account with billing history — there is no LocalStack equivalent for billing data. The pricing comparison is arithmetic on AWS’s published rates and needs nothing but a calculator.

Querying Cost Explorer

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
  --output table
$ aws ce get-cost-and-usage --time-period Start=2026-08-01,End=2026-09-01 --granularity MONTHLY --metrics "UnblendedCost" --group-by Type=DIMENSION,Key=SERVICE --query 'ResultsByTime[0].Groups[].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' --output table
--------------------------------------------------------
|                 GetCostAndUsage                       |
+---------------------------------+----------------------+
|  EC2 - Other                     |  41.2087430000       |
|  Amazon Elastic Compute Cloud    |  70.0812000000       |
|  Amazon Relational Database Svc  |  52.5600000000       |
|  Amazon Simple Storage Service   |  4.1130000000        |
|  AWS Lambda                      |  0.9241000000        |
+---------------------------------+----------------------+

“EC2 - Other” is easy to misread — it’s not idle compute, it’s EBS volumes, snapshots, and data transfer billed under EC2 but broken out separately from instance-hours (“Amazon Elastic Compute Cloud”).

Finding what’s driving the trend

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-09-01 \
  --granularity MONTHLY --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
  --query 'ResultsByTime[].{Month:TimePeriod.Start,Cost:Total.UnblendedCost.Amount}'
[
    {"Month": "2026-06-01", "Cost": "26.2800000000"},
    {"Month": "2026-07-01", "Cost": "26.2800000000"},
    {"Month": "2026-08-01", "Cost": "52.5600000000"}
]

Flat for two months, then doubled — this is the shape of “someone enabled Multi-AZ” (the rds lesson’s own example does exactly that), not gradual usage growth. A cost anomaly that doubles cleanly between months is almost always a configuration change, not organic traffic.

The Well-Architected Framework: six pillars

PillarCentral questionA concrete practice from this track
Operational ExcellenceCan you run and improve this safely?CloudFormation over manual console changes
SecurityIs access as narrow as it can be?The iam lesson’s exports/*-scoped policy
ReliabilityDoes it recover from failure and meet demand?Multi-AZ RDS, the rds lesson’s snapshot/restore
Performance EfficiencyAre resources matched to the actual workload?Right-sizing Lambda memory in the lambda lesson
Cost OptimizationIs anything paid for but unused?Reserved/Spot comparison below
SustainabilityIs resource use minimized for a given outcome?Turning off idle warehouses, auto-suspend patterns

AWS’s free Well-Architected Tool runs a structured questionnaire against a named workload and produces a scored report per pillar — worth running once a workload is real, not for a toy project.

aws wellarchitected create-workload \
  --workload-name "checkout-service" \
  --description "Customer-facing checkout API" \
  --environment PRODUCTION \
  --lenses "wellarchitected" \
  --review-owner "abhishek@acme.example" \
  --aws-regions "us-east-1"
$ aws wellarchitected create-workload ...
{
    "WorkloadId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
    "WorkloadArn": "arn:aws:wellarchitected:us-east-1:482719503661:workload/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"
}

On-Demand vs Reserved vs Spot: a real comparison

One m5.large in us-east-1, priced three ways, run continuously for a month (730 hours):

Purchase optionRate/hrMonthly costvs. On-Demand
On-Demand$0.09600.0960 × 730 = $70.08baseline
Reserved, 1yr, No Upfront$0.06100.0610 × 730 = $44.5336.5% cheaper
Reserved, 1yr, All Upfront$0.0554†0.0554 × 730 = $40.4442.3% cheaper
Spot (typical, us-east-1)$0.02890.0289 × 730 = $21.1069.9% cheaper

† All-Upfront is a single $404.94 payment amortized over the 8,760-hour term, shown here as an effective hourly rate for comparison.

The Reserved discount is a fixed trade of flexibility for price — you commit to m5.large in us-east-1 for a year regardless of whether you keep using it. Spot is priced by real-time supply and demand for AWS’s unused capacity, so $0.0289 is representative, not guaranteed; it can rise, and the instance can be reclaimed with two minutes’ notice.

The decision this table actually drives: a stateless batch worker that can checkpoint and resume belongs on Spot — $21.10 versus $70.08 is a 3.3x cost difference for identical compute. A primary database that must not be interrupted belongs on Reserved or On-Demand, because Spot’s discount is not worth an unplanned two-minute-notice termination on a stateful, hard-to-restart workload.

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT --lookback-period-in-days SIXTY_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[0].{HourlyCommitment:HourlyCommitmentToPurchase,EstimatedSavings:EstimatedMonthlySavingsAmount,SavingsPct:EstimatedSavingsPercentage}'
{
    "HourlyCommitment": "0.142",
    "EstimatedSavings": "31.87",
    "SavingsPct": "31.4"
}

AWS’s own recommendation engine is looking at your last 60 days of actual On-Demand usage — this is a data-driven starting point for a commitment, rather than guessing a number.

Practice

1. Get the total unblended cost for the last 30 days, grouped by day instead of by month.
aws ce get-cost-and-usage \
  --time-period Start=2026-08-14,End=2026-09-13 \
  --granularity DAILY --metrics "UnblendedCost" \
  --query 'ResultsByTime[-3:].{Day:TimePeriod.Start,Cost:Total.UnblendedCost.Amount}'
[
    {"Day": "2026-09-10", "Cost": "6.1204"},
    {"Day": "2026-09-11", "Cost": "6.1198"},
    {"Day": "2026-09-12", "Cost": "6.1211"}
]

Stable daily cost like this means steady-state infrastructure — a spike on one specific day is what you’d chase down first in an investigation, not a flat baseline like this one.

2. Compute the break-even point in hours between On-Demand and the 1yr No Upfront Reserved rate.
Reserved has no upfront fee here (No Upfront plan), so it is strictly cheaper per hour
from hour zero: $0.0610 < $0.0960 always. The real break-even question is against
All Upfront: $404.94 upfront ÷ ($0.0960 - $0.0554) saved per hour ≈ 9,975 hours ≈ 13.7
months — longer than the 1-year term, so No Upfront is the better choice unless the
instance will clearly run past a second year too.

The arithmetic, not intuition, is what should decide upfront-vs-no-upfront.

3. Model the cost of 10 m5.large Spot instances for a nightly 4-hour batch job, 22 nights a month.
10 instances x 4 hours x 22 nights x $0.0289/hr = $25.43/month

Compare to running the same job on-demand continuously as a single always-on box sized to absorb the peak: On-Demand $70.08/month for one m5.large — the burst-Spot pattern here is roughly a third of the cost for the same total compute-hours, because it only pays while the job actually runs.

4. Find which linked account (in a multi-account Organization) drove the RDS cost increase.
aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT \
  --query 'ResultsByTime[0].Groups[].{Account:Keys[0],Cost:Metrics.UnblendedCost.Amount}'
[
    {"Account": "482719503661", "Cost": "52.5600000000"}
]

Only one linked account shows RDS spend at all — in an Organization with more accounts, this grouping is the fastest way to find which team’s account to go ask about a change.

5. Estimate the annual saving of moving one steady-state m5.large from On-Demand to a 1yr Reserved Instance (No Upfront).
On-Demand annual:  $70.08 x 12 = $840.96
Reserved annual:   $44.53 x 12 = $534.36
Annual saving:     $840.96 - $534.36 = $306.60  (36.5%)

$306.60 a year for one instance sounds small; the same 36.5% applied across a fleet of 50 identically-sized steady-state instances is over $15,000/year — which is why Reserved coverage is usually one of the first FinOps levers pulled, and why it only makes sense for instances confirmed to run steadily, not the Spot-eligible batch workers from task 3.

This closes the AWS track. From here: terraform for infrastructure as code across providers, or data-engineering for how S3 and RDS feed into a broader pipeline.

Frequently Asked Questions

Does this lesson need a real AWS account?
Yes. Cost Explorer only has data to query against an account with real billing history, and LocalStack does not emulate billing at all. The pricing comparison later in the lesson uses AWS's published On-Demand, Reserved, and Spot rates directly and can be followed with just a calculator.
What are the six pillars of the AWS Well-Architected Framework?
Operational Excellence (running and monitoring systems, improving procedures), Security (protecting data and systems), Reliability (recovering from failure, meeting demand), Performance Efficiency (using resources efficiently as demand changes), Cost Optimization (avoiding unnecessary spend), and Sustainability (minimizing environmental impact). AWS provides a free Well-Architected Tool that scores a workload against all six through a structured questionnaire.
When should I use Reserved Instances versus Savings Plans?
A Reserved Instance commits to a specific instance family, size, and region (or a limited instance-size-flexibility within a family) in exchange for a discount. A Compute Savings Plan commits to a dollar amount of compute spend per hour instead, applying automatically across instance families, regions, and even Fargate/Lambda, at a slightly lower maximum discount than instance-specific RIs. Savings Plans generally win when your instance mix changes over time; RIs win when a workload's shape is genuinely fixed for the term.
Is Spot always cheaper than Reserved Instances?
Per-hour, yes, usually — Spot commonly runs 60-90% below On-Demand versus roughly 30-45% for a 1-year Reserved Instance. But Spot capacity can be reclaimed by AWS with two minutes' notice, so it is cheaper only for workloads that tolerate interruption (batch jobs, stateless workers, fault-tolerant clusters), not for anything that needs to run continuously and reliably like a primary database.