A Savings Plan Expiring in 45 Days and an Outage That Wasn't Support's Fault
A 400-person company runs 180 EC2 instances in one region: 120 production instances of a fixed family and size running steadily, 40 staging instances running weekdays 9–6, and 20 batch instances that are interruption-tolerant. A 3-year all-upfront Compute Savings Plan covering 100 instances expires in 45 days. Last month's bill showed $38,000 for EC2 and $2,100 for data transfer, of which $1,300 was attributed to cross-AZ traffic between the application tier and a chatty internal service. The company is on Business Support; last quarter a production outage ran 11 hours and the lead engineer says the technical account manager never called. Two engineers now want Enterprise Support, citing that outage.
1. Recommend a purchase mix for the 180 instances and justify it against the 45-day deadline.
Read the worked answer
Split by usage shape, and respect the clock - 45 days is enough for commitment purchases but not for a fleet redesign.
- 120 steady production instances → a compute commitment. The choice is between an EC2 Instance Savings Plan (deeper discount, locked to family/size/region) and a Compute Savings Plan (slightly shallower, applies across families, regions, and to some serverless compute). Since the current fleet is already a fixed family and size, the deeper discount is defensible - but if a migration to a different processor family is remotely likely within the term, that flexibility is worth more than the extra percentage. Prefer a shorter term on the first renewal while the migration question is open.
- 40 staging instances → on-demand plus scheduling. Weekday-only usage does not justify a 3-year commitment. Schedule stop/start outside 9–6 (accepting that attached storage keeps billing) and cover only the residual steady portion.
- 20 batch instances → Spot capacity. They are interruption-tolerant by definition; use allocation that diversifies across capacity pools and ensure the work checkpoints, because reclaim gives roughly a two-minute warning.
The trap is committing 100% coverage. Over-commitment is the expensive mistake; target the steady baseline and let the variable load float.
2. Is an 11-hour outage sufficient grounds to move from Business to Enterprise Support? Argue both sides and name the evidence that settles it.
Read the worked answer
The case for 'yes': Enterprise adds a designated technical account manager, a faster response target for business-critical systems, and access to proactive programmes; a company with a 11-hour production outage has demonstrated that downtime cost matters, and a named advocate changes escalation behaviour.
The case against, which is stronger on the facts given: the claim is that the TAM never called - but a TAM is an Enterprise feature and there was none to call on Business. Business does provide 24/7 access and a response-time target for production-down cases. So the correct first question is not 'which plan' but 'did we open a case, at what severity, and what was the actual response time?' If they never opened one, or opened it at a low severity, the plan is not the failing component.
Evidence that settles it: case history with timestamps, severity levels used, whether the runbook was followed, and the internal time-to-detect versus time-to-AWS-contact split. If AWS breached its published response target, escalate; if the delay was internal, a support upgrade buys a relationship, not an outcome.
Also check the price before advocating: Enterprise carries a monthly minimum charge, so at roughly $40K of monthly spend the increase can be a six-figure annual decision - materially more than the Business plan. Test whether improved architecture (multi-AZ, health checks, tested failover) buys more availability per dollar than the support tier does.
3. The $1,300 cross-AZ line item: how do you attribute it, and what do you change?
Read the worked answer
Sanity-check the number before redesigning anything. Cross-AZ data transfer is charged in both directions, on the order of a cent per GB each way. $1,300 at that effective rate implies tens of terabytes a month between an application tier and one internal service - implausibly high for internal chatter. So the first move is to verify the attribution, not the architecture.
Attribute properly:
- Turn on flow logs (or examine existing ones) and group by source/destination subnet and Availability Zone.
- Tag resources by service and cost centre, then use cost explorer grouping to confirm which traffic type it actually is - internet egress, a NAT gateway processing charge, or genuine cross-AZ. Mislabeled lines are common and each has a different fix.
If it is genuinely cross-AZ:
- Reduce the volume: batch or compress the calls, add caching, replace chatty per-request calls with fewer larger payloads.
- Prefer zone-affine routing for that specific internal pairing where resilience allows, while keeping the fleet spread across zones.
- Do not collapse to a single AZ to save a thousand dollars a month - trading availability for that amount is the wrong direction for a 400-person company, and the decision should be made explicitly rather than by an engineer optimising a line item.