Which Tool Migrates 50 TB With Least Overhead?
Determine high-performing data ingestion and transformation solutions.
Design cost-optimized compute solutions.
Answer
Correct answer: C — Order an AWS Snowball Edge Storage Optimized device to ship the 50 TB and run the transformation as a serverless AWS Glue custom job in the cloud.
A company uses 50 TB of data for reporting. The company wants to move this data from on premises to AWS. A custom application in the company’s data center runs a weekly data transformation job. The company plans to pause the application until the data transfer is complete and needs to begin the transfer process as soon as possible. The data center does not have any available network bandwidth for additional workloads. A solutions architect must transfer the data and must configure the transformation job to continue to run in the AWS Cloud. Which solution will meet these requirements with the LEAST operational overhead?
Community Insight
The question tests choosing a physical data-transfer service when no network bandwidth exists, plus a serverless transformation service; the trap is assuming EC2 or a device-resident application is lower effort than a managed Glue job.
This SAA-C03 scenario asks how to move 50 TB from a bandwidth-starved data center to AWS while keeping a weekly transformation job running in the cloud with minimal operational overhead. The correct path is an AWS Snowball Edge Storage Optimized device for the transfer plus an AWS Glue custom ETL job for the transformation, because Glue is serverless and eliminates instance management.
Option D is the most-chosen wrong answer: learners reason that re-implementing the custom job in Glue is heavy lifting, but they overlook that D provisions and operates a new EC2 instance (patching, scaling, monitoring) and that its Snowball Edge compute capacity is never even used.
Community Discussion (72 comments)
Sushmita42
👍 1
Selected: D
I think the answer is D. The question has three major clues: a. 50 TB of data b. No available network bandwidth c. There is an existing custom transformation application that needs to continue running with minimum operational overhead They point to Snowball Edge + EC2. With D, the application can run on EC2, allowing the company to preserve the existing application rather than rewriting it as an AWS Glue job. The Snowball Edge device with EC2 compute also allows compute workloads to run locally while the data is being transferred.
46e1a46
👍 1
Selected: C
A - Requires network bandwidth, which the data center doesn't have B- Snowcone only holds 8TB D- Running the original custom application on EC2 keeps all the operational overhead of maintaining custom code, instances, and infrastructure. C - Glue is fully managed and has lower overhead
0bf2fba
👍 2
Selected: D
I'll go with D. Option C is very close but AWS Glue requires rebuilding the transformation logic, which adds operational effort compared to reusing the existing app.
kaleido
👍 1
Selected: C
If the data transform runs in the Snowball edge device, does that count as "running on the AWS cloud"? Honest question.
c12ab95
👍 1
Selected: D
Option Shortcoming A AWS DataSync requires network bandwidth, which is unavailable. B Snowcone’s maximum capacity (14 TB SSD) is insufficient for 50 TB. C AWS Glue would require rewriting the custom application, increasing operational overhead. Option D minimizes operational overhead by leveraging Snowball for offline transfer and EC2 for running the existing application, ensuring a seamless transition to AWS.
zdi561
👍 1
Selected: C
One requirement is to run transformation with the data in aws, that is the job of glue
architect_kags
👍 3
Selected: D
Since the transformation application already there, Snowball Edge devices with compute capability allow to run applications directly on the device. This means the transformation job can start locally on the Snowball Edge device if needed or directly after the data transfer to AWS, minimizing delays. AWS Glue for transformation adds additional refactoring work and operational overhead.
tom_cruise
👍 2
Selected: D
The only way C can work is by using this: Amazon S3 adapter — Use for programmatic data transfer in to and out of AWS using the Amazon S3 API for Snowball Edge, but it is not indicated in the answer. If it includes the step to transfer the data from the Snowball to S3, then C would be a better answer.
0de7d1b
👍 2
Selected: D
Application still need EC2 instance along data transfer with Snowball
PaulGa
👍 3
Selected: D
Ans D - but I suspect it should be Ans C because, as stated by 123jhlo (1yr 11mth ago), D is not serverless: "C. Order an AWS Snowball Edge Storage Optimized device. Copy the data to the device. Create a custom transformation job by using AWS Glue. - SnowBall can store 80TB (ok), takes around 1 week to move the device (faster than A), and AWS Glue allows to do ETL jobs." D. Order an AWS Snowball Edge Storage Optimized device that includes Amazon EC2 compute. Copy the data to the device. Create a new EC2 instance on AWS to run the transformation application. - Same as C, but the ETL job requires the deployment/configuration/maintenance of an EC2 instance, while Glue is serverless. This means D has more operational overhead than C."
bignatov
👍 3
Selected: D
A and D are wrong. D is the correct answer. Why not C: AWS Snowball Edge is a physical device designed for transferring large amounts of data to and from AWS. It includes some compute capabilities, such as running AWS Lambda functions, AWS IoT Greengrass, and EC2 instances, but it does not support AWS Glue. AWS Glue is a fully managed ETL (Extract, Transform, Load) service that runs within the AWS Cloud. It is designed to work with data stored in AWS services like Amazon S3, Amazon RDS, and Amazon Redshift, among others. AWS Glue is not available on edge devices like Snowball Edge.
Lexxo
👍 1
Yes, AWS Glue can connect to AWS Snowball Edge. AWS Snowball Edge is a data transfer and edge computing device that allows you to move large amounts of data into and out of AWS. You can use AWS Glue to create ETL jobs that read data from Snowball Edge and write it to other AWS services like Amazon S3, Amazon Redshift, or Amazon RDS. --- FROM Copilot
bignatov
👍 1
just correction A and B are wrong and D is the correct answer.
lofzee
👍 2
gotta be C surely..... LEAST operational overhead. EC2 = operational overhead. AWS Glue = managed service with transformation capabilities.
f761d0e
👍 4
The q states that the custom job must remain, so glue is out. Seems like D is the only option as DataSync needs bandwidth.
vip2
👍 2
Selected: C
Using an EC2 instance instead of a managed service like AWS Glue will include more operational overhead for the organization.
Femmyte
👍 3
Selected: D
The answer is D because of the following key points 1. A custom application in the company’s data center runs a weekly data transformation job. Which means that the company already has an application that runs the transformation. 2. A solutions architect must transfer the data and must configure the transformation job to continue to run in the AWS Cloud. This shows that the only responsibility of the architect is to transfer the data and configure the existing application to run on the EC2 the architect is going to deploy.
awsgeek75
👍 2
Selected: C
A: Cannot be done because no bandwidth B: Snowcone is probably to small D: Doable by EC2 is overhead for transformation when Glue is an option C: Is correct as Snowball Edge Storage Optimised device is good for storage and Glue can transform once the data is available
bujuman
👍 1
Selected: C
C best suit for: ETL jobs with LEAST operational overhead. For my understanding, we need here to avoir operation or maintenance burden of the solution
Shalen
👍 1
Selected: D
we use snowball to copy 50 PB "The company plans to pause the application until the data transfer is complete " and least over head " hence C would be reinventing the weel
slimen
👍 2
Selected: D
which is faster? - setup a glue cluster and adapt it to do the same analytical stuff as the original app - simpley run the same app in an EC2 instance?
mach2022
👍 2
How are we going to run the custom application using glue? that means more time to adapt the process instead of just running the app in ec2
GB_12345
👍 7
Selected: D
Not A. AWS DataSync requires an internet connection & the question states no available bandwidth Not B. SnowCone only has a max of 14 TB with an SSD, and the data is 50 TB Not C. Snowball Edge doesn't support Glue Supported services: https://docs.aws.amazon.com/snowball/latest/developer-guide/whatisedge.html So the answer must be D, as Snowball Edge Storage Optimized does support EC2 & can store 80 TB for the version that support compute resources
TariqKipkemei
👍 1
Selected: C
Snowball Edge has storage and compute capabilities, can be used to support workload in offline locations. Technically option D will work but with the overhead of EC2, negating the requirement for LEAST ops.
Guru4Cloud
👍 1
Selected: C
The Snowball Edge Storage Optimized device allows transferring a large amount of data without using network bandwidth. Once the data is copied to the Snowball, AWS Glue can be used to create a custom ETL job to transform the data, avoiding the need to reconfigure the existing on-premises application. This meets the requirements to transfer the data with minimal operational overhead and configure the data transformation job to run in AWS
james2033
👍 2
Selected: C
AWS Glue for ETL (Extract, Transform, Load) https://docs.aws.amazon.com/glue/latest/dg/how-it-works.html is good for this case (transformation). Keyword "50 TB", "AWS Snowball". Choose C. Easy question.
small_zipgeniuis
👍 4
Selected: C
A - no bandwith, option out B - snowcone SSD has max 14TB of capacity C - is correct one here D - cannot use Compute optimized as max capactiy for this snowball is 39.5TB, and only that's why ;-) https://docs.aws.amazon.com/snowball/latest/developer-guide/device-differences.html
rcarmin
👍 3
D answer says Snowball Edge STORAGE Optimized, which supports 80TB. 39.5TB is for the Snowball Edge COMPUTE Optimized.
live_reply_developers
👍 2
Selected: D
"A custom application in the company’s data center runs a weekly data transformation job." "A solutions architect must transfer the data and must configure the transformation job to continue to run in the AWS Cloud." LEAST operational overhead -> just take app and put on EC2, instead of configuring Glue
rcarmin
👍 2
IMHO, that's the least CONFIGURATION overhead, not operational. After you configure Glue, the operation should be easier than maintaining the EC2 and the transformation job.
cookieMr
👍 5
Option A (AWS DataSync with AWS Glue) involves using AWS DataSync for data transfer, which requires available network bandwidth. Since the data center has no additional network bandwidth, this option is not suitable. Option B (AWS Snowcone device with deployment) is designed for smaller workloads and may not have enough storage capacity for transferring 50 TB of data. Additionally, deploying the transformation application on the Snowcone device could introduce complexity and operational overhead. Option D (AWS Snowball Edge with EC2 compute) involves transferring the data using a Snowball Edge device and then creating a new EC2 instance in AWS to run the transformation application. This option adds additional complexity and operational overhead of managing an EC2 instance. In comparison, option C offers a straightforward and efficient approach. The Snowball Edge Storage Optimized device can handle the large data transfer without relying on network bandwidth. Once the data is transferred, AWS Glue can be used to create the transformation job, ensuring the continuity of the application's processing in the AWS Cloud.
rcarmin
👍 2
My thoughts exactly. I think people are missunderstanding CONFIG for OPERATION overhead.
beginnercloud
👍 1
Selected: C
Correctly answer is C. “The data center does not have any available network bandwidth for additional workloads.”
KMohsoe
👍 1
Option is C. “The data center does not have any available network bandwidth for additional workloads.” D is new EC instance is need to created. So I choose option C.
studynoplay
👍 5
Selected: C
LEAST operational overhead = Serverless = Glue
SkyZeroZx
👍 1
Selected: D
Exist " A custom application in the company’s data center runs a weekly data transformation job" Because existing previous app rebuild with Glue is more effort Ans D
darn
👍 2
Selected: C
D is far too manual, lots of overhead
Robrobtutu
👍 3
Selected: C
I'm voting C and not D because creating a new EC2 instance in Snowball to run the transformation application has more overhead than running Glue. Another thing to consider is that answer C does not mandate us to install Glue in Snowball, we can run Glue after the data has been uploaded from Snowball to AWS.
Bang3R
👍 3
Selected: C
C has less operational overhead than D. Managing EC2 has higher operational overhead than serverless AWS Glue
StuMoz
👍 3
I was originally going to vote for C, however it is D because of 2 reasons. 1) AWS love to promote their own products, so Glue is most likely and 2) because Glue presents the least operational overhead moving forward as it is serverless unlike an EC2 instance which requires patching, feeding and watering
Robrobtutu
👍 5
Answer C uses Glue, answer D uses EC2, so I believe you probably meant you're voting for C.
Dody
👍 2
Selected: C
Using the EC2 instance created on the Snowball Edge for the transformation job will do it once , However the solution architect must configure the transformation job to continue to run in the AWS Cloud so it's AWS Glue
AlmeroSenior
👍 2
Selected: D
Lets not forget that even a compute optimized Snowball cannot run Glue . Basically a NAS with S3 and EC2 is what you get so cant be C ( unless you run storage on prem and Glue in cloud with a dx/vpn )
Robrobtutu
👍 3
The answer does not say you have to run Glue inside snowball edge, it just says you would use Glue, which could be after snowball edge reaches Amazon facilities and the data is uploaded to AWS.
habibi03336
👍 1
Is it possible to use AWS Glue service on snowball edge?
remand
👍 1
Selected: D
perfect fit is D
xxichlas
👍 2
the differene between snowball with ec2 and without ec2 is $200 (for us east 1). fair to assume aws glue will not be more than that
G3
👍 4
.... and the AI maven says : A solution that would meet these requirements with the least operational overhead is to use AWS Snowball Edge. Snowball Edge is a data transfer device that can transfer large amounts of data into and out of the AWS cloud with minimal network bandwidth requirements. Additionally, Snowball Edge can run custom scripts on the device, so the transformation job can be configured to continue running during the transfer. Once the transfer is complete, the data can be loaded into an AWS storage service such as Amazon S3. This solution would minimize operational overhead by allowing for a parallel transfer and processing of data, rather than requiring the application to be paused.
goodmail
👍 18
Selected: D
Why C? This answer misses the part between SnowBall and AWS Glue. D at least provides a full-step solution that copies data in snowball device, and installs the custom application in device's EC2 to do the transformation job.
happpieee
👍 3
AWS Glue is not part of SnowBall Edge AWS services it can run within. Check it out here : https://docs.aws.amazon.com/snowball/latest/developer-guide/whatisedge.html
pentium75
👍 6
Because AWS Glue means less "operational (!) overhead" than running an EC2 instance.
aba2s
👍 2
Selected: C
Option B is incorrect. Although you can use AWS DataSync to automate and accelerate data transfer from on-premises to AWS storage services, it’s not capable of replicating existing applications running on your server. Option B is incorrect as AWS Snowcone supports data collection and data processing using AWS compute services but supports only 8 TB of HDD-based hard disk. It’s not the best option for transferring 50 TB of data, as it will require multiple iterations of offline data transfer. I will go for C as it seem to have less operational overhead.
NV305
👍 4
Selected: C
c only Glue is serverless. This means D has more operational overhead than C.
DavidNamy
👍 1
Selected: C
Option C involves using AWS Lambda to process the photos and storing the photos in Amazon S3, which can handle a large amount of data and scale to meet the needs of the growing user base. Retaining DynamoDB to store the metadata allows the application to continue to use a fast and highly available database for this purpose.
DavidNamy
👍 2
Selected: D
Option D, ordering an AWS Snowball Edge Storage Optimized device that includes Amazon EC2 compute, is the most efficient solution because it allows you to both transfer the data and run the transformation application on the same device, reducing the operational overhead required.
Robrobtutu
👍 2
The answer states you would create an extra EC2 instance to run the application. Wouldn't this mean it would have more operational overhead than Glue?
Buruguduystunstugudunstuy
👍 4
Selected: D
The solution that will meet these requirements with the least operational overhead is Option D: (Order an AWS Snowball Edge Storage Optimized device that includes Amazon EC2 compute. Copy the data to the device. Create a new EC2 instance on AWS to run the transformation application.) AWS Snowball Edge Storage Optimized devices are used to transfer large amounts of data quickly and securely to and from the cloud. They come with onboard storage and compute capabilities, which allows you to perform data processing tasks on the device itself before transferring the data to the cloud. This means that you can copy the data to the device and then use the device's computing capabilities to run the transformation application directly on the device, without having to pause the application or transfer it to the cloud.
Robrobtutu
👍 2
The answer states you would create an extra EC2 instance to run the application, you wouldn't be using the existing the existing compute. Wouldn't this mean it would have more operational overhead than Glue?
Buruguduystunstugudunstuy
👍 1
Option A, using AWS DataSync to move the data and creating a custom transformation job using AWS Glue, would require more operational overhead as it involves setting up and configuring multiple services. Option B, ordering an AWS Snowcone device and deploying the transformation applied to the device, would also involve setting up and configuring multiple services and may not have sufficient computing capabilities to run the transformation application. Option C, ordering an AWS Snowball Edge Storage Optimized device and creating a custom transformation job using AWS Glue, would involve setting up and configuring multiple services and would not have the onboard compute capabilities to run the transformation application directly on the device.
career360guru
👍 1
Selected: D
Option D is right as there is a need to copy and transfer the customer job also along with Data. Option C may not work as it requires custom job that needs to be re-written. So fastest and least operational overhead for migration is D only.
mj98
👍 2
Selected: D
I would say D because they have a custom application?
ocbn3wby
👍 2
Selected: D
I would stick to D answer. In real life - this is what it would have happened. Maybe after the migration, the existing ETL application would be refactored to AWS services. But this takes development time vs "lift and shift" approach. Edge Storage optimized offers EC2 compute functionality (with AMI directly integrated) https://docs.aws.amazon.com/snowball/latest/developer-guide/device-differences.html
ocbn3wby
👍 1
Also, the question clearly states they want to "pause the application" and not transform it to something more efficient.
ocbn3wby
👍 3
You can search this online. https://docs.aws.amazon.com/snowball/latest/developer-guide/device-differences.html
rewdboy
👍 1
Selected: D
D is correct I'm a bit split on this, because C is also a good answer, especially if you consider that the operational overhead. On the other hand, it seems more operationally efficient to just run the custom ETL job that already exists on the on-prem server on an EC2 instance instead of using AWS Glue. The part of the question that says they already have a "custom application" tells me that it should stay 1:1 to make the migration easier.
ocbn3wby
👍 1
In real life - this is what it would have happened. Maybe after the migration, the existing ETL application would be refactored to AWS services (Glue). But this takes development time vs "lift and shift" approach. I would stick to answer D.
JayanKuruwita
👍 1
As I know Snowball Edge dosn't come with EC2. So the answer should be C
Wpcorgan
👍 1
C is correct
Six_Fingered_Jose
👍 2
Selected: C
agree with C Glue is least effort
123jhl0
👍 77
Selected: C
A. Use AWS DataSync to move the data. Create a custom transformation job by using AWS Glue. - No BW available for DataSync, so "asap" will be weeks/months (?) B. Order an AWS Snowcone device to move the data. Deploy the transformation application to the device. - Snowcone will just store 14TB (SSD configuration). C. Order an AWS Snowball Edge Storage Optimized device. Copy the data to the device. Create a custom transformation job by using AWS Glue. - SnowBall can store 80TB (ok), takes around 1 week to move the device (faster than A), and AWS Glue allows to do ETL jobs. This is the answer. D. Order an AWS Snowball Edge Storage Optimized device that includes Amazon EC2 compute. Copy the data to the device. Create a new EC2 instance on AWS to run the transformation application. - Same as C, but the ETL job requires the deployment/configuration/maintenance of an EC2 instance, while Glue is serverless. This means D has more operational overhead than C.
jdr75
👍 6
I agree. When it said "with least Operational overhead" , it does not takes in account "migration activities" neccesary to reach the "final photo/scenario". In "operational overhead" schema, you're situated in a "final scenario" and you've only take into account how do you operate it, and if the operation of that scheme is ALIGHTED (least effort to operate than original scenario), that's the desired state.
remand
👍 11
I disagree on D. transformation job is already in place.so, all you have to do is deploy and run on ec2. C takes more effort to build Glue process, like reinventing the wheel . this is unnecessary
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option C pairs an AWS Snowball Edge Storage Optimized device — rated for 80 TB usable, so it comfortably holds the 50 TB dataset — with AWS Glue for the weekly transformation, which meets the "no available network bandwidth" and "begin as soon as possible" constraints without saturating the WAN. Because the requirement is explicitly LEAST operational overhead, Glue's serverless model wins: no AMIs to bake, no EC2 patching, no autoscaling or instance-lifecycle management, and no cluster provisioning. Glue also runs custom ETL code (Spark/Python scripts), so the company's custom transformation logic can be expressed as a Glue job rather than as an always-managed application. Once the Snowball lands the data in Amazon S3, Glue reads directly from S3 and the weekly schedule continues in the cloud, fully satisfying the "continue to run in the AWS Cloud" clause.Why the Other Options Are Wrong
Option A fails on the first constraint: AWS DataSync replicates over the network, and the data center "does not have any available network bandwidth for additional workloads," so a 50 TB DataSync task would take weeks and would compete with existing traffic. Option B fails on capacity: Snowball Edge Storage Optimized's smaller sibling, Snowcone, tops out around 14 TB SSD, far short of the required 50 TB, and it offers no meaningful way to run a transformation workload at this scale. Option D transfers the data correctly but then requires launching and maintaining a new Amazon EC2 instance to host the application — a server-based, patch-and-monitor model that carries strictly more ongoing operational overhead than Glue. Notably, D also wastes its premise: the option says to "Create a new EC2 instance on AWS," so the compute-capable Snowball Edge device it orders is never used for the job anyway.Community Comment Notes
Commenters split between C and D, with 123jhl0 and studynoplay arguing for C on capacity and serverless grounds — "LEAST operational overhead = Serverless = Glue" — while goodmail and GB_12345 push D, GB_12345 asserting that "Snowball Edge doesn't support Glue". That objection misreads the design: Glue runs in the AWS Region after the Snowball ships data to S3, not on the device, so device service support is irrelevant. f761d0e objected that "The q states that the custom job must remain, so glue is out," but Glue supports custom ETL scripts, and the question asks for the job to continue to run in the cloud, not for identical code packaging. remand similarly warned that rebuilding in Glue is "reinventing the wheel," yet under the question's explicit "LEAST operational overhead" test, ongoing EC2 administration outweighs one-time job migration effort.Official Reference
Exam Strategy
When a question forbids additional network bandwidth, immediately eliminate DataSync, Direct Connect-based, and S3-transfer-over-internet options, then check device capacity against the dataset size. On 'least operational overhead' phrasing, prefer serverless managed services (Glue, Lambda, Fargate) over EC2-based answers unless the workload must run unmodified on a specific runtime.
Frequently Asked Questions
Why can't AWS DataSync be used when the data center has no free bandwidth?
DataSync moves data over the network, so a 50 TB copy task would consume WAN capacity the site does not have and take weeks, violating the 'begin as soon as possible' requirement.
Doesn't running the transformation on EC2 mean less work than rebuilding it in AWS Glue?
EC2 means ongoing patching, monitoring, and instance lifecycle management. Glue is serverless and runs custom ETL scripts, so it carries lower operational overhead after the one-time job migration.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →