Kestrel Analytics: Sunk Costs, Elasticity, and a Six-Week Deadline
Kestrel Analytics is a 40-person market-research firm that has run its nightly ETL pipeline on 24 physical servers bought three years ago for $310,000. Utilization on those servers is 90% between 01:00 and 05:00 and 4-6% for the remaining 20 hours. The CFO has approved a cloud migration only if it lowers cost within 18 months, and wants to know whether the $310,000 already spent counts against the cloud option. The CTO, under pressure from a product launch in six weeks, wants the team to rebuild the pipeline as containerized microservices on AWS before that launch. The team has two engineers with AWS experience and no dedicated operations staff. Last quarter a proof-of-concept in a single Availability Zone lost 40 minutes of processing when a host failed, and the team is unsure whether to change the architecture or accept the risk.
1. The CFO asks whether the $310,000 of existing servers should be included when comparing on-premises and AWS costs, and how you would build the comparison. What do you advise?
Read the worked answer
The $310,000 is a sunk cost. It was paid regardless of what Kestrel does next, so including it would make migration look artificially expensive (or, if depreciated, arbitrarily cheap). The only defensible comparison is forward-looking cash flow over the same horizon: what Kestrel will pay on AWS versus what it will pay to keep the servers alive - power, cooling, rack space, hardware refresh in year four or five, backup, DR, and staff time.
Build the AWS side with the AWS Pricing Calculator rather than a per-server rule of thumb, and include what teams forget: data transfer out, storage growth, a support plan, and the cost of a Multi-AZ design if availability is a requirement. Migration Evaluator can produce a baseline from the existing utilization data.
The utilization profile - 90% for four hours, under 6% for twenty - is the strongest argument for the cloud. On-premises capacity sized for the peak is idle roughly 83% of the day; right-sized instances with automatic scaling are not. The honest caveat: a poorly sized migration, or one that keeps 24 server-equivalents running around the clock, can cost more than the hardware did.
2. The CTO wants the full re-architecture into containerized microservices completed before the six-week launch. Evaluate this plan and recommend an approach.
Read the worked answer
Rebuilding as containerized microservices in six weeks, with two AWS-experienced engineers and no operations staff, is a schedule bet that usually loses. The AWS Cloud Adoption Framework separates migration into phases, and the operational excellence pillar of the Well-Architected Framework favours small, reversible changes over a single large cutover.
A practical sequence: migrate the existing pipeline first, largely as-is, onto managed compute and object storage. That meets the launch date and removes the hardware risk. Then refactor incrementally, one stage at a time, behind the same interfaces, so each change can be tested and rolled back independently. Keep each refactor tied to a named business driver - cost per job, time to add a data source - not to a preference for containers.
Flag the staffing constraint explicitly: two engineers cannot both operate a new platform and rewrite it at the same time. 'No dedicated operations staff' is an argument for managed services such as S3, AWS Batch, Step Functions and managed queues, not for a bespoke microservice platform that someone then has to run at 3 a.m.
3. The proof-of-concept lost 40 minutes of processing when a single host failed in one Availability Zone. What design change addresses this, and how does the shared responsibility model apply?
Read the worked answer
The 40-minute loss came from a single point of failure that the customer chose, not from AWS failing to keep the Availability Zone running. Multi-AZ is the standard remedy: run processing capacity in at least two AZs and make each unit of work retryable, so a lost host costs one document rather than one batch.
Concretely: put a queue in front of the workers (Amazon SQS), make each job idempotent and keyed by document ID, set a visibility timeout slightly longer than expected processing time, and let a killed worker's job return to the queue. Checkpoint progress to S3 or DynamoDB. For the database, RDS Multi-AZ provides a synchronous standby and automatic failover.
Under the shared responsibility model, AWS is responsible for the availability of the AZ infrastructure itself; the customer is responsible for designing an architecture that survives losing any single one. The trade-off is cost - a second AZ, a standby database, duplicated capacity - so decide explicitly which pipeline stages must survive a failure and which can simply be re-run cheaply.