AWS CRWT study materials
AWS CRWT study resources

AWS Certified Cloud Practitioner (CRWT): Meridian Logistics: a $46,000 bill, a nine-hour outage, and an acquisition risk

AWS CRWT · Put your knowledge to work in context.

All case studies

Meridian Logistics: a $46,000 bill, a nine-hour outage, and an acquisition risk

Meridian Logistics spends about $46,000 a month on AWS. The last bill broke down as 58 percent EC2 and EBS for a production order-tracking platform that has run at steady load for two years and will run for at least three more; 24 percent EC2 for development and QA, busy 09:00 to 18:00 on weekdays and idle at weekends, with unpredictable jumps when a release is being tested; 11 percent S3 and data transfer for a document archive that grows steadily; the remainder is assorted services. Meridian is on Basic support. Six weeks ago a production outage lasted nine hours; the team later said the first two hours were lost because nobody could reach a human at AWS quickly, and the on-call engineer did not know that Trusted Advisor checks beyond the core set existed. The CFO wants a 25 percent reduction and asks whether to commit to three-year terms, given that the company may be acquired.

1. Recommend a purchasing approach for each of the three workloads, with the reasoning behind the commitment depth.

Read the worked answer

Match commitment to certainty, and do not let a discount create a liability.

Production platform (about $26,700/month): steady for two years with at least three more expected, so a commitment is justified - but the acquisition question argues against the deepest lock-in. Start with a one-year Compute Savings Plan covering the measured baseline, deliberately not 100 percent of usage, then layer a three-year plan only on the portion the CFO is certain survives an acquisition. Savings Plans are preferable to convertible or standard Reserved Instances here because they apply across instance families and regions, so a rightsizing or a migration does not strand the discount.

Dev/QA (about $11,000/month): do not commit. Schedule shutdown outside 09:00-18:00 weekdays, use autoscaling with a low floor, and put interruption-tolerant CI and batch work on Spot capacity. The pattern here is idle capacity, not price per hour.

Archive (about $5,000/month): lifecycle policies to colder storage tiers, and review data transfer - CDN for repeated reads, VPC endpoints to avoid unnecessary egress paths.

Show the CFO the arithmetic per workload rather than a single blended percentage, and note that a 25 percent target is plausible mainly from the dev/QA and archive lines plus coverage of the production baseline.

2. Is upgrading support part of the cost answer or a contradiction of it? Argue the case.

Read the worked answer

It is part of the answer, but it must be argued rather than assumed, because the CFO will see it as spending more while being asked to spend less.

Basic support gives no access to technical support cases. Developer support is business-hours email with no production-down response commitment, so it would not have changed the nine-hour outage. Business support adds 24/7 phone, chat and email access, a one-hour response target for a production system down, and the full Trusted Advisor check set - which is the specific gap that left the on-call engineer unaware of checks already available.

On cost: Business support is billed on a tiered percentage of monthly usage. At roughly $46,000 the published tiering works out to something near 10 percent of the first $10,000 plus 7 percent of the remainder, on the order of $3,500 a month, so verify the current published rates before quoting. That is about 7 to 8 percent of the bill, against a nine-hour outage of a production order system and two hours lost purely on escalation.

The honest framing: support does not reduce the bill, it reduces the duration and cost of the incidents that the bill's workloads will eventually have. If the 25 percent target cannot absorb it, present it as a separate decision with its own justification, not buried in the optimisation plan.

3. What would you put in place so the 25 percent target is measurable and does not quietly erode?

Read the worked answer

Make cost a reviewed artefact with an owner, not a monthly surprise.

Tagging first: a mandatory allocation scheme for workload, environment and owner, enforced at creation so untagged resources cannot accumulate. Without it, every later report is guesswork. Then Cost Explorer for the trend and service breakdown, and AWS Budgets with alerts at thresholds for the total and for each workload, so a dev environment left running over a weekend is visible within days rather than at month end.

For commitments specifically: track Savings Plan and Reserved Instance coverage and utilisation. Under-coverage means you are paying on-demand rates; over-commitment means you are paying for capacity you retired. Review both monthly, because the acquisition scenario makes an oversized commitment a real risk.

For the running bill: the Cost and Usage Report to object storage, queryable for the detailed questions finance will ask, and anomaly detection to catch a spike from a misconfigured resource.

Finally, agree the baseline month with the CFO up front. A 25 percent target measured against a moving baseline is how cost programmes lose credibility.