AWS · 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
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
| Pillar | Central question | A concrete practice from this track |
|---|---|---|
| Operational Excellence | Can you run and improve this safely? | CloudFormation over manual console changes |
| Security | Is access as narrow as it can be? | The iam lesson’s exports/*-scoped policy |
| Reliability | Does it recover from failure and meet demand? | Multi-AZ RDS, the rds lesson’s snapshot/restore |
| Performance Efficiency | Are resources matched to the actual workload? | Right-sizing Lambda memory in the lambda lesson |
| Cost Optimization | Is anything paid for but unused? | Reserved/Spot comparison below |
| Sustainability | Is 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 option | Rate/hr | Monthly cost | vs. On-Demand |
|---|---|---|---|
| On-Demand | $0.0960 | 0.0960 × 730 = $70.08 | baseline |
| Reserved, 1yr, No Upfront | $0.0610 | 0.0610 × 730 = $44.53 | 36.5% cheaper |
| Reserved, 1yr, All Upfront | $0.0554† | 0.0554 × 730 = $40.44 | 42.3% cheaper |
| Spot (typical, us-east-1) | $0.0289 | 0.0289 × 730 = $21.10 | 69.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.