It says "LEAST operational overhead" (ie do it in a way it's the less work for me). If you know a little Amazon AppFlow (see the some videos) you'll see you'll need time to configure and test it, and at the end cope with the errors during the extraction and load the info to the target. The customer in the example ALREADY has some EC2 that do the work, the only problem is the performance, that WILL be improved scaling out and adding a queue (SNS) to decouple the work of notify the user. The operational load of doing this is LESS that configuring AppFlow.

This question just screams AppFlow (SaaS integration) https://aws.amazon.com/appflow/

configuring Auto-Scaling also takes time when compared to AppFlow, in AWS's words "in just a few clicks" > Amazon AppFlow is a fully managed integration service that enables you to securely transfer data between Software-as-a-Service (SaaS) applications like Salesforce, SAP, Zendesk, Slack, and ServiceNow, and AWS services like Amazon S3 and Amazon Redshift, in just a few clicks

"Operational overhead" refers to operation of the solution once it's deployed, it's not about setting it up. EC2 instances that retrieve data from A and write it to B are nonsense, that's what cloud services are meant for.

With AWS, a managed service is "less operational overhead" regardless of the complexity of the setup. AppFlow management is less of a headache when compared to EC2 management so A cannot be correct. EC2 has a setup overhead of OS/Application/Code hooks, security etc. continuous patching/upgrading seems like more than what you'll need to do with SaaS. B is the correct answer.

No B. if you go to the aws site(https://aws.amazon.com/appflow/) -AppFlow is a fully managed integration service that helps you securely transfer data between software as a service (SaaS) applications such as Salesforce, SAP, Google Analytics, Facebook Ads, and ServiceNow, and AWS services such as Amazon Simple Storage Service (S3) and Amazon Redshift in just a "few clicks". remember the question is asking for "the LEAST operational overhead", While Auto Scaling improves performance, it still involves managing EC2 instances, which adds operational overhead compared to a managed service like AppFlow.

https://aws.amazon.com/appflow/ "With Amazon AppFlow automate bi-directional data flows between SaaS applications and AWS services in just a few clicks." If you want to pass the exam, choose B, regardless of your personal experience! Always use AWS managed services for "least operational overhead"

Yea , I think this question is looking for Amazon Appflow.I also feel like it would be easier to set up Autoscaling for the already existing EC2 instances in the short term but then the fact that this software integrates with a lot of SAAS services means using Amazon Appflow will work reduce operational overhead in the long term

Amazon AppFlow is a fully managed integration service that helps you securely transfer data between software as a service (SaaS) applications such as Salesforce, SAP, Google Analytics, Facebook Ads, and ServiceNow, and AWS services such as Amazon Simple Storage Service (S3) and Amazon Redshift in just a few clicks. https://aws.amazon.com/appflow/

First i thought it would be A but with more stydy found if its Saas and need to choose between EC2 and aws managed service one should always choose AWS managed service. So AppFlow seems more appropriate here.

The answer is B, because for answer A you will have to manage the EC2 infrastructure, while AppFlow is a serverless service, you will not need to manage the infrastructure

Agreed, I hesitated a long time exactly for this reason. However, the requirement is to improve the performance as much as possible. I cannot guarantee the same performance with EC2 than with managed services. That's why I eventually voted B.

Has to be appflow because of the SaaS integration

i support AppFlow, the original can be saas, and the target can be s3.

B. Cree un flujo de Amazon AppFlow para transferir datos entre cada fuente de SaaS y el depósito de S3. Configure una notificación de eventos de S3 para enviar eventos a un tema de Amazon Simple Notification Service (Amazon SNS) cuando se complete la carga al depósito de S3. Explicación: Amazon AppFlow permite la integración directa con múltiples fuentes de SaaS y automatiza el flujo de datos hacia Amazon S3, eliminando la necesidad de instancias de EC2 para recibir y cargar datos. Esto reduce la carga en las instancias de EC2 y simplifica el proceso de integración y recolección de datos. Notificación de eventos de S3 y SNS : Configurar eventos en Amazon S3 permite enviar notificaciones directamente a un tema de Amazon SNS cuando los datos se han cargado, lo cual asegura que los usuarios recibirán notificaciones sin necesidad de código personalizado en EC2.

Option A: Auto Scaling EC2 instances High operational overhead (still managing EC2 instances). Not eliminating bottlenecks (EC2 instance is still the data processor). 🔴 Option C: EventBridge Rules Complex event-driven setup instead of direct integration. Requires custom event rules for each SaaS source, increasing operational burden. 🔴 Option D: ECS with CloudWatch Events Migrating to ECS introduces complexity and doesn’t directly improve transfer speeds. Still processes data manually, adding an unnecessary layer. Amazon AppFlow (Option B) is the best choice because it is fully managed, removes EC2 dependencies, and simplifies integration while improving performance.

B for sure

Initially I was inclined towards A, but then I read about AppFlow, which is a specific service to collect SAAS data sources. Also with A, there will be additional maintenance activities for EC2and application, but AppFlow will completely eliminate that work!

Key words here is Least Operational Overhead so A for me

A is correct

Use Amazon AppFlow to automate and scale data ingestion from SaaS sources to S3, and configure S3 event notifications to SNS for user alerts — the most efficient, scalable, and low-maintenance solution for this use case.

direct connect maybe correct answer but we are making too many assumptions regarding direct connect network requirements.