Case Studies: Storage

Domain 2: Design for New Solutions - Storage Case Studies

Case Study 1

A healthcare analytics company processes medical imaging data from hospitals across multiple countries. The company receives DICOM files ranging from 50 MB to 2 GB in size. Files are uploaded continuously throughout the day and must be accessible immediately after upload for AI-based diagnostic processing. After 90 days, files are rarely accessed but must be retained for 7 years due to regulatory requirements. The company currently stores all data in Amazon S3 Standard and is spending approximately $180,000 monthly on storage alone. The architecture team has been tasked with reducing storage costs by at least 60% while maintaining immediate access to recent files and ensuring compliance with data retention policies. The solution must not require changes to the existing application code that references S3 object URLs directly.

What is the MOST cost-effective solution that meets all requirements?

1. Implement an S3 Lifecycle policy that transitions objects to S3 Standard-IA after 30 days, then to S3 Glacier Flexible Retrieval after 90 days, with an expiration rule at 7 years.
2. Implement an S3 Lifecycle policy that transitions objects to S3 Intelligent-Tiering immediately upon upload, with archive configurations that move objects to Archive Access tier after 90 days and Deep Archive Access tier after 180 days.
3. Migrate all existing objects to S3 One Zone-IA immediately, then implement a lifecycle policy to transition objects to S3 Glacier Deep Archive after 90 days with an expiration at 7 years.
4. Implement an S3 Lifecycle policy that transitions objects to S3 Standard-IA after 90 days, then to S3 Glacier Deep Archive after 180 days, with an expiration rule at 7 years.

Answer & Explanation

Correct Answer: 2 - Implement S3 Intelligent-Tiering with archive configurations

Why this is correct: S3 Intelligent-Tiering is specifically designed for data with unknown or changing access patterns. It automatically moves objects between access tiers based on actual usage without performance impact or operational overhead. Objects remain immediately accessible in the Frequent Access tier when first uploaded and during the initial 90-day period when they're actively used for diagnostic processing. After 90 days without access, objects automatically move to the Archive Access tier (equivalent to Glacier Flexible Retrieval pricing), and can optionally move to Deep Archive Access tier after 180 days of no access. Critically, objects remain accessible via the same S3 API and URLs regardless of tier, meaning no application code changes are required. The automatic tiering eliminates the risk of early deletion charges and minimum storage duration violations that plague fixed lifecycle transitions. This solution can achieve 60%+ cost reduction while maintaining immediate access for active files.

Why the other options are wrong:

• Option 1: Transitioning to S3 Standard-IA after 30 days incurs early deletion charges if objects are accessed and modified within the first 30 days (Standard-IA has a 30-day minimum storage duration). More importantly, files that are still actively accessed between 30-90 days would incur higher retrieval costs in Standard-IA. The transition timing is not optimized for the actual access pattern described.
• Option 3: S3 One Zone-IA immediately applied to all objects would expose the data to availability zone failure risk, which is unacceptable for healthcare data requiring 7-year retention for regulatory compliance. Additionally, migrating all existing objects immediately would trigger data transfer and PUT request costs, and One Zone-IA still has a 30-day minimum storage duration that could result in early deletion charges.
• Option 4: While this approach avoids some early deletion issues by waiting 90 days before transitioning to Standard-IA, it fails to optimize for the first 90-day period when files are actively accessed. Objects would remain in the expensive S3 Standard tier during this entire period. Additionally, once objects move to Glacier Deep Archive, retrieval requires 12-48 hours, which could create compliance issues if unexpected access is needed during the 7-year retention period.

Key Insight: The constraint "must not require changes to existing application code that references S3 object URLs directly" eliminates solutions that move data to Glacier storage classes, which require restore operations before access. S3 Intelligent-Tiering is the only solution that maintains transparent S3 API access across all tiers while automatically optimizing costs based on actual access patterns, making it ideal for unknown or changing access patterns without code modifications.

Case Study 2

A financial services company runs a trading platform that captures market tick data at microsecond precision. The application layer consists of 200 EC2 instances across four Availability Zones that must write data simultaneously to shared storage. The system generates approximately 40 TB of new data daily, with write operations occurring at rates exceeding 500,000 IOPS during peak trading hours. Data must be immediately accessible to all compute instances with sub-millisecond latency. After 24 hours, data is archived to long-term storage and removed from the high-performance storage system. The company previously attempted to use a self-managed parallel file system but experienced significant operational burden related to scaling, patching, and failure recovery. The architecture team needs a fully managed solution that can handle the extreme IOPS requirements while minimizing operational overhead.

Which storage solution meets these requirements with the LEAST management overhead?

1. Deploy Amazon FSx for Lustre with a Persistent_2 deployment type, configure data repository associations to automatically export data to S3 after 24 hours, and enable automatic backup.
2. Deploy Amazon EFS with Max I/O performance mode and use lifecycle management policies to transition data to EFS Infrequent Access after 24 hours, with a Lambda function to delete old files.
3. Deploy Amazon FSx for NetApp ONTAP with flash cache enabled, use SnapMirror to replicate data to S3 after 24 hours, and configure volume auto-sizing for capacity management.
4. Deploy a fleet of Amazon EBS volumes using io2 Block Express volumes with Multi-Attach enabled, distribute data across volumes, and use AWS Backup to archive data to S3 after 24 hours.

Answer & Explanation

Correct Answer: 1 - Amazon FSx for Lustre with Persistent_2 deployment type

Why this is correct: Amazon FSx for Lustre is purpose-built for high-performance computing workloads requiring extreme throughput and IOPS. The Persistent_2 deployment type can deliver up to millions of IOPS with sub-millisecond latencies, easily handling the 500,000+ IOPS requirement. Lustre natively supports concurrent access from hundreds of instances across multiple Availability Zones, making it ideal for the 200-instance requirement. The data repository association feature allows automatic and policy-driven export of file data to S3, enabling seamless archival after 24 hours without custom scripting. FSx for Lustre is fully managed-AWS handles patching, scaling, and failure recovery-directly addressing the operational burden the company experienced with self-managed systems. The file system can be accessed using standard POSIX semantics, ensuring compatibility with existing trading applications.

Why the other options are wrong:

• Option 2: Amazon EFS, even with Max I/O mode, cannot deliver the 500,000+ IOPS required by this workload. EFS is designed for general-purpose file sharing with moderate performance requirements (typically up to 500,000 aggregate IOPS across all connected clients, but individual file operations are much slower than Lustre). More critically, EFS lifecycle management transitions files to Infrequent Access storage class but does not remove files from the file system-it only changes the storage tier. This would not free up the high-performance storage as required, and would still incur costs for storing 40 TB daily on EFS, which is significantly more expensive than archiving to S3.
• Option 3: Amazon FSx for NetApp ONTAP is designed for enterprise workloads requiring advanced data management features like snapshots and cloning, but it does not provide the extreme IOPS performance required for high-frequency trading tick data. While ONTAP supports high performance, it is optimized for mixed workloads and NAS protocols rather than the massive parallel I/O patterns of financial tick data. Additionally, configuring SnapMirror to replicate to S3 adds complexity and does not provide a native, automated export mechanism like FSx for Lustre's data repository associations.
• Option 4: EBS Multi-Attach only works within a single Availability Zone and supports a maximum of 16 instances per volume, making it impossible to support 200 instances across four Availability Zones. Even with io2 Block Express volumes capable of 256,000 IOPS per volume, distributing data across multiple volumes requires complex application-level logic for data striping and management. This approach increases operational complexity rather than reducing it, and AWS Backup does not natively archive EBS snapshots directly to S3 in a way that removes data from the volumes-it creates snapshots stored as EBS snapshot data, not archived objects.

Key Insight: The combination of extreme IOPS requirements (500,000+), concurrent multi-instance access across AZs, and the need for automated data lifecycle management (archive to S3 after 24 hours) uniquely points to FSx for Lustre. Many candidates incorrectly assume EFS is always the answer for shared file storage, but EFS cannot deliver the performance required for high-frequency trading workloads. Understanding the performance boundaries and specific use cases for each file storage service is critical.

Case Study 3

A media streaming company stores video content in Amazon S3, with a content delivery architecture that serves 50 million users globally through Amazon CloudFront. The company recently migrated from an on-premises storage system and discovered that their monthly S3 request costs have reached $85,000, primarily driven by GET requests from CloudFront to S3. The architecture team analyzed access patterns and found that approximately 30% of videos account for 95% of all views, while the remaining 70% of content is accessed infrequently. Videos are encoded in multiple bitrate formats, resulting in 8-12 separate objects per video asset. The company wants to reduce S3 request costs without impacting user experience or requiring changes to CloudFront distributions. The solution must maintain the current architecture's security model, which uses signed URLs with origin access identity for CloudFront to S3 access.

What solution will MOST effectively reduce S3 request costs while maintaining the current architecture?

1. Enable S3 Transfer Acceleration on the origin buckets to reduce the per-request cost between CloudFront and S3, and implement S3 Intelligent-Tiering to automatically optimize storage costs.
2. Migrate the top 30% of frequently accessed video content to Amazon EFS and configure CloudFront to use a custom origin pointing to an NLB in front of EFS, keeping infrequently accessed content in S3.
3. Enable CloudFront Origin Shield in a centralized AWS Region to consolidate requests to S3, reducing redundant requests from multiple CloudFront edge locations.
4. Implement S3 Select to reduce the amount of data transferred from S3 to CloudFront by retrieving only the necessary byte ranges for adaptive bitrate streaming.

Answer & Explanation

Correct Answer: 3 - Enable CloudFront Origin Shield

Why this is correct: CloudFront Origin Shield acts as an additional caching layer between CloudFront edge locations and the S3 origin. When multiple edge locations request the same object that isn't cached, Origin Shield consolidates these into a single request to S3, dramatically reducing the total number of GET requests. Given that 30% of videos account for 95% of views, Origin Shield will cache these popular objects and serve them to multiple edge locations without repeatedly hitting S3. This can reduce origin requests by 30-60% in typical scenarios. Origin Shield integrates seamlessly with the existing CloudFront distribution and maintains all current security configurations including origin access identity and signed URLs. There are no changes required to the S3 bucket structure or CloudFront distribution behavior, and user experience remains unchanged. The cost of Origin Shield ($0.005-0.02 per 10,000 requests depending on region) is significantly lower than the avoided S3 GET request costs ($0.0004 per request × millions of requests).

Why the other options are wrong:

• Option 1: S3 Transfer Acceleration is designed to accelerate uploads and long-distance transfers to S3 from clients, not to reduce request costs between CloudFront and S3. CloudFront already accesses S3 through AWS's internal network with optimal performance. Transfer Acceleration would actually increase costs without providing any benefit for CloudFront-to-S3 requests. S3 Intelligent-Tiering optimizes storage costs, not request costs, and does nothing to reduce the number of GET requests being made.
• Option 2: Migrating content to Amazon EFS introduces massive complexity and operational overhead without addressing the core issue. EFS is not optimized for CloudFront origin use cases-it would require EC2 instances or containers to serve as intermediaries (via NLB), adding compute costs, latency, and management burden. This architecture would actually increase costs rather than reduce them. Additionally, splitting content across two different origin types (EFS and S3) complicates content management, invalidation strategies, and monitoring. CloudFront's origin access identity only works with S3, so this would require completely redesigning the security model.
• Option 4: S3 Select is designed for querying and filtering structured data (CSV, JSON, Parquet) within S3 objects, not for retrieving byte ranges of video files. CloudFront already handles HTTP range requests efficiently for adaptive bitrate streaming-these range requests are still full GET requests to S3 from CloudFront's perspective and do not reduce request costs. S3 Select would not function with video file formats and would not reduce the number of GET requests CloudFront makes to S3.

Key Insight: Understanding that the cost problem stems from redundant requests across multiple CloudFront edge locations is critical. Origin Shield specifically addresses cache misses at the edge by providing a centralized caching layer closer to the origin. Many candidates focus on storage class optimization (Intelligent-Tiering) when the actual problem is request costs, not storage costs. The question specifically states request costs are the issue, not storage costs, requiring careful attention to what constraint is actually being addressed.

Case Study 4

An e-commerce platform runs a PostgreSQL database on Amazon RDS that stores product catalog information, user accounts, and transaction history. The database has grown to 18 TB and is experiencing increasing I/O contention during peak shopping periods. The application performs complex joins across multiple tables for personalized product recommendations, and query performance has degraded significantly. Database administrators have identified that approximately 4 TB of data consists of product images stored as binary large objects (BLOBs) directly in the database. These images are displayed on product pages and are retrieved every time a product query is executed. The company wants to improve database performance and reduce RDS instance costs without requiring a complete application rewrite. The solution must maintain transactional consistency between product records and their associated images, and should minimize changes to existing database queries.

Which solution will MOST effectively address the performance issues while minimizing application changes?

1. Modify the database schema to replace BLOB columns with S3 object keys, store images in Amazon S3, and update application logic to retrieve images directly from S3 using presigned URLs while maintaining product metadata in RDS.
2. Enable RDS Performance Insights and create read replicas to distribute the query load, then implement ElastiCache for Redis to cache frequently accessed product images and reduce database load.
3. Migrate the database to Amazon Aurora PostgreSQL, enable Aurora Auto Scaling for read replicas, and use Aurora's storage auto-scaling feature to handle the I/O contention without schema changes.
4. Create an Amazon DynamoDB table to store product images with product IDs as partition keys, implement DynamoDB Streams to keep images synchronized with RDS, and modify the application to retrieve images from DynamoDB.

Answer & Explanation

Correct Answer: 1 - Store images in S3 with object keys in RDS

Why this is correct: Storing large binary objects directly in relational databases is an anti-pattern that causes multiple problems: inflated database size, increased backup/restore times, buffer pool pollution, and I/O contention. By moving the 4 TB of image data to Amazon S3 and storing only object keys (strings) in the database, the RDS instance immediately benefits from reduced storage (18 TB → 14 TB), dramatically reduced I/O operations (no more BLOB reads), and improved query performance (smaller result sets, better cache utilization). Presigned URLs allow the application to securely retrieve images directly from S3, bypassing the database entirely for image access. This approach maintains transactional consistency because the database still contains the authoritative product records with S3 references-if a product is deleted, the application can delete the corresponding S3 object. Application changes are minimal: modify the data access layer to retrieve the S3 key and generate presigned URLs instead of reading BLOB data. The database schema change (BLOB column to VARCHAR for S3 keys) is straightforward and doesn't affect the rest of the schema or query logic.

Why the other options are wrong:

• Option 2: While read replicas can help distribute read query load, they do not address the root cause of the problem: storing 4 TB of binary image data in the database itself. Every read replica would still need to replicate and store the full 18 TB including all BLOB data, multiplying storage costs rather than reducing them. ElastiCache for Redis could cache some images, but caching 4 TB of image data in memory would be prohibitively expensive (Redis pricing is based on memory size). This solution also adds significant operational complexity without addressing the fundamental architectural issue. RDS Performance Insights helps identify performance bottlenecks but does not solve them.
• Option 3: Amazon Aurora PostgreSQL does offer better performance than standard RDS PostgreSQL due to its distributed storage architecture and read replica capabilities. However, Aurora still suffers from the same fundamental problem when storing large BLOBs: the data must be replicated across storage nodes, buffer pool memory is wasted on binary data, and I/O operations still occur for BLOB retrieval. Aurora's storage auto-scaling addresses capacity but not the performance impact of inefficient data storage patterns. This option is more expensive than RDS (Aurora costs more per instance hour) without solving the core architectural issue. Migration to Aurora also represents significant effort and risk compared to the simpler schema modification in Option 1.
• Option 4: Moving images to DynamoDB and using DynamoDB Streams for synchronization introduces unnecessary complexity and eventual consistency challenges. DynamoDB has a 400 KB item size limit, so images would need to be chunked across multiple items or stored in S3 anyway (making DynamoDB an unnecessary intermediary). DynamoDB Streams provide change data capture, but maintaining bidirectional synchronization between RDS and DynamoDB for transactional consistency is complex and error-prone. This architecture also requires more significant application changes than Option 1, contradicting the requirement to minimize application modifications. If images are being moved out of the database anyway, storing them directly in S3 is simpler and more cost-effective than introducing DynamoDB as an intermediary.

Key Insight: This question tests the understanding that relational databases should store structured, relational data, not large binary objects. Many candidates might gravitate toward Aurora or caching solutions without recognizing that the fundamental architecture is flawed. The key phrase "4 TB of data consists of product images stored as binary large objects" is the critical indicator that the database schema itself is the problem, not database engine choice or caching strategy. Separating blob storage from transactional data storage is a fundamental architectural principle.

Case Study 5

A genomics research organization processes DNA sequencing data submitted by laboratories worldwide. Raw sequencing files (FASTQ format) range from 50 GB to 500 GB per sample and must be uploaded directly by external laboratories through a secure, authenticated mechanism. Once uploaded, files are processed by a compute cluster that runs alignment and variant calling pipelines, typically requiring 12-48 hours per sample. During processing, files are accessed sequentially with high throughput (multiple GB/s) but only once. After processing is complete, the raw files must be retained for 2 years for audit purposes but are never accessed again unless a reanalysis is specifically requested (less than 1% of files annually). The organization currently receives 200-400 new samples per week. The security team requires that files must be encrypted at rest and in transit, and that external laboratories should not have direct AWS console or API access. The organization wants to minimize storage costs while maintaining the ability to process new submissions efficiently.

Which combination of solutions will meet these requirements MOST cost-effectively? (Select TWO)

1. Configure S3 Transfer Acceleration for the input bucket to enable laboratories to upload large files efficiently, with S3 default encryption enabled using SSE-S3.
2. Generate presigned POST URLs with time-limited expiration for external laboratories to upload files directly to S3, with server-side encryption enforced through bucket policies.
3. Implement an S3 Lifecycle policy that transitions raw files to S3 Glacier Deep Archive immediately after the processing pipeline marks them as complete using object tags.
4. Store raw files in S3 Standard during processing, then use an S3 Lifecycle policy to transition files to S3 Glacier Flexible Retrieval 7 days after upload, with expiration after 2 years.
5. Configure AWS Transfer Family SFTP endpoint with authentication via AWS Secrets Manager, storing uploaded files directly in S3 Standard with automatic transition to S3 Glacier Deep Archive after processing.

Answer & Explanation

Correct Answer: 2 and 3

Why these are correct:

Option 2 (Presigned POST URLs): Presigned POST URLs allow external laboratories to upload files directly to S3 without requiring AWS credentials, IAM users, or console access. The organization generates time-limited URLs (e.g., valid for 24 hours) that grant upload permission to specific S3 paths. This meets the security requirement that external users should not have direct AWS access. Presigned URLs are generated programmatically by the organization using their own credentials, providing complete control over upload permissions. Bucket policies can enforce server-side encryption by rejecting uploads that don't include encryption headers, ensuring all files are encrypted at rest. TLS ensures encryption in transit. This approach is cost-effective (no additional infrastructure) and secure.

Option 3 (Lifecycle with object tags to Glacier Deep Archive): Since files are never accessed after processing except for rare reanalysis requests (1% annually), S3 Glacier Deep Archive provides the lowest storage cost ($0.00099 per GB-month vs. $0.023 for S3 Standard). Using object tags to trigger lifecycle transitions allows precise control-the processing pipeline tags files as "processing-complete" when done, and the lifecycle policy immediately transitions them to Deep Archive. This minimizes the time files spend in expensive S3 Standard storage while ensuring files remain in high-performance storage during the 12-48 hour processing window. The 12-48 hour retrieval time for Deep Archive is acceptable given the 1% reanalysis rate, and retrieval can be planned in advance if needed.

Why the other options are wrong:

• Option 1: S3 Transfer Acceleration incurs additional per-GB transfer costs ($0.04-0.08 per GB) that are unnecessary for large file uploads. While Transfer Acceleration can improve upload speeds for geographically distant users, the primary bottleneck for 50-500 GB files is typically the laboratory's upload bandwidth, not S3's ingestion capacity. Presigned URLs with direct S3 uploads provide sufficient performance for this use case without the additional cost. Transfer Acceleration might be appropriate if upload performance issues were explicitly stated, but cost-effectiveness is the primary constraint here.
• Option 4: Transitioning to S3 Glacier Flexible Retrieval after 7 days is suboptimal because many files will complete processing within 12-48 hours, meaning they would spend 5+ unnecessary days in S3 Standard storage before transitioning. This wastes storage costs compared to immediate transition after processing completion (Option 3). Additionally, Glacier Flexible Retrieval ($0.0036 per GB-month) is more expensive than Glacier Deep Archive ($0.00099 per GB-month), and the faster retrieval time (minutes vs. hours) provides no benefit for files that are virtually never accessed. The 7-day fixed period ignores the actual processing completion time, which varies per sample.
• Option 5: AWS Transfer Family SFTP is designed for legacy applications requiring SFTP protocol compatibility. It incurs significant costs: $0.30 per hour per endpoint (~$216/month) plus $0.04 per GB transferred. Given that the organization receives 200-400 samples per week averaging 50-500 GB each, this could represent 10-200 TB monthly, resulting in $400-8,000 in data transfer charges alone. SFTP adds no security benefit over presigned URLs with HTTPS (both use TLS), and external laboratories would need to configure SFTP clients instead of using simple HTTP upload mechanisms. This option is significantly more expensive and operationally complex than Option 2 without providing commensurate benefits.

Key Insight: This question tests understanding of secure external upload patterns without granting AWS access (presigned URLs), and lifecycle optimization based on actual access patterns rather than fixed time periods (object tag-based transitions). Many candidates might select Transfer Acceleration thinking it's always beneficial for large files, or might choose fixed time-based lifecycle transitions without recognizing that processing completion times vary. The combination of "never accessed again except 1% annually" and "cost-effectively" clearly points to Glacier Deep Archive, while "external laboratories should not have direct AWS access" eliminates options requiring IAM credentials or AWS service access.

Case Study 6

A logistics company operates a fleet management system that tracks 50,000 delivery vehicles in real-time. Each vehicle transmits telemetry data (GPS coordinates, speed, fuel level, engine diagnostics) every 10 seconds, resulting in approximately 400 million data points daily. The data is currently stored in Amazon DynamoDB and is used for three purposes: real-time dashboard visualization (last 2 hours of data), route optimization analysis (last 30 days), and historical trend analysis (all data). The DynamoDB table has grown to 85 TB, and monthly costs have reached $42,000 primarily due to read capacity units consumed by the historical analysis queries. The data analytics team runs ad-hoc queries using Amazon Athena to analyze historical patterns but reports slow performance and high costs. The architecture team has determined that 95% of read capacity is consumed by queries accessing data older than 30 days, while real-time and recent data queries account for only 5% of reads. The company wants to optimize costs and query performance while maintaining the existing real-time dashboard functionality without changes to the application code that queries DynamoDB for current data.

What is the MOST operationally efficient solution that addresses the cost and performance issues?

1. Enable DynamoDB Time to Live (TTL) to automatically delete records older than 30 days, implement DynamoDB Streams with a Lambda function to archive deleted items to S3 in Parquet format, and configure Athena to query the S3-based historical data lake.
2. Implement DynamoDB Auto Scaling for read capacity to handle query spikes more efficiently, create Global Secondary Indexes optimized for historical queries, and enable DynamoDB DAX for caching frequently accessed historical data.
3. Create an AWS Glue ETL job that runs daily to move records older than 30 days from DynamoDB to Amazon Redshift, maintain recent data in DynamoDB for real-time queries, and use Redshift Spectrum for analyzing historical data in S3.
4. Enable point-in-time recovery for DynamoDB, use AWS Database Migration Service to continuously replicate data to Amazon Aurora PostgreSQL for historical analysis, and query Aurora using read replicas while maintaining DynamoDB for real-time operations.

Answer & Explanation

Correct Answer: 1 - DynamoDB TTL with Stream-based archival to S3 and Athena

Why this is correct: This solution elegantly separates hot data (last 30 days) from cold data (older than 30 days) using fundamentally different storage and query mechanisms optimized for each use case. DynamoDB TTL automatically expires and deletes records older than 30 days at no additional cost, reducing the DynamoDB table size from 85 TB to approximately 8-10 TB (30 days of data). This dramatically reduces DynamoDB storage costs and improves query performance for real-time and route optimization queries. DynamoDB Streams captures the deleted items before removal, triggering Lambda functions that transform the data into Parquet format (columnar, compressed) and archive it to S3. Amazon Athena can then efficiently query the S3-based historical data using standard SQL, with query costs based on data scanned (Parquet's compression and columnar format minimize scan costs). This architecture maintains the real-time dashboard functionality unchanged (still queries DynamoDB for recent data) while providing cost-effective historical analysis through Athena. The solution is operationally efficient because TTL and Streams are managed services requiring no infrastructure management, and Lambda scales automatically to handle the archival workload.

Why the other options are wrong:

• Option 2: DynamoDB Auto Scaling adjusts capacity based on utilization but does not address the fundamental problem: DynamoDB is not cost-effective for infrequently accessed historical data at 85 TB scale. Auto Scaling would still maintain high provisioned capacity to serve the historical queries, resulting in continued high costs. Creating Global Secondary Indexes for historical queries actually increases costs (indexes are stored separately and consume additional storage and capacity units) and does not improve query performance for ad-hoc analytical queries spanning large time ranges-DynamoDB is optimized for key-value lookups, not analytical scans. DynamoDB DAX is an in-memory cache designed for high-frequency read operations against the same items (e.g., product catalog lookups), not for ad-hoc analytical queries across different historical time periods. DAX would provide no benefit for historical trend analysis queries that access different data each time and would add significant cost (~$0.25-2.00 per hour per node).
• Option 3: While using AWS Glue to move data to a data warehouse is architecturally sound, introducing Amazon Redshift adds significant operational overhead and cost that is not justified by the use case. Redshift requires cluster provisioning, scaling, maintenance, and costs approximately $0.25 per hour per node minimum (for dc2.large), or $180+ monthly for even a small cluster, plus additional storage costs. The data analytics team is already using Athena for ad-hoc queries, suggesting they are comfortable with serverless SQL query tools. Redshift Spectrum queries data in S3 but still requires a Redshift cluster to run, making it more expensive than native Athena for sporadic analytical workloads. If continuous, complex analytical workloads were required, Redshift might be justified, but the question describes ad-hoc queries, making serverless Athena more appropriate and cost-effective.
• Option 4: Using AWS Database Migration Service (DMS) to continuously replicate 85 TB of data to Amazon Aurora PostgreSQL introduces enormous complexity, cost, and operational overhead. DMS charges for replication instance hours (~$0.036-0.154 per hour depending on instance type) plus data transfer. Aurora would need to store the full 85 TB dataset, with storage costs of $0.10 per GB-month ($8,500 monthly for storage alone), plus instance costs, plus read replica costs. Aurora is a transactional database optimized for OLTP workloads, not analytical queries scanning large historical datasets-performance for historical trend analysis would likely be poor compared to purpose-built analytical tools like Athena. This solution is operationally complex (maintaining DMS replication, managing Aurora clusters) and extremely expensive compared to the S3+Athena approach. Point-in-time recovery is a backup/disaster recovery feature and provides no benefit for this use case.

Key Insight: The key to this question is recognizing the anti-pattern: using DynamoDB to store and query 85 TB of mostly cold data. DynamoDB excels at high-speed transactional operations on hot data but becomes prohibitively expensive for large volumes of infrequently accessed data. The solution requires separating hot and cold data paths: keep recent data in DynamoDB for transactional queries, move historical data to S3 for analytical queries. TTL + Streams + Lambda provides an automated, serverless, operationally efficient mechanism for this separation. Many candidates might focus on optimizing DynamoDB (Auto Scaling, DAX) without recognizing that the fundamental storage choice is wrong for the access pattern.

Case Study 7

A research institution runs computational fluid dynamics simulations on AWS that generate checkpoint files every 15 minutes during multi-day simulation runs. Each checkpoint file is approximately 200 GB and represents the complete state of the simulation at that point in time. The simulation cluster consists of 500 tightly coupled EC2 instances using MPI (Message Passing Interface) for inter-process communication. All instances must be able to write checkpoint files simultaneously with minimal latency impact on the simulation. If a simulation fails, it can be restarted from the most recent checkpoint file. Once a simulation completes successfully, all intermediate checkpoint files are deleted, and only the final result files are retained. The research team has observed that checkpoint write operations are creating I/O bottlenecks, occasionally causing simulation slowdowns of 15-20%. The team needs a storage solution that can handle 500 simultaneous writes of 200 GB files (100 TB aggregate per checkpoint cycle) without impacting simulation performance, while minimizing storage costs for the temporary checkpoint data.

Which storage solution will BEST meet these requirements?

1. Deploy Amazon FSx for Lustre with a Scratch deployment type, configure the simulation to write checkpoint files to the Lustre file system, and delete checkpoint files when simulations complete successfully.
2. Configure each EC2 instance with a dedicated instance store volume for local checkpoint storage, use a Lambda function triggered by CloudWatch Events to aggregate checkpoint files to S3 after each cycle, and delete local files after aggregation.
3. Create an Amazon EFS file system with Provisioned Throughput mode configured for the peak write bandwidth, enable lifecycle management to transition checkpoint files to EFS Infrequent Access after 1 day, and delete files when simulations complete.
4. Provision io2 Block Express EBS volumes with Multi-Attach enabled for every 16 instances, configure application-level striping across volumes for checkpoint writes, and use S3 lifecycle policies to delete checkpoint files after 7 days.

Answer & Explanation

Correct Answer: 1 - Amazon FSx for Lustre with Scratch deployment type

Why this is correct: Amazon FSx for Lustre Scratch file systems are specifically designed for temporary, high-performance storage workloads where data persistence is not required beyond the life of the file system. Scratch file systems provide the highest performance-to-cost ratio among managed file systems on AWS, delivering up to hundreds of GB/s throughput and millions of IOPS-sufficient to handle 500 simultaneous 200 GB checkpoint writes without creating I/O bottlenecks. Lustre's parallel distributed architecture allows all 500 MPI-coupled instances to write simultaneously to the shared namespace without contention or performance degradation. The Scratch deployment is approximately 50% less expensive than Persistent deployment types because it does not provide data replication or high availability guarantees, which is acceptable for checkpoint files that are temporary by nature and can be regenerated if lost. Since checkpoint files are deleted after successful simulation completion, persistence is unnecessary. The file system can be accessed from all instances simultaneously using POSIX semantics, which integrates seamlessly with HPC simulation applications that typically expect shared file system behavior.

Why the other options are wrong:

• Option 2: Instance store volumes provide excellent local I/O performance and would eliminate network bottlenecks for checkpoint writes. However, this approach has a critical flaw for checkpoint-based fault tolerance: if an instance fails (hardware failure, Spot interruption, etc.), the checkpoint files stored on that instance's local storage are lost. In an MPI simulation with 500 tightly coupled instances, all instances must coordinate from the same checkpoint state-losing even one instance's checkpoint data makes the entire checkpoint unusable for recovery. The simulation would need to restart from an earlier checkpoint or from the beginning, defeating the purpose of checkpointing. Additionally, Lambda functions have execution time limits (15 minutes) and payload limits that make them unsuitable for aggregating 100 TB of data every 15 minutes. This architecture would require complex orchestration and likely wouldn't work at the required scale and frequency.
• Option 3: Amazon EFS with Provisioned Throughput can deliver high aggregate throughput, but at significant cost. To support 100 TB written every 15 minutes (approximately 110 GB/s sustained throughput), EFS would require provisioning ~110,000 MB/s throughput at $6 per MB/s-month, resulting in ~$660,000 monthly just for provisioned throughput, far exceeding FSx for Lustre costs. Even with Bursting throughput mode, EFS would struggle to deliver consistent performance for this write pattern. Additionally, EFS lifecycle management transitions to Infrequent Access storage class but files remain on the file system-this doesn't reduce costs for temporary checkpoint files that are deleted within hours or days. EFS is designed for persistent, shared file storage across workloads, not temporary high-performance scratch space for HPC checkpoints.
• Option 4: EBS Multi-Attach only supports attaching a single volume to up to 16 instances within the same Availability Zone. For 500 instances, this would require at least 32 separate volumes (500/16), and the application would need complex logic to stripe data across volumes and coordinate which instances write to which volumes. io2 Block Express volumes can deliver 256,000 IOPS and 4,000 MB/s per volume, but 32 volumes × 4,000 MB/s = 128 GB/s theoretical maximum-barely sufficient, with no headroom for overhead or contention. This approach adds enormous operational complexity (managing 32+ volumes, implementing application-level striping, handling volume failures) compared to a shared file system. The Multi-Attach limitation to 16 instances makes this fundamentally unsuitable for 500-instance tightly coupled HPC workloads. S3 lifecycle policies are irrelevant because checkpoint files need to be deleted immediately after simulation completion, not retained for 7 days.

Key Insight: This question tests understanding of HPC storage requirements: extremely high concurrent throughput, shared access across hundreds of instances, and temporary data lifecycle. The key differentiator is recognizing that checkpoint files are ephemeral (deleted after simulation completion) and that Lustre Scratch file systems are purpose-built and cost-optimized for exactly this use case. Many candidates might consider EFS as the default shared file system, but EFS cannot deliver the required performance at acceptable cost for extreme HPC workloads. The "temporary/scratch" nature of the data is the critical hint pointing to FSx for Lustre Scratch over Persistent deployment types or other storage services.

Case Study 8

A global pharmaceutical company is migrating a legacy drug discovery application from an on-premises data center to AWS. The application uses a commercial scientific database that stores molecular structure data and requires block-level storage with consistent low-latency access. The database currently resides on a dedicated storage array providing 200 TB capacity with 100,000 IOPS performance. The company's migration strategy requires a phased approach: the application will run simultaneously in both on-premises and AWS environments for 6 months during validation, with the on-premises database as the primary write location and the AWS database receiving real-time replication for read-only queries and disaster recovery. After validation, AWS will become the primary environment. The network team has established a 10 Gbps AWS Direct Connect connection. The security team requires that all data must be encrypted at rest and in transit, and that database snapshots must be copied to a secondary AWS Region for disaster recovery. The solution must minimize data synchronization latency between on-premises and AWS during the hybrid phase.

Which solution BEST meets these requirements for the hybrid migration phase?

1. Deploy AWS Storage Gateway Volume Gateway in cached mode in the on-premises data center, configure the scientific database to write to the cached volumes, with data automatically synchronized to S3 and exposed as EBS volumes to the AWS application instances.
2. Provision io2 EBS volumes in AWS with 100,000 IOPS capacity, use the database vendor's native replication feature over the Direct Connect connection to replicate from on-premises to AWS, enable EBS encryption and automated snapshots with cross-region copy enabled.
3. Deploy AWS Storage Gateway File Gateway on-premises with the molecular structure data stored as files, use AWS DataSync to continuously synchronize data to Amazon FSx for Lustre in AWS, and configure the AWS application to access FSx for Lustre.
4. Implement AWS Database Migration Service with continuous replication from the on-premises database to Amazon RDS in AWS, use RDS read replicas for query workloads, and enable automated backups with cross-region snapshot copy.

Answer & Explanation

Correct Answer: 2 - io2 EBS volumes with native database replication over Direct Connect

Why this is correct: This solution properly addresses the hybrid migration requirements by maintaining the existing database architecture while extending it to AWS. io2 EBS volumes provide block-level storage that matches the on-premises storage array's performance characteristics, capable of delivering 100,000 IOPS (io2 supports up to 64,000 IOPS per volume, so multiple volumes or a single volume with Provisioned IOPS can meet the requirement, or io2 Block Express can deliver 256,000 IOPS for larger volumes). Using the database vendor's native replication mechanism preserves the database's transactional integrity and leverages tested, supported replication technology rather than introducing third-party solutions. The AWS Direct Connect 10 Gbps connection provides low-latency, dedicated bandwidth between on-premises and AWS, ensuring minimal synchronization latency for real-time replication. EBS encryption at rest meets security requirements, and the Direct Connect connection (not traversing the public internet) provides secure transit. Automated EBS snapshots with cross-region copy fulfill the disaster recovery requirement for secondary region backup. This approach maintains the database at both locations as actual database instances, allowing the application to perform real read-only queries in AWS during validation rather than just accessing backup copies.

Why the other options are wrong:

• Option 1: AWS Storage Gateway Volume Gateway in cached mode is designed for scenarios where a primary copy of data resides in AWS (S3) with frequently accessed data cached on-premises. The question describes the opposite: on-premises is the primary write location during the 6-month validation phase. Using cached mode would introduce significant latency because writes would need to traverse the Direct Connect connection to S3 before acknowledging, impacting the scientific database's performance. Additionally, Volume Gateway exposes storage as iSCSI volumes, but those volumes appear on-premises, not directly in AWS-the AWS application would need to access data through EBS volumes created from snapshots or through other mechanisms, adding complexity. This architecture is backwards for the described use case and would create performance issues for the on-premises database workload.
• Option 3: Storage Gateway File Gateway provides SMB/NFS file share access to S3 object storage, which is fundamentally incompatible with a database requiring block-level storage. Databases need direct block storage (like EBS) for data files and transaction logs to maintain ACID properties; they cannot function correctly on top of file protocols or object storage. AWS DataSync synchronizes file data between storage systems but introduces latency (it's designed for scheduled periodic sync, not real-time continuous replication) and does not maintain database consistency (it copies files, not database transactions). Amazon FSx for Lustre is a high-performance file system for HPC workloads, not a database storage platform. This entire approach misunderstands the storage requirements of a transactional database and would not work.
• Option 4: AWS Database Migration Service (DMS) is a migration tool designed to move data between database engines, including continuous change data capture (CDC) replication. However, the question specifies a "commercial scientific database"-DMS supports common database engines (Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, etc.) but may not support specialized scientific databases. More importantly, DMS is designed for migration to AWS-managed databases like RDS, but Amazon RDS only supports specific database engines (Oracle, SQL Server, MySQL, PostgreSQL, MariaDB, Aurora). If the commercial scientific database is a specialized product (e.g., Cambridge Structural Database, Schrödinger Suite, OpenEye toolkits), it would not be available in RDS and would need to run on EC2 instances with EBS storage, making DMS an inappropriate choice. Even if the database were RDS-compatible, using DMS for a 6-month hybrid operational period is using a migration tool for ongoing operational replication, which is outside its primary design intent. Option 2's native database replication is more reliable and appropriate for sustained operational use.

Key Insight: This question tests the understanding of hybrid migration patterns and the importance of matching storage type (block vs. file vs. object) to application requirements. The critical constraint is that the database requires "block-level storage with consistent low-latency access" during a sustained 6-month operational period, not a one-time migration. Native database replication over Direct Connect with EBS storage is the standard, reliable pattern for hybrid database architectures. Storage Gateway options seem AWS-native and tempting, but understanding their actual architectural direction (cached mode means primary data in AWS, not on-premises) is essential to avoiding incorrect choices.

Case Study 9

A financial services company operates a document management system that stores regulatory filings, audit reports, and compliance documentation. The system currently stores 850 TB of PDF, Word, and Excel documents in Amazon S3 Standard. The company's legal team has identified that the SEC recently updated regulations requiring that all financial documents must be retained for 7 years and must remain unmodifiable after creation. The company has discovered that several documents were inadvertently deleted by users with overly broad IAM permissions during the past year, causing compliance concerns. Additionally, during a recent audit, the auditing firm requested proof that documents have not been altered since their original filing date. The company needs to implement a solution that prevents document deletion or modification for the required retention period, provides cryptographic proof of document integrity, and does not require changes to the existing application that uploads and retrieves documents from S3 using standard GET and PUT operations.

Which solution will meet these compliance requirements with the LEAST operational complexity?

1. Enable S3 Versioning on the bucket, implement S3 Lifecycle policies to prevent deletion of versions during the 7-year period, enable MFA Delete to require multi-factor authentication for deletion operations, and use S3 access logs to track all access to documents.
2. Enable S3 Object Lock in compliance mode with a retention period of 7 years, configure default retention settings at the bucket level, and enable S3 Inventory to generate reports showing object retention status for audit purposes.
3. Implement S3 bucket policies that deny DeleteObject and PutObject operations from all principals except a dedicated backup role, enable S3 Versioning to maintain historical versions, and use AWS CloudTrail with log file validation to provide cryptographic proof of integrity.
4. Migrate documents to Amazon S3 Glacier Vault Lock, configure a vault lock policy with a 7-year retention period, use AWS Backup to manage document lifecycle, and implement a Lambda function to validate document integrity using checksums stored in DynamoDB.

Answer & Explanation

Correct Answer: 2 - Enable S3 Object Lock in compliance mode

Why this is correct: S3 Object Lock is specifically designed for regulatory compliance scenarios requiring WORM (Write Once, Read Many) capabilities. Compliance mode ensures that objects cannot be deleted or overwritten by any user, including the AWS account root user, until the retention period expires-this provides the legally defensible immutability required for regulatory filings. Setting a 7-year retention period directly addresses the SEC requirement. Configuring default retention at the bucket level automatically applies protection to all newly uploaded objects without requiring application changes (the existing PUT operations work unchanged). S3 Object Lock internally uses object version IDs and metadata to enforce retention, and each object version has a cryptographically signed ETag that provides integrity verification. The S3 Inventory report can demonstrate to auditors which objects are under retention protection and when retention expires. This solution requires minimal configuration (enable Object Lock and set default retention), has no ongoing operational overhead, and does not require application changes since S3's standard API remains compatible.

Why the other options are wrong:

• Option 1: While S3 Versioning preserves all versions of objects and protects against accidental deletion (deleted objects become delete markers rather than being permanently removed), versioning alone does not prevent intentional deletion of all versions. MFA Delete adds a layer of protection by requiring multi-factor authentication to permanently delete versions or disable versioning, but it still allows deletion by authorized users with MFA devices-it's not a true WORM solution that prevents all deletion during a retention period. S3 Lifecycle policies cannot "prevent deletion"-lifecycle policies can transition or expire objects but cannot enforce retention periods that prevent user-initiated deletions. S3 access logs provide audit trails but do not offer cryptographic proof of integrity (they show access patterns, not document integrity verification). This combination provides security layers but does not meet the regulatory requirement for true immutability and cryptographic proof of unaltered documents.
• Option 3: Implementing bucket policies to deny DeleteObject and PutObject can prevent accidental deletions by most users, but bucket policies can be modified by users with sufficient IAM permissions (e.g., administrators or root users). This does not provide the same legally defensible immutability as Object Lock, which cannot be bypassed even by root. The approach of maintaining a "dedicated backup role" creates operational complexity and exception management that increases risk. CloudTrail log file validation uses digital signatures to ensure CloudTrail logs themselves haven't been tampered with, but it does not provide cryptographic proof that the actual S3 document objects haven't been modified-it only proves that the audit trail of API calls is valid. This distinction is critical: CloudTrail validates the log integrity, not the document integrity. For document integrity, S3 Object Lock or external checksum validation would be needed.
• Option 4: Amazon S3 Glacier Vault Lock does provide true WORM capabilities with regulatory compliance features similar to S3 Object Lock. However, moving documents from S3 to Glacier Vaults requires changing how the application accesses data. Glacier Vaults use a different API from S3 (Glacier API, not S3 API), and retrieving objects requires restore operations that take hours, fundamentally breaking the existing application that expects immediate access via standard S3 GET operations. The question explicitly states the solution "does not require changes to the existing application that uploads and retrieves documents from S3 using standard GET and PUT operations." Additionally, implementing Lambda functions to validate checksums stored in DynamoDB adds significant operational complexity (managing Lambda code, DynamoDB table, handling failures) when S3 Object Lock provides integrity verification natively. AWS Backup for Glacier adds further unnecessary complexity.

Key Insight: This question tests knowledge of compliance and data governance features, specifically S3 Object Lock versus other protective mechanisms. The key differentiator is understanding that regulatory immutability requirements (cannot be modified or deleted by anyone, including administrators) require purpose-built WORM features like S3 Object Lock or Glacier Vault Lock-general security controls like IAM policies, MFA Delete, or bucket policies can be bypassed by administrators and don't provide legally defensible immutability. The constraint "does not require changes to the existing application" eliminates Glacier Vault Lock (different API) and points to S3 Object Lock (transparent to applications using standard S3 API).

Case Study 10

An autonomous vehicle company collects sensor data from test vehicles operating in multiple cities. Each vehicle generates approximately 5 TB of raw sensor data daily (LiDAR, camera, radar, GPS) that must be uploaded to AWS for processing and machine learning model training. The company operates 120 test vehicles, resulting in 600 TB of new data daily. Data is collected on local storage in the vehicles during daily test runs, and vehicles return to regional depot locations each evening where high-speed internet connections (1-10 Gbps) are available for data upload. The machine learning team requires that data must be available in AWS within 24 hours of collection to maintain training pipeline schedules. Due to the rapidly expanding vehicle fleet (projected to reach 500 vehicles within 12 months), the company wants a solution that scales easily without requiring significant infrastructure investment at each depot location. The current approach of using aws s3 sync commands from depot servers is becoming operationally burdensome and unreliable, with frequent upload failures requiring manual intervention. The solution must handle upload failures gracefully with automatic retry mechanisms and provide visibility into upload progress and status across all depot locations.

Which solution provides the MOST scalable and operationally efficient approach for uploading vehicle sensor data?

1. Deploy AWS DataSync agents as virtual machines at each depot location, configure DataSync tasks to transfer vehicle data to S3, enable CloudWatch logging for monitoring, and use EventBridge rules to trigger notifications for failed transfers.
2. Deploy AWS Storage Gateway Volume Gateway at each depot location in stored mode, configure vehicles to write data to the gateway volumes throughout the day, and allow automatic background synchronization to S3 overnight.
3. Implement AWS Snow Family devices (Snowball Edge) at each depot location, configure vehicles to write data to the local Snowball storage throughout the day, and ship devices to AWS weekly for data ingestion to S3.
4. Deploy Amazon EC2 instances at each depot location running custom Python scripts using the S3 multipart upload API with exponential backoff retry logic, implement a centralized DynamoDB table to track upload status, and create a web dashboard for monitoring.

Answer & Explanation

Correct Answer: 1 - Deploy AWS DataSync agents at depot locations

Why this is correct: AWS DataSync is purpose-built for large-scale data transfer scenarios and directly addresses all the identified issues with the current approach. DataSync agents can be deployed as virtual machines at depot locations with minimal infrastructure requirements (standard virtualization platform like VMware or Hyper-V). DataSync automatically handles parallel transfers, network optimization, data integrity verification, and built-in retry logic with automatic failure recovery-eliminating the "frequent upload failures requiring manual intervention" problem. A single DataSync task can be configured per depot or per vehicle, and DataSync automatically scales to utilize available network bandwidth (1-10 Gbps) efficiently. CloudWatch integration provides centralized visibility into all transfer operations across all depot locations, with metrics for bytes transferred, files completed, and transfer errors. EventBridge rules can automatically notify operations teams of failures, enabling proactive intervention if needed. DataSync validates data integrity during transfer and provides detailed reporting, ensuring the ML team receives complete, uncorrupted data. As the fleet expands to 500 vehicles, additional DataSync agents can be deployed without architectural changes-each agent operates independently and reports to centralized CloudWatch, maintaining operational simplicity at scale.

Why the other options are wrong:

• Option 2: AWS Storage Gateway Volume Gateway in stored mode is designed for scenarios where applications need block storage with local caching and background sync to AWS, typically for continuous operational workloads. However, Volume Gateway is not optimized for the burst transfer pattern described here (5 TB per vehicle uploaded during evening hours after daily collection). Volume Gateway would require significant hardware at each depot to provide the storage capacity (120 vehicles × 5 TB = 600 TB total daily), and the "stored mode" maintains a complete local copy synchronized to S3, which is unnecessary since vehicles have local storage and depot servers only act as transfer points. More importantly, Volume Gateway is significantly more expensive and complex to deploy and manage compared to DataSync agents (Gateway requires more substantial compute and storage resources), contradicting the requirement to avoid "significant infrastructure investment at each depot location." Volume Gateway is designed for persistent workloads like file servers or database storage, not batch data transfer operations.
• Option 3: AWS Snowball Edge devices are designed for offline data transfer scenarios where network connectivity is limited, intermittent, or insufficient for transferring large datasets within required timeframes. The question explicitly states that depot locations have "high-speed internet connections (1-10 Gbps)"-sufficient bandwidth to transfer 600 TB within 24 hours (600 TB ÷ 24 hours = 25 TB/hour = 55 Gbps theoretical; with 10 Gbps connections across 12 depots, 120 Gbps total available bandwidth is more than adequate). Using Snowball devices when high-speed connectivity exists introduces unnecessary latency (shipping time), operational complexity (device management, shipping logistics), and cost (Snowball device fees, shipping costs). The 24-hour requirement can be met with network transfer, making physical device shipping inappropriate. Additionally, with 120 vehicles collecting data daily, the company would need continuous device rotation, creating enormous operational burden rather than reducing it.
• Option 4: While building a custom solution using EC2 instances with Python scripts and S3 multipart upload API is technically feasible, it directly contradicts the requirement for operational efficiency and scalability. This approach requires significant development effort (writing and testing upload scripts, retry logic, error handling), ongoing maintenance (updating code, patching EC2 instances), and operational overhead (managing EC2 instances at all depot locations, monitoring health, handling failures). As the fleet expands to 500 vehicles across potentially more depot locations, managing distributed EC2 instances and custom code becomes increasingly burdensome-exactly the kind of operational complexity the company wants to avoid. Using DynamoDB for centralized tracking and building a custom dashboard adds further development and maintenance overhead. This option represents the "build" approach when a managed service (DataSync) already provides the required functionality with lower total cost of ownership and operational burden.

Key Insight: This question tests understanding of purpose-built AWS data transfer services versus general-purpose alternatives. The key constraints are "operationally efficient," "scales easily without significant infrastructure investment," and "handle upload failures gracefully with automatic retry"-all pointing to a managed service rather than custom-built solutions or heavy infrastructure deployments. Many candidates might default to Storage Gateway because it's an AWS service, but recognizing that DataSync is specifically designed for large-scale, scheduled data transfer operations while Storage Gateway is designed for continuous hybrid storage integration is the critical distinction. The availability of sufficient network bandwidth eliminates Snow Family devices, which are for offline or bandwidth-constrained scenarios.