Cutting Cross-Region S3 Write Lag with Local Buckets and CRR
Short answer
C Upload each new Region's records to a local S3 bucket and Cross-Region Replicate them into the centralized eu-north-1 bucket.
Question
The company wants to increase its global presence. A solutions architect must launch the data collection capabilities in the sa-east-1 and ap-northeast-1 Regions. The solutions architect deploys the application, the Kinesis data stream, and the Lambda functions in the two new Regions. The solutions architect keeps the S3 bucket in eu-north-1 to meet a requirement to centralize the data analysis.
During testing of the new setup, the solutions architect notices a significant lag on the arrival of data from the new Regions to the S3 bucket.
Which solution will improve this lag time the MOST?
Key Takeaways
The question measures whether you recognize that Transfer Acceleration only speeds up internet-origin uploads, while Lambda writers in AWS Regions already use the AWS backbone — so the real fix is moving the write closer to the data source.
This SAP-C02 scenario tests how to shorten data arrival time from sa-east-1 and ap-northeast-1 to a centralized eu-north-1 S3 bucket read by Athena. The correct fix is Option C: write to a Regional bucket in each new Region and replicate to eu-north-1 with S3 Cross-Region Replication.
Common mistake: Option B (S3 Transfer Acceleration) is the most plausible wrong answer: it sounds like a direct latency fix and preserves the single central bucket, but it accelerates public-internet uploads, not Region-to-Region traffic that already runs on the AWS backbone.
Expert Analysis
Why Option B looks like the winner
Option B is the most tempting choice because it appears to attack the exact symptom: data from sa-east-1 and ap-northeast-1 arriving slowly at the eu-north-1 bucket. "Transfer Acceleration" reads like a generic latency fix, and it keeps the architecture unchanged — one central bucket, no new services, no replication semantics to reason about. On the surface it also seems to satisfy the requirement to centralize analysis in eu-north-1.
Where Option B stops being correct
S3 Transfer Acceleration accelerates uploads that originate on the public internet by entering AWS through a CloudFront edge location and riding the AWS backbone from there. In this question the writers are Lambda functions already running inside AWS Regions, so their traffic is already on the AWS backbone — there is no "last mile" for Transfer Acceleration to improve. It also requires the client to switch to the s3-accelerate endpoint, and Transfer Acceleration is not available in every Region, which is exactly the trap flagged in the discussion: it "achieves acceleration by routing traffic to a CloudFront edge location," but the client here is already AWS-side, so the gain is negligible. The lag is fundamentally cross-Region WAN distance plus synchronous cross-Region write latency, not an inefficient upload path.
Why Option C wins
Option C shortens the write path itself: each Region writes to a bucket in its own Region, which is a single-digit-millisecond local PUT, and S3 Cross-Region Replication then asynchronously pushes objects to the eu-north-1 bucket, where Athena keeps reading the centralized dataset. The centralization requirement is preserved because the destination of replication is still the eu-north-1 bucket.
Why A and D fail
Option A's S3 gateway endpoint only keeps VPC-to-S3 traffic on the private path within a Region; it does not shorten the cross-Region hop, and gateway endpoints do not accelerate inter-Region transfer. Option D's extra Lambda memory and multipart upload address compute throughput and large-object upload mechanics, neither of which is the bottleneck between Regions.
Verdict: Option C is the change that improves lag the MOST, because it removes the long-haul write from the critical path while keeping analysis centralized.
Official Reference
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html
These links open the official vendor documentation in a new tab.
Exam Strategy
On latency questions, first identify where the client runs. If the writer is already inside AWS (Lambda, EC2), eliminate any option built on CloudFront edge or internet acceleration, because that path only helps off-cloud clients. Then pick the option that shortens the critical write path itself rather than tuning compute, memory, or endpoints — here, a same-Region bucket plus replication removes the cross-Region hop from the ingest path.
Frequently Asked Questions
Why doesn't S3 Transfer Acceleration fix the lag from Lambda in sa-east-1 and ap-northeast-1?
Does using Cross-Region Replication break the requirement to centralize analysis in eu-north-1?
Why don't an S3 gateway endpoint or more Lambda memory reduce this lag?
Community Votes
58% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 33 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 30 of 33
-
wyeedh1 👍 20 Answered Cs3 transfer acceleration is not supported in eu-north-1 region yet https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html
-
VerRi 👍 9 Answered C"improve this lag time the MOST" means improve the time for "uploading files" not "uploading the files to the destination." Uploading the files to the bucket in the same region is faster than transferring them to other regions.
-
bjexamprep 👍 6 Answered CS3 Transfer Acceleration achieves acceleration by AWS routing traffic to AWS cloudfront edge location and transfer aws network backbone. The key speed improvement is AWS network backbone. While, in this case, the application in the two new regions is the client to write the output to S3 in EU, which means the client is already on AWS, the data transportation is already on AWS network backbone. So S3 Transfer Acceleration is not helping at all. B is out. C is the best answer.
-
cf9e355 👍 5 Answered Bas they said "The solutions architect keeps the S3 bucket in eu-north-1 to meet a requirement to centralize the data analysis". So, B should be the answer
-
leliodesouza 👍 4 Answered CCorrect Answer is C. S3 transfer acceleration is not yet supported in the eu-north-1 region, as wyeedh1 commented. https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html
Show 25 more comments
-
HunkyBunky 👍 4 Answered CAnswer is C - this option will provide MOST lag-improve solution for application
-
kejam 👍 4 Answered Bhttps://aws.amazon.com/s3/transfer-acceleration/
-
thotwielder 👍 3 Answered BA: wrong. for s3 gateway endpoint it's not possible to access the S3 buckets from another VPC/Region B: typical scenario for s3 transfer acceleration. C: possible. But extra steps. And not sure s3 replication will be faster. So is wrong. D: wrong.
-
seetpt 👍 3 Answered CI would choose B but it cannot be B because S3 Transfer Acceleration is not supported in eu-north-1. This leaves C as the only viable option.
-
TheCloudGuruu 👍 3 Answered BB. Transfer Accelertation
-
qaz12wsx 👍 3 Answered Cagree with bjexamprep
-
alexis123456 👍 3Correct Answer is C
-
failexamonly 👍 3 Answered Csee wyeedh1 answer
-
career360guru 👍 3 Answered BOption B
-
arberod 👍 3 Answered BIt is B
-
0b43291 👍 2 Answered CBy implementing Option C, the company can leverage the proximity of local S3 buckets in each Region, while still maintaining a centralized data store in eu-north-1 through Cross-Region Replication. This approach minimizes the lag time for data arrival and ensures that the data analysis in Amazon Athena is performed on the complete and up-to-date dataset. The other options have limitations or may not address the lag time issue effectively: Option A (VPC and S3 gateway endpoint) does not directly address the latency issue caused by the long distances between Regions. Option B (S3 Transfer Acceleration) can improve transfer speeds but may not be as effective as having local S3 buckets in each Region. Option D (increasing Lambda memory and using multipart uploads) may improve Lambda performance but does not address the underlying network latency issue.
-
teashoppe 👍 2 Answered CB incorrect (S3 Transfer Acceleration): Helps most when uploads come from the public internet and can benefit from entering AWS at an edge location. Your uploads are coming from AWS Regions (Lambda/EC2) over AWS backbone already; TA usually won’t be the biggest improvement here.
-
07c2d2a 👍 2B. It's not efficient to upload to 1 S3 bucket, then have it replicated across. It will be faster to use acceleration to get to the actual destination bucket. Additionally, they don't need 2 extra copies of all the data. B makes the most sense from all perspectives.
-
AloraCloud 👍 2Except if RTC is enabled you cannot guarantee that the data replicated to the central S3 bucket in eu-north-1 will be up to date. I'll be dammed if AWS is really expecting folks to remember the regions which do not have the Amazon S3 Transfer Acceleration feature.
-
veyisceylan 👍 2I think that the LAG 7is caused due to network path running to S3 public interfaces. The gateway endpoint can enchance the network path and reduce the LAG. https://aws.amazon.com/blogs/architecture/reduce-cost-and-increase-security-with-amazon-vpc-endpoints/
-
BelloMio 👍 2 Answered CAnswer is C I mean if this question is on the exam that's just ridiculous. You would have to know by heart that eu-north-1 is not yet supported for transfer acceleration. https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html
-
AloraCloud 👍 2I think the answer is C because Amazon Kinesis Data Streams cannot directly leverage S3 Transfer Acceleration. S3 Transfer Acceleration is typically used for accelerating transfers from clients to S3 and doesn't support Kinesis Data Streams directly.
-
aka1177 👍 2 Answered CThe requirement for centralizing data in the region exists solely because analysis is done with Athena. Therefore, replicating data from other regions is definitely a viable solution. The correct answer is C.
-
e4bc18e 👍 2Answer is C but feel this is one they definitely want people to get wrong. No one is going to memorize which regions every feature is supported in, it is something anyone would look up.
-
Syre 👍 2 Answered BWhile C would work, it adds complexity by requiring separate S3 buckets in each Region and replicating data, which could increase cost and delay due to replication schedules.
-
trungtd 👍 2 Answered CNo matter how fast you run, you cannot run from Tokyo to Stockholm as fast as someone 10km from Stockholm.
-
sat2008 👍 2 Answered BI agree for the reason "requirement to centralize the data analysis" we cant have S3 s in other regions
-
akiakiaki 👍 2 Answered Cwyeedh1
-
stantx 👍 1 Answered CThe correct solution is C. Here is the corrected architectural breakdown of why Option C is the right answer and why Option B is fundamentally flawed in this context: The Flaw in Option B (S3 Transfer Acceleration for intra-AWS traffic) Amazon S3 Transfer Acceleration (S3TA) is designed specifically to accelerate uploads originating from the public internet (e.g., end-users on mobile phones or on-premises servers) by routing their traffic to the nearest CloudFront Edge Location and then across the AWS global backbone. However, in this scenario, the client uploading the data is an AWS Lambda function running inside an AWS Region (sa-east-1 and ap-northeast-1). Traffic sent from one AWS Region to another AWS Region already inherently travels over the highly optimized AWS global private backbone. Therefore, enabling S3TA for an AWS Lambda function provides virtually zero performance benefit, as the traffic is already on the fastest possible AWS path. Why Option C is Correct (Local Buckets + CRR) The "lag" the architect is noticing is the synchronous, cross-continental TCP network latency caused by Lambda waiting for a PutObject API call to complete against a bucket on the other side of the world. To solve this: Decouple the Write: By creating a local S3 bucket in sa-east-1 and ap-northeast-1, the Lambda functions write their processed records locally. This reduces the synchronous upload latency from hundreds of milliseconds down to low single-digit milliseconds, allowing the Lambda functions to execute and terminate incredibly fast. Asynchronous Transfer: S3 Cross-Region Replication (CRR) takes over. AWS highly optimizes CRR transfers across its backbone in the background to sync the objects to the central eu-north-1 bucket. This provides the most reliable and fastest end-to-end data arrival time without blocking the application's compute layer. Why the Other Options are Incorrect Option A is incorrect: Amazon S3 Gateway Endpoints are strictly Regional. A VPC endpoint in sa-east-1 cannot route traffic to an S3 bucket located in eu-north-1. Option D is incorrect: While increasing Lambda memory does allocate more CPU and network bandwidth, the bottleneck here is the physical distance/speed of light (TCP latency) across continents, not a lack of compute resources. Furthermore, multipart upload is generally only beneficial for large files (typically >100 MB), not streaming application records.
-
Amac1979 👍 1 Answered BC (S3 buckets per Region + Cross-Region Replication) — While writing locally is fast, S3 Cross-Region Replication (CRR) introduces its own lag. CRR is asynchronous and can take minutes to hours depending on object size and queue depth. The net effect may not improve the total time for data to arrive in eu-north-1 compared to Transfer Acceleration, which is a direct accelerated upload. Also adds complexity of managing multiple buckets.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →