LEARN. PRACTICE. GROW.Build a comparison with matching scope
For a fictional funds service, FinOps requests a monthly reduction while APS requires recovery, performance, and private access to remain intact. Start with two estimates using the same demand, period, Regions, and service level. Separate fixed charges, variable consumption, and costs retained after the change. An RDS Reserved DB Instance is a billing discount on eligible usage, not a new database to install. Confirm matching attributes and partial cluster coverage. An instance discount does not automatically cover storage, backups, and I/O. All exercise prices are fictional units; for a real decision, substitute the applicable quote and document exclusions.
Compare Aurora totals and variability
Aurora Standard has an I/O charge; I/O-Optimized removes read and write I/O charges, but the remaining categories still need comparison. Here Standard costs 900 for instances and storage plus 600 for I/O; the alternative costs 1200 for the same service. The difference is 300, not 600. If demand changes and I/O falls to 150, Standard becomes 1050. Calculate quiet and busy months before recommending. Do not plan daily switching: Standard-to-I/O-Optimized changes have a frequency limit and class-dependent impacts may apply. For serverless, no queries does not prove a pause; open user connections prevent it. Confirm engine support, a zero minimum, and resume tolerance.
Separate DynamoDB capacity mode and table class
On-demand charges for requests; provisioned charges for configured capacity even when some is unused. Unpredictable demand may favor on-demand’s simpler management. A steady workload with a credible forecast can justify comparing provisioned mode, including configuration and peak handling. This choice is separate from Standard versus Standard-IA table class. Standard-IA reduces storage pricing but increases throughput pricing; a large table with many reads can become more expensive. Secondary indexes use their table’s class, and Standard-IA can use on-demand. In the workshop, calculate storage plus requests before and after, including indexes, and explain which demand assumption reverses the decision. Size and access frequency are different facts.
Calculate avoidable endpoint cost
A gateway endpoint for S3 or DynamoDB has no additional endpoint charge and can remove that traffic from NAT. This does not eliminate NAT hours if other destinations still need it. An interface endpoint has per-zone hours and data processing charges. With fictional values, replacing NAT processing of 0.05 per GB with an endpoint costing 48 fixed plus 0.01 per GB breaks even at 1200 GB. Above that volume the alternative saves money in this model; below it costs more. Retain the same zone coverage and required access in both estimates. Do not remove a zone to manufacture savings or assume all endpoints are free because gateway endpoints are.
Count the complete traffic path
Draw source, hops, and destination, marking charge categories on each link. TGW adds attachment hours and processing alongside applicable transfer costs; processing alone is not the total solution cost. For an ALB without an LCU reservation, normalize all four dimensions to LCUs and use the largest, then add the load balancer’s hourly charge. Do not sum already normalized dimensions. CloudFront can reduce origin work, but comparison includes delivery, requests, and enabled features under the selected plan. Direct Connect retains port-hour charges while provisioned, even without traffic. For an intermittent connection, also compare partner charges and required availability rather than deciding from the per-GB price alone.
Turn an estimate into a verifiable decision
Give the committee the alternative, scope, expected saving, demand sensitivity, and evidence that requirements remain satisfied. A saving forecast may fail because NAT remains necessary, the application keeps connections open, or an index generates more requests than expected. Assign an owner to each assumption and schedule a later comparison against the same baseline. Run the lesson’s local model: predict the results first, change volume to 600 and then 2400 GB, and explain the reversal. The code calculates only synthetic in-memory values; it does not retrieve prices, represent an invoice, or measure AWS. Record which excluded costs would matter in a real review.
// Synthetic teaching model: fictional units, no AWS prices or requests.
const endpoint = gb => ({nat: gb *.05, endpoint: 48 + gb *.01});
const savings = gb => {const c = endpoint(gb);return c.nat - c.endpoint;};
const result = {
auroraSaving: (900 + 600) - 1200,
endpointBreakEvenGB: 48 / (.05 -.01),
endpointSavingAt2000GB: savings(2000),
endpointSavingAt600GB: savings(600),
albLCU: Math.max(.4,.2, 1.4,.8),
cdnNetSaving: 400 - (100 + 250)
};
console.log(JSON.stringify(result))Twenty-minute workshop: NAT remains for external destinations. The endpoint costs 48 monthly plus 0.01 per GB; avoidable NAT processing costs 0.05 per GB. At 2000 GB, compare 68 with 100 for a saving of 32. At 600 GB, compare 54 with 30 for an increase of 24. All values are fictional; other categories are equal or explicitly excluded.
Common pitfalls
Applying an RDS discount to the whole bill; overlooking I/O and requests; treating Standard-IA as an archive without throughput; counting every NAT hour as avoided; forgetting per-zone endpoints; summing LCU dimensions; assuming serverless pauses with open connections; mistaking fictional rates for a real quote.
Related topics: Databases, replicas, and cache · Costs, commitments, and retirement · Compute: commitments and batch recovery
Compare the complete service, separate avoidable and retained costs, and repeat the calculation across demand levels. The cheapest choice is eligible only if it retains requirements. Models and cases are fictional; they prove neither real savings nor AWS execution.
Reference: SAA-C03 cost-optimized architectures · SAA-C03