Silverframe Studios: A Four-Hour Recovery Contract Across Three Continents
Silverframe Studios edits and renders film in London, Toronto, and Singapore. Editors need sub-50 ms access to 500 TB of source footage, and local data-protection rules require EU-origin footage to remain in the EU. Rendering is bursty: 3,000 CPU-hours in a normal week, 40,000 in the week before delivery. The studio's DR plan currently restores from tape in three days, but a client contract now demands an RTO of four hours and an RPO of 15 minutes. The board asks whether one Region is enough and whether multi-Region active-active is worth the cost. The CTO wants a design that meets the contract without overbuilding, and a pilot proposal in two weeks.
1. Select a disaster recovery strategy that meets the RTO and RPO. Compare it with the cheaper options you reject.
Read the worked answer
Choose warm standby. A scaled-down but functional copy of the production environment runs continuously in a second Region, with data replicated continuously. Failover scales it up and redirects traffic. This can meet a four-hour RTO because the environment already exists, and a 15-minute RPO because replication is ongoing.
Rejected: backup and restore. Restoring from S3 or tape takes hours to days, so it fails both targets. It is the cheapest option and the right choice only for data that can wait.
Rejected as marginal: pilot light. Core services run but are switched off or minimal, so recovery depends on provisioning and automation that is rarely tested. It can meet four hours if the automation is excellent, but warm standby is more defensible for a contractual commitment.
Rejected as overbuilt: multi-site active-active. It doubles run cost, requires conflict-free data handling, and is unnecessary for a four-hour RTO.
Add two non-negotiables: replicate footage with S3 Cross-Region Replication to approved Regions only, and test failover quarterly. An untested warm standby is a hypothesis, not a control. The pilot should measure actual failover time, not assume it.
2. Design the Region, Availability Zone, and edge topology for latency and EU data residency.
Read the worked answer
Regions near the editors: London (eu-west-2) for the UK and EU editorial teams, Toronto (ca-central-1) for North America, and Singapore (ap-southeast-1) for Asia. Each uses at least three Availability Zones so a single AZ failure does not stop editing or rendering.
Data residency: EU-origin footage stays in an EU Region and is replicated only to other approved EU Regions. Do not replicate it to Toronto or Singapore. Enforce this with bucket policies, S3 replication rules scoped by prefix, and separate accounts or Organizations controls so a misconfiguration cannot move regulated data. Metadata and rendered outputs can be replicated more freely if they contain no regulated footage.
Latency: CloudFront edge locations help with delivery of finished renders and metadata, but they are caches, not a substitute for 500 TB of source footage at sub-50 ms. For source access, place compute near the footage and use Direct Connect or S3 Transfer Acceleration for uploads. Editors should work against local caches or file systems backed by the nearest Region.
Board answer: one Region is not enough for a four-hour RTO if that Region fails; active-active across three Regions is not required.
3. How should rendering capacity be sized and purchased given the weekly burst?
Read the worked answer
Split the workload into a steady floor and a burst. The 3,000 CPU-hours per week is predictable enough to cover with a Compute Savings Plan, purchased for the baseline only. The 40,000-hour pre-delivery week should run on Spot instances orchestrated by AWS Batch, with diversified instance families and Availability Zones, capacity-optimized allocation, and checkpointing so an interruption resumes rather than restarts from zero.
Render outputs go to S3, and the job queue absorbs interruptions. Do not buy Reserved Instances or a Savings Plan sized for the peak week; that converts a variable cost into a year-round fixed cost for capacity used a few weeks a year.
Measure before committing: run the pilot for four weeks and record actual CPU-hours, interruption rates, and time to completion. Then commit to the measured floor. This also gives the CTO the evidence needed to defend the design to the board without overbuilding.
One caveat: Spot capacity is not guaranteed, so keep a small On-Demand buffer for delivery-week deadlines where completion time is contractual.