Nightly municipal backups from private subnets go to Amazon S3 through a NAT Gateway, and data-processing charges are high. Which change most directly cuts that network cost?
Select an answer to reveal the explanation.
Short Explanation
Don't toll the town trucks through the NAT booth when S3 has a free local on-ramp. An S3 Gateway VPC endpoint skips NAT data-processing charges for backups.
Full Explanation
Nightly municipal backups from private subnets to Amazon S3 that traverse a NAT Gateway incur NAT data-processing charges on top of any other transfer considerations. An S3 Gateway VPC endpoint keeps that backup traffic on the Amazon network via prefix-list routes in the route table, so PUTs to S3 no longer hairpin through NAT. For backup and log-heavy paths, Gateway endpoints are a direct, commonly tested cost win because they have no hourly charge for the gateway endpoint itself and eliminate NAT processing for S3-bound bytes.
Moving S3 buckets to a different AWS account so NAT charges "reverse" fails by concept: if traffic still exits via NAT to reach S3, NAT processing still applies; account boundaries do not invent a free path. Forcing backups through an internet-facing Application Load Balancer adds L7 proxy cost and complexity unsuitable for object PUTs. Switching backups to CloudFront invalidations confuses CDN cache busting with backup object storage writes.
Exam caveat: Gateway endpoints support S3 and DynamoDB; other AWS APIs need Interface endpoints (which do have hourly ENI charges). Ensure bucket policies and endpoint policies still enforce least privilege for the backup role.
Operational check: create an S3 gateway endpoint in the township VPC, update private subnet route tables, confirm backup job ENIs resolve S3 via the endpoint (no NAT path), watch NAT Bytes drop on backup windows, and verify Cost Explorer NAT data-processing charges decline while backup success rates stay green.