Cascade Instruments: 400 TB, Three Plants, and One Region
Cascade Instruments manufactures sensors in three plants in Ohio, Bavaria and Vietnam. Engineers at each plant need file-level access to a shared 400 TB design repository, and they complain that opening a large CAD file from the current Ohio data centre takes minutes and often fails. The repository must be migrated to AWS within five months. The plants' internet links range from 100 Mbps to 1 Gbps and are oversubscribed during business hours. Separately, Cascade's public product catalogue serves customers in 40 countries from a single t3.medium web server in us-east-2, and page load times in Southeast Asia average six seconds. Management has also asked what happens if us-east-2 becomes unavailable, and has stated that the catalogue can be down for up to four hours but must not lose more than 15 minutes of order data.
1. How would you move the 400 TB and give plant engineers low-latency file access afterwards?
Read the worked answer
These are two different problems. For the bulk move, the plants' links are the constraint: 400 TB over a saturated 1 Gbps link is roughly 40 days of continuous transfer at perfect efficiency, and reality is far worse, so the initial copy should go physical. AWS Snowball Edge devices sized to the data ship the bulk offline; DataSync then handles verification and the delta, and can continue incremental syncs over the network once the bulk has landed.
For ongoing access, direct internet access from Vietnam and Bavaria to a bucket in Ohio will not fix CAD open times, because the file-sharing semantics are wrong. Deploy S3 File Gateway at each plant: it presents an SMB or NFS share backed by S3 with a local cache of recently used files, turning a multi-minute open into a local read. If sustained write throughput beyond the cache is needed, pair it with Direct Connect or a Site-to-Site VPN rather than assuming the oversubscribed internet links will cope.
Cost the gateway hosts and cache storage at each site - that is the price of latency, and it is cheaper than a full on-premises file server refresh.
2. What does the catalogue architecture need to satisfy a four-hour RTO and a 15-minute RPO?
Read the worked answer
Translate the two numbers into architecture. A 15-minute RPO rules out nightly backups alone, while a four-hour RTO makes full active-active hard to justify.
Within a Region, RDS Multi-AZ gives a synchronous standby and failover in typically under two minutes, which covers an Availability Zone failure. The order data also needs automated backups and point-in-time recovery, so that a logical error - a bad deploy, a dropped table - does not breach the 15-minute RPO on its own.
A whole-Region failure is the case management actually asked about: keep a cross-Region read replica in a second Region, replicate the catalogue bucket with Cross-Region Replication, and put Route 53 failover routing with health checks in front. That is a warm standby and meets four hours if promotion and DNS change are rehearsed; run the failover quarterly and record the real elapsed time.
The judgement call is to resist active-active. Two Regions accepting writes doubles cost and operational complexity to buy an RTO the business has already said it does not need.
3. Which of these symptoms is a content-delivery problem and which is not? What does CloudFront fix here?
Read the worked answer
The catalogue is a content-delivery problem, and CloudFront is the right answer: cache static assets and product pages at edge locations close to the 40 countries, cut round trips, and terminate TLS at the edge. That typically turns a six-second load into something acceptable with no change to the origin. Put S3 behind CloudFront rather than a single t3.medium, which is simultaneously a scaling limit and a single point of failure.
The design repository is not a CloudFront problem. CloudFront accelerates HTTP content; it does not speak SMB or NFS, and it cannot make a multi-gigabyte CAD file editable at a plant. That needs the File Gateway cache or dedicated connectivity.
The trap is treating 'slow for users in Asia' as one symptom. The fix depends entirely on the protocol and the access pattern, and applying a CDN to a file-share problem produces a confident recommendation that changes nothing. A secondary point: CloudFront removes the origin as a bottleneck for cacheable content, but uncacheable requests such as checkout still need a Multi-AZ origin.