Case study: cutting a monthly cloud bill

On the afternoon of November 12, Gwen hands Mateo a final exercise. "Two bills," she says. "The sandbox bill that started all this, which we fix today, and the production estimate from lesson 4, which we plan to cut before the first invoice ever arrives. Write it up as a one-page plan for Lorraine." This lesson follows that exercise. It uses everything in the course: pricing drivers, purchase options, storage classes, data transfer, the estimating and tracking tools, the organization, the Free Tier, support plans and Trusted Advisor.

Part 1: the sandbox bill

The October sandbox invoice was 612.40 US dollars after credits. Mateo lists every line, its cause and its fix, using Cost Explorer grouped by usage type and the Trusted Advisor core checks from lesson 10.

Then he adds controls, so that the next mistake is caught in days instead of a month: the sandbox joins the organization (lesson 7); a monthly budget of 150 US dollars with forecast and actual alerts, and a budget action at 150 (lesson 6); a Cost Anomaly Detection monitor; a service control policy that blocks very large instance types in the sandbox; a scheduled job that stops any sandbox instance tagged environment = sandbox at 7 p.m.; and a monitored billing contact. With these in place, the November sandbox forecast falls to about 40 US dollars.

Part 2: the production estimate

The production estimate from lesson 4 was about 9,800 US dollars a month at On-Demand rates. Gwen and Mateo go through it group by group, asking the same questions each time: Is it the right size? Does it need to run all the time? Is it in the right pricing model? Is the data in the right storage class? Is data moving in a way that costs money for no reason?

Rightsizing

The estimate sized the two VetLedger application servers from the vendor's general recommendation. A load test planned for December will measure real use, but the current on-premises servers already give a clue: they run at about a quarter of their CPU most of the day. Gwen proposes starting one size smaller than the vendor's suggestion, watching CloudWatch and Compute Optimizer during the pilot, and stepping up only if needed. On AWS, changing an instance size is a short maintenance task, not a hardware purchase.

Scheduling and environments

The development account will mirror production in miniature. Its servers and test database need to run only in working hours on weekdays, so a schedule stops them at night and on weekends. Lesson 1's calculation showed that running 50 hours a week instead of 168 removes about 70 cents of every compute dollar. Development is smaller than production, but the saving is real and costs nothing.

Storage

Imaging is the largest data cost. The estimate already included a lifecycle rule, but Gwen checks its timing against Dr. Kaur's real practice: most studies are reopened within three months, so the move to Glacier Instant Retrieval shifts to 180 days. Volumes move from gp2-style sizing to gp3 with performance set to measured need. Backups are reviewed with Hannah: daily backups kept 35 days, monthly backups kept for the records retention period, all managed by AWS Backup rather than ad hoc snapshots, so old copies expire automatically.

Data transfer

Three changes reduce transfer charges: gateway endpoints so private servers reach S3 without passing through NAT gateways; CloudFront in front of the public website and its images; and keeping each application's busy, chatty components in the same Availability Zone where the design allows, while still running copies in two zones for resilience. The estimate keeps one NAT gateway per Availability Zone for the traffic that really needs the internet.

Commitments, later

Commitments come last. Production will run On-Demand for its first three months, so the team can see the steady baseline. Then, using the Savings Plans recommendations in Cost Explorer, Lorraine will approve a Compute Savings Plan sized a little below the steady baseline, and the team will evaluate Reserved Instances for Amazon RDS for the SQL Server database, which runs continuously. These are plans for summer 2027, not purchases.

# Illustrative monthly production estimate (USD) and the planned changes.
start = 9800
changes = [
    ("Rightsize app servers one size down", -900),
    ("Schedule development off nights and weekends", -420),
    ("Lifecycle and gp3 changes", -380),
    ("Gateway endpoints and CloudFront", -260),
    ("Business Support+ for production", +700),
    ("Savings Plan and RDS reservation (planned, after 3 months)", -1640),
]
total = start
print(f"{'Starting estimate':55} {start:7,d}")
for name, delta in changes:
    total += delta
    print(f"{name:55} {delta:+7,d}")
print(f"{'Planned steady-state monthly cost':55} {total:7,d}")

Starting estimate                                         9,800
Rightsize app servers one size down                        -900
Schedule development off nights and weekends               -420
Lifecycle and gp3 changes                                  -380
Gateway endpoints and CloudFront                           -260
Business Support+ for production                           +700
Savings Plan and RDS reservation (planned, after 3 months)  -1,640
Planned steady-state monthly cost                         6,900

The result is about 6,900 US dollars a month once commitments are in place, illustrative and dependent on the pilot's measurements. Two lines deserve comment. Business Support+ makes the bill higher, and that is deliberate: Dr. Kaur's 3 a.m. requirement is worth paying for (lesson 9). And the largest single saving, the commitment, is also the one with the most risk if bought too early or too large, which is why it waits.

Part 3: keeping it cut

A bill cut once grows back unless someone watches it. Mateo's plan ends with a monthly routine that takes about an hour.

• Week one of each month: compare the finalized bill with the estimate by group in Cost Explorer; explain any line that moved by more than an agreed amount.
• Review recommendations: Cost Optimization Hub, Trusted Advisor cost checks and Compute Optimizer; act on the top three.
• Check commitments: Savings Plans and RI utilization and coverage reports; flag anything below the agreed utilization.
• Check tags: the untagged resources report; tag or delete what it finds.
• Budgets and anomalies: confirm alerts still go to the right people; review any anomalies from the month.
• Report: a one-page summary for Lorraine with cost by clinic, using the tags and Cost Categories from lesson 6.

This routine is a small version of what larger organizations call cloud financial management or FinOps: finance, technology and the business working together to make spending decisions with good, timely data. Gwen points out that the idea is the same at any size: everyone who can create cost should be able to see it, and someone should look regularly.

Mateo's one-page plan

Lorraine's reply comes back within the hour: "This I can take to the board. Please add a column for who owns each line." Mateo adds it. It is the last change of the course, and possibly the most important one: costs are controlled by people who know they own them.

Cost per appointment

Lorraine thinks in clinics and appointments, not instance hours. Gwen suggests one unit cost for the board: cloud cost per appointment. If the planned steady-state cost is about 6,900 US dollars a month and the group handles about 9,150 appointments a month across all sites, each appointment carries well under a dollar of cloud cost. As the group grows, the total bill should rise, but the cost per appointment should stay flat or fall. A rising unit cost is an early warning that something is being wasted.

# Illustrative unit cost: monthly cloud cost per appointment.
months = ["Apr", "May", "Jun"]
cost = [7400, 7050, 6900]            # USD a month (planned, illustrative)
appointments = [8900, 9050, 9150]
for m, c, a in zip(months, cost, appointments):
    print(f"{m}: {c / a:5.3f} USD per appointment")

Apr: 0.831 USD per appointment
May: 0.779 USD per appointment
Jun: 0.754 USD per appointment

Unit costs also make conversations easier. "The cloud bill went up 300 dollars" invites alarm; "the cloud bill went up 300 dollars because we opened a new clinic, and cost per appointment fell" invites agreement.

Cost and the Well-Architected Framework

The AWS Well-Architected Framework includes a cost optimization pillar whose practices match this lesson: practice cloud financial management, measure and attribute spending, use cost-effective resources, manage demand and supply, and keep optimizing over time. The Well-Architected Tool lets a team review a workload against these questions. Gwen schedules a review of the production design against the cost and reliability pillars before cutover, so that the cost plan and the 3 a.m. plan are checked together.

Where to go next

The billing domain is a small share of the Cloud Practitioner exam, but in daily work it is where most conversations with leadership happen. Mateo leaves the course able to read a bill line by line, estimate a system before it exists, choose purchase options and storage classes, set up tags, budgets and alerts, explain the support plans and find help. The remaining preparation for his February exam is the readiness course, which reviews all four domains.