Topic 20 Practice Test 1 covers Cost-Optimized Networking, NAT, Endpoints, Connectivity, Routing, and Edge Caching for AWS SAA-C03. For broader exam preparation, review the AWS SAA-C03 Exam Dumps. Every option includes focused technical reasoning explaining both the AWS architecture concept and its fit to the scenario.
Question 1
A private EC2 analytics fleet reads several terabytes from Amazon S3 each day. The instances currently reach S3 through a NAT gateway, and the company wants to reduce recurring network-processing cost without making the instances public. What should the architect change?
- Add another NAT gateway in the same Availability Zone for these requests
- Create an S3 gateway VPC endpoint and route S3 traffic to it
- Create an S3 interface endpoint in every subnet for these application flows
- Assign public IPv4 addresses to the EC2 instances for this traffic path
Correct Answer(s)
B
Rationale
- A same-AZ NAT gateway can avoid cross-AZ transfer for internet-bound traffic, but NAT hourly and data-processing charges still apply to bytes that traverse it. In this scenario, the objective is to remove NAT processing for S3 rather than merely localize it, so paying for this component would not solve the stated problem.
- An S3 gateway endpoint provides private VPC access to S3 through route-table entries and has no additional hourly or endpoint data-processing charge. Here, S3 is the high-volume destination and the NAT path is unnecessary; that removes the paid network path the workload does not need.
- An S3 interface endpoint uses AWS PrivateLink and provides private IP-based access, but it has endpoint hourly and data-processing charges. The option is technically valid in other designs, but all callers are inside one VPC and can use the no-additional-charge gateway endpoint; it does not optimize the required traffic path.
- Public IPv4 addressing can let instances use an internet gateway, but public addresses carry their own charges and expose a broader network path. Here, the workloads must remain private and S3 can be reached without public addressing; this alternative adds cost or capability that the workload does not require.
Question 2
Private application servers run in two Availability Zones and send large volumes of traffic to internet APIs. Both subnets route through one NAT gateway in only one Availability Zone. NAT processing is expected, but inter-AZ transfer has become significant. Which change best targets that extra cost?
- Replace the NAT gateway with an internet gateway on the private subnets
- Send the traffic through an S3 gateway endpoint for this traffic path
- Route both subnets through a Transit Gateway before the NAT gateway
- Deploy a NAT gateway in each Availability Zone and use same-AZ routes
Correct Answer(s)
D
Rationale
- An internet gateway does not provide IPv4 source translation for private-only instances; those instances need public IPv4 addresses or a NAT mechanism for outbound IPv4. Because the servers must stay private and still initiate IPv4 internet connections, this approach would not remove the charge or transfer pattern identified in the question.
- Gateway endpoints are route-table targets for S3 and DynamoDB, not generic paths to arbitrary internet APIs. For the stated workload, the expensive traffic is destined for external APIs rather than S3 or DynamoDB; selecting this would optimize the wrong layer.
- Transit Gateway adds attachment and data-processing charges and would still leave the centralized NAT plus cross-AZ path unless the topology changed elsewhere. The architecture needs a different lever because the problem is the location of the NAT hop, not a missing transitive routing service; this option would not materially reduce the targeted spend.
- Using one NAT gateway per active Availability Zone lets private workloads send internet traffic through a local NAT path, avoiding the cross-AZ hop to a centralized NAT. In the stated architecture, internet traffic is high enough that eliminating cross-AZ transfer justifies the additional NAT hourly charge; choosing this option targets the measured source of spend.
Question 3
A dual-stack workload in private subnets sends outbound telemetry to IPv6-capable internet collectors. No inbound internet-initiated IPv6 sessions are allowed, and the team wants to avoid paying NAT gateway processing for this IPv6 path. Which component should be used?
- An egress-only internet gateway for the IPv6 route
- A public NAT gateway with DNS64 enabled for this workload
- An internet gateway with public IPv4 addresses on every instance
- An interface VPC endpoint for the collector for this design
Correct Answer(s)
A
Rationale
- An egress-only internet gateway is a scalable VPC component for outbound IPv6 connectivity that blocks internet-initiated IPv6 connections, and AWS does not charge for the gateway itself. Operationally, the telemetry destinations support IPv6 and outbound-only behavior is required; the option therefore reduces unnecessary transfer or fixed networking charges.
- A public NAT gateway can perform NAT64 for IPv6 workloads that must reach IPv4-only destinations, which is useful when native IPv6 is unavailable. The scenario specifies that the external collectors already support IPv6, so translation and NAT processing are unnecessary; this alternative does not align with that traffic or billing characteristic.
- An internet gateway can carry public IPv4 and IPv6 traffic, but assigning public IPv4 addresses adds address charges and changes the workload exposure model. Using this would be reasonable only under different constraints, because only outbound IPv6 is required and the instances should not accept unsolicited sessions; the current requirement points elsewhere.
- Interface endpoints privately expose supported AWS or endpoint services through PrivateLink; arbitrary public IPv6 collectors are not reached through a VPC endpoint. This does not fit the cost model: the target is an internet service, not a PrivateLink-capable AWS endpoint; another choice removes the unnecessary network charge more directly.
Question 4
Two VPCs in the same Region exchange a very large stream between workloads placed in the same Availability Zone. They need only direct private connectivity and no transitive routing. Which topology minimizes unnecessary network-service charges?
- Attach both VPCs to AWS Transit Gateway for these requests
- Create Site-to-Site VPN connections between the VPCs for this design
- Create a direct VPC peering connection between the two VPCs
- Expose the producer through AWS PrivateLink for this traffic path
Correct Answer(s)
C
Rationale
- Transit Gateway provides hub-and-spoke and transitive routing for many networks, but VPC attachments and traffic sent through the gateway incur charges. The mismatch is that there is no transitive requirement and only one VPC pair needs to communicate; this option introduces or retains charges that the preferred design avoids.
- Site-to-Site VPN is designed for encrypted connectivity between a VPC and customer networks or other VPN endpoints and includes connection-hour charges. In context, native same-Region VPC connectivity is available without VPN tunnels; this would spend money on a capability that is not required.
- VPC peering connects two VPCs privately without a gateway appliance, and AWS does not charge to create the peering connection; same-AZ peering traffic is not charged for data transfer. The workload profile shows that only two VPCs need one-to-one connectivity and both endpoints can remain in the same Availability Zone; this design is therefore the best financial fit without breaking the requirement.
- PrivateLink is valuable for publishing a service privately to consumers without broad network routing, but interface endpoints add hourly and data-processing charges. The workload does not benefit from this choice because the requirement is general bidirectional VPC connectivity rather than access to one published service; its primary cost remains unchanged.
Question 5
Ten development VPCs already attach to a Transit Gateway for required inter-VPC routing. Each VPC sends only a few gigabytes of internet traffic monthly, and maintaining a NAT gateway in every VPC dominates cost. Which redesign is most appropriate after validating route and security requirements?
- Add one NAT gateway per Availability Zone in every development VPC for these application flows
- Give every private instance a public IPv4 address as the main path for this workload
- Use a centralized egress VPC with shared NAT gateways reached through the existing Transit Gateway
- Create gateway endpoints for all external internet APIs as the selected route for these requests
Correct Answer(s)
C
Rationale
- Per-AZ NAT gateways can reduce cross-AZ transfer and improve fault isolation for heavy egress, but multiplying gateways increases fixed hourly cost. Applying this service would not help here, since these VPCs have very low outbound volume and already share a transit hub; the scenario calls for a more targeted network change.
- Public IPv4 addressing bypasses NAT for direct internet access but adds address cost and weakens the private-subnet network model. The design goal is narrower than this option assumes because the organization wants shared controlled egress rather than public addresses on each workload; the added capability is not justified by the savings.
- Centralized egress can consolidate NAT gateways for many low-volume VPCs when a transit hub already exists, trading some Transit Gateway processing for fewer NAT hourly charges. Since the measured traffic pattern shows that internet volume per VPC is small while the fixed cost of many separate NAT gateways is dominant, this selection avoids paying for unused network features.
- Gateway endpoints only support specific AWS services such as S3 and DynamoDB; they cannot replace general internet egress for third-party APIs. This is not the best answer because the destinations are arbitrary internet services, so a controlled egress path is still necessary; the proposed component does not change the expensive path identified.
Question 6
A company needs private connectivity from a small branch office to one AWS VPC for a six-month project. Traffic is light, internet connectivity is reliable, and there is no requirement for a dedicated circuit. Which option is the most cost-appropriate?
- Use AWS Site-to-Site VPN over the existing internet connection
- Order a dedicated AWS Direct Connect connection
- Deploy AWS Global Accelerator for the branch
- Create a VPC peering connection to the branch router
Correct Answer(s)
A
Rationale
- Site-to-Site VPN provides encrypted IPsec connectivity to AWS without provisioning a dedicated physical circuit, making it suitable for modest or temporary hybrid traffic. Here, the project is short-lived, low-volume, and does not justify dedicated connectivity; that removes the paid network path the workload does not need.
- Direct Connect provides dedicated private connectivity with port-hour and provider-related costs, which can be attractive for sustained high-volume or consistent hybrid traffic. In this scenario, the branch has only temporary light traffic and no dedicated-line requirement, so paying for this component would not solve the stated problem.
- Global Accelerator improves internet path performance to regional application endpoints using the AWS global network; it does not create a private branch-to-VPC network tunnel. The option is technically valid in other designs, but the need is encrypted hybrid connectivity, not acceleration for public application clients; it does not optimize the required traffic path.
- VPC peering operates between VPCs and does not terminate an on-premises router or extend a branch network into AWS. Here, one endpoint is a physical branch network rather than another VPC; this alternative adds cost or capability that the workload does not require.
Question 7
A media company transfers tens of terabytes from AWS to its on-premises facility every month. The flow is steady, the company already has presence at a Direct Connect location, and predictable private connectivity is required. What should the architect evaluate first for long-term network cost optimization?
- Keep all transfer over Site-to-Site VPN because tunnels have no data-transfer charges
- Use an S3 gateway endpoint to extend the on-premises network into S3
- Use AWS Global Accelerator between the facility and S3 for this workload
- Use AWS Direct Connect sized for the sustained throughput for this workload
Correct Answer(s)
D
Rationale
- VPN connectivity still uses billable network paths and has connection-hour considerations; it is not automatically cheaper for very high sustained data volumes. Because the workload is dominated by long-running bulk transfer rather than occasional encrypted access, this approach would not remove the charge or transfer pattern identified in the question.
- S3 gateway endpoints are attached to VPC route tables and are not reachable from on-premises networks through VPN or Direct Connect. For the stated workload, the traffic must cross the hybrid boundary rather than stay inside a VPC; selecting this would optimize the wrong layer.
- Global Accelerator is designed to improve availability and performance for supported regional application endpoints; it is not a bulk private data-transfer replacement for Direct Connect. The architecture needs a different lever because the requirement is sustained hybrid transfer with predictable private connectivity; this option would not materially reduce the targeted spend.
- Direct Connect provides dedicated connectivity with port-hour charges and Direct Connect data-transfer pricing; at sustained high volumes it can be more economical than repeated internet egress while also providing predictable network behavior. In the stated architecture, transfer volume is large and steady and the company already has practical access to a Direct Connect location; choosing this option targets the measured source of spend.
Question 8
An S3-backed software distribution site serves the same large installation files to customers around the world. Most requests retrieve immutable objects, and internet data-transfer charges from the Region are high. Which architecture is most likely to reduce delivery cost while also improving user performance?
- Create an interface VPC endpoint for S3 for the stated production traffic path
- Place Amazon CloudFront in front of the S3 origin and cache the installers
- Replicate every object into a separate S3 bucket in each Availability Zone
- Route downloads through a NAT gateway as the selected route for these requests
Correct Answer(s)
B
Rationale
- An S3 interface endpoint provides private access from supported networks to S3 but does not cache objects near public end users or replace internet content delivery. The scenario specifies that the cost is public distribution to global customers, not private VPC-to-S3 access; this alternative does not align with that traffic or billing characteristic.
- CloudFront caches objects at edge locations and can reduce repeated origin requests and data transferred directly from a Region; AWS origins can also benefit from CloudFront transfer economics. Operationally, the same immutable files are repeatedly downloaded by geographically distributed users; the option therefore reduces unnecessary transfer or fixed networking charges.
- S3 is already a regional service with resilient storage behavior, and duplicating buckets by Availability Zone does not create edge caching for internet clients. Using this would be reasonable only under different constraints, because viewers are global and repeated delivery, not zonal object placement, drives spend; the current requirement points elsewhere.
- NAT gateways provide outbound translation for private resources and add processing charges; they are not designed as a customer-facing content distribution layer. This does not fit the cost model: clients need efficient inbound content delivery rather than private-subnet outbound internet access; another choice removes the unnecessary network charge more directly.
Question 9
A streaming service uses CloudFront, but nearly all paying viewers are in the United States, Canada, and Western Europe. Management accepts slightly less optimal latency for rare viewers elsewhere if delivery cost decreases. Which CloudFront setting should be reviewed?
- Use a lower CloudFront price class that excludes more expensive edge locations
- Enable Origin Shield in every possible AWS Region for this traffic path
- Disable caching and forward every request to the origin for these requests
- Replace CloudFront with a public NAT gateway for the stated client traffic
Correct Answer(s)
A
Rationale
- CloudFront price classes let an operator limit which groups of edge locations are used, trading some geographic performance reach for lower delivery pricing. The workload profile shows that the audience is concentrated in lower-cost regions and management explicitly accepts the performance trade-off elsewhere; this design is therefore the best financial fit without breaking the requirement.
- Origin Shield adds a centralized caching layer and incurs additional request charges; it is configured for a selected Region rather than enabled everywhere. The mismatch is that the primary goal is to restrict expensive edge coverage, not add another cache layer; this option introduces or retains charges that the preferred design avoids.
- Bypassing edge caching increases origin requests and typically gives up one of the core mechanisms CloudFront uses to reduce delivery and backend costs. In context, most content can still benefit from the CDN and the problem is edge-location price scope; this would spend money on a capability that is not required.
- A NAT gateway is an outbound VPC translation service and does not provide viewer-facing edge distribution or configurable delivery price classes. The workload does not benefit from this choice because the workload needs CDN delivery with a controlled geographic cost-performance trade-off; its primary cost remains unchanged.
Question 10
A CloudFront distribution has a poor cache-hit ratio because the cache key includes a session cookie and several query parameters that the origin ignores when generating static catalog images. Which change is the best cost optimization?
- Forward every viewer header and cookie to the origin
- Set the minimum TTL to zero for all catalog images
- Remove the unnecessary cookie and query parameters from the cache key
- Create a Transit Gateway between CloudFront and the origin VPC
Correct Answer(s)
C
Rationale
- Forwarding additional request attributes can be required for personalized content, but doing so does not improve reuse when those values are irrelevant to the response. Applying this service would not help here, since the origin ignores the extra attributes and the goal is to increase cache reuse; the scenario calls for a more targeted network change.
- A zero minimum TTL permits immediate revalidation or noncaching behavior and generally reduces edge reuse rather than improving it. The design goal is narrower than this option assumes because the images are static and the excessive cache-key variation, not staleness, is the problem; the added capability is not justified by the savings.
- CloudFront cache policies control which headers, cookies, and query strings contribute to the cache key; fewer irrelevant variations let more requests reuse the same cached object. Since the measured traffic pattern shows that the origin returns identical images despite those request attributes, so cache fragmentation is creating avoidable origin traffic, this selection avoids paying for unused network features.
- Transit Gateway connects networks and VPC attachments; CloudFront origin access and caching are not optimized by placing a transit gateway in the path. This is not the best answer because the cost comes from cache misses rather than missing transitive VPC routing; the proposed component does not change the expensive path identified.
Question 11
A global application has CloudFront in front of an origin that performs expensive just-in-time image transformations. Similar cache misses arrive from many edge locations, causing repeated origin work. The team estimates that reducing origin requests will save more than the additional feature charge. What should it enable?
- Add a second public NAT gateway in front of the origin
- Enable CloudFront Origin Shield in the Region closest to the origin
- Create VPC peering from each edge location to the origin VPC
- Disable CloudFront and let every viewer request reach the origin directly
Correct Answer(s)
B
Rationale
- NAT gateways provide outbound address translation for private workloads and do not consolidate CloudFront cache misses or shield an origin from repeated content requests. In this scenario, the costly activity is duplicate origin processing, not lack of outbound IPv4 capacity, so paying for this component would not solve the stated problem.
- Origin Shield adds another CloudFront caching layer that can consolidate misses from multiple edge locations before requests reach the origin, reducing duplicate origin work and transfer. Here, the origin operation is expensive and modeled savings exceed Origin Shield’s additional request charge; that removes the paid network path the workload does not need.
- CloudFront edge locations are not customer VPCs that can be VPC-peered to an origin network, so this does not create a valid cache architecture. The option is technically valid in other designs, but the requirement is another caching tier rather than private VPC routing; it does not optimize the required traffic path.
- Removing the CDN would increase origin request volume and internet delivery burden, worsening the stated cost problem for expensive transformations. Here, the team specifically wants to collapse repeated misses before they reach the origin; this alternative adds cost or capability that the workload does not require.
Question 12
A company runs six low-traffic HTTP microservices, each behind its own Application Load Balancer. The services have compatible security and scaling requirements, and monthly load balancer fixed charges exceed the traffic-related charges. What change should be evaluated?
- Replace every ALB with a separate Network Load Balancer for this workload
- Put a NAT gateway in front of each microservice for these requests
- Use one Transit Gateway attachment per microservice for the stated client traffic
- Consolidate the services behind one ALB using host- or path-based listener rules
Correct Answer(s)
D
Rationale
- Network Load Balancers are useful for Layer 4 protocols, static IP needs, and extreme connection rates, but one NLB per service would preserve multiple billable load balancers. Because all workloads are compatible HTTP services and consolidation, not protocol change, is the cost lever, this approach would not remove the charge or transfer pattern identified in the question.
- NAT gateways support outbound translation from private subnets; they do not accept public HTTP client traffic as application load balancers do. For the stated workload, the services need inbound HTTP routing rather than outbound internet access; selecting this would optimize the wrong layer.
- Transit Gateway operates at network routing scope between VPCs and hybrid networks; it does not replace HTTP listener rules or target-group selection. The architecture needs a different lever because the cost problem is multiple application load balancers within a compatible web tier; this option would not materially reduce the targeted spend.
- An Application Load Balancer can route HTTP requests to different target groups using host names and URL paths, allowing compatible services to share one load-balancing layer. In the stated architecture, separate ALBs are not needed for isolation and their fixed charges dominate the network bill; choosing this option targets the measured source of spend.
Question 13
Private application servers make millions of AWS Secrets Manager API calls and otherwise do not need internet access. A NAT gateway was deployed only for those calls. Which redesign should the architect cost-model first?
- Create an S3 gateway endpoint as the selected private network route for these requests
- Add a second NAT gateway for redundancy as the primary route for this traffic
- Assign Elastic IP addresses to the application servers for the current private application path
- Create an interface VPC endpoint for Secrets Manager and remove the dedicated NAT path
Correct Answer(s)
D
Rationale
- Gateway endpoints provide no-additional-charge private routes to S3 and DynamoDB, but they do not serve Secrets Manager API endpoints. The scenario specifies that the destination is Secrets Manager and requires a supported interface endpoint instead; this alternative does not align with that traffic or billing characteristic.
- Another NAT gateway can improve zonal egress design, but it would increase fixed charges while retaining NAT data processing for every Secrets Manager call. Using this would be reasonable only under different constraints, because the workload has no other internet requirement and can reach Secrets Manager privately; the current requirement points elsewhere.
- Elastic/public addressing would create direct internet paths and incur public IPv4-related cost without eliminating the need for secure service access controls. This does not fit the cost model: the servers are intended to stay private and only call one AWS service; another choice removes the unnecessary network charge more directly.
- Interface endpoints use AWS PrivateLink to reach supported AWS services through private addresses; they have hourly and per-GB charges but can avoid NAT processing and internet-path dependencies. Operationally, Secrets Manager traffic is heavy and the NAT gateway exists solely to carry that supported AWS-service traffic; the option therefore reduces unnecessary transfer or fixed networking charges.
Question 14
An on-premises backup appliance already has an AWS Direct Connect connection and must send large backups to Amazon S3. Private IP addressing for S3 is not required, and the team wants to avoid adding paid S3 interface endpoints. Which Direct Connect design fits?
- Create an S3 interface endpoint in a VPC and force all backups through it for these application flows
- Create a public virtual interface on the existing Direct Connect connection for AWS public services such as S3
- Create an S3 gateway endpoint and advertise it to the data center for the current private application path
- Replace Direct Connect with a NAT gateway as the selected private network route for all application requests operationally
Correct Answer(s)
B
Rationale
- An S3 interface endpoint provides private-IP access and is appropriate when that addressing model is required, but it adds endpoint-hour and data-processing charges. The mismatch is that the scenario explicitly does not require private S3 addresses and already has Direct Connect; this option introduces or retains charges that the preferred design avoids.
- A Direct Connect public virtual interface reaches AWS public service prefixes, including Amazon S3, over the Direct Connect path without requiring an S3 interface endpoint inside a VPC. The workload profile shows that the appliance can use public S3 addresses and the existing Direct Connect circuit while avoiding PrivateLink endpoint charges; this design is therefore the best financial fit without breaking the requirement.
- Gateway endpoints are VPC route-table targets and cannot be extended to on-premises networks over Direct Connect, VPN, peering, or Transit Gateway. In context, the caller is outside the VPC and cannot consume a gateway endpoint transitively; this would spend money on a capability that is not required.
- A NAT gateway is a VPC egress translation service and cannot terminate the existing on-premises dedicated connection or provide a more economical S3 hybrid path. The workload does not benefit from this choice because the existing Direct Connect link already supplies the required physical connectivity; its primary cost remains unchanged.
Question 15
Network charges increased sharply after a release. The architect needs both detailed evidence of which ENI conversations generate the most bytes and billing data that separates transfer and network-service usage. Which TWO data sources should be used together? (Choose TWO.) (Choose 2.)
- VPC Flow Logs for this design
- AWS CloudTrail event history
- AWS Cost and Usage Report
- Amazon Route 53 Resolver query logging
Correct Answer(s)
A, C
Rationale
- VPC Flow Logs record metadata about accepted or rejected IP traffic for network interfaces, subnets, or VPCs and can reveal high-volume source-destination conversations for traffic analysis. Since the measured traffic pattern shows that the team needs technical flow evidence that can be correlated with the release, this selection avoids paying for unused network features.
- CloudTrail records API activity and is valuable for governance and change investigation, but it does not measure the byte volume of ordinary application network conversations. The design goal is narrower than this option assumes because the investigation requires flow volume and billing detail rather than only control-plane calls; the added capability is not justified by the savings.
- The Cost and Usage Report provides detailed billing line items and can include usage types, services, accounts, and cost allocation dimensions for deeper cost analysis. The business constraint is that the team must connect observed flows to billed transfer and network-service usage; this option optimizes spend at the exact point where the traffic is generated.
- Resolver query logs show DNS queries handled by Route 53 Resolver and can help troubleshoot name resolution, but they do not provide general packet-byte accounting or the complete AWS bill. This is not the best answer because the cost spike is broad network usage, not specifically DNS-query volume; the proposed component does not change the expensive path identified.
Question 16
A public API behind CloudFront is being hit by automated clients at a rate far above the contracted usage. The excess requests increase origin transfer and downstream compute cost. The business wants to reject abusive request rates at the edge before they reach the application. What should be added?
- An AWS WAF rate-based rule associated with the CloudFront distribution
- A larger Direct Connect circuit to the origin VPC
- A Transit Gateway with appliance mode enabled for this design
- A second NAT gateway for the application subnets
Correct Answer(s)
A
Rationale
- AWS WAF rate-based rules can count and limit requests from sources that exceed configured rates, allowing abusive traffic to be blocked before it reaches the protected application origin. Here, the goal is to suppress excessive client requests at the edge and reduce avoidable downstream traffic; that removes the paid network path the workload does not need.
- Direct Connect provides hybrid dedicated connectivity and additional bandwidth would not stop public internet clients from sending excessive requests through CloudFront. In this scenario, the problem is unwanted request volume rather than insufficient private WAN capacity, so paying for this component would not solve the stated problem.
- Transit Gateway connects VPC and hybrid networks, while appliance mode helps preserve symmetric routing through stateful appliances; neither feature rate-limits CloudFront viewers. The option is technically valid in other designs, but the traffic should be rejected before origin processing, not routed through another network hub; it does not optimize the required traffic path.
- NAT gateways handle outbound IPv4 connections from private workloads and do not provide inbound request throttling for a CloudFront-delivered API. Here, the expensive traffic is viewer-to-origin request volume rather than server egress translation; this alternative adds cost or capability that the workload does not require.
Question 17
A non-production batch pipeline has a producer and consumer that exchange multiple terabytes daily. Both components can tolerate a single-AZ maintenance window, and no availability requirement forces them into separate zones. What placement change can reduce network-transfer charges?
- Place each component in a different Availability Zone
- Place the communicating resources in the same Availability Zone
- Place the consumer in a second AWS Region
- Route the traffic through AWS Global Accelerator
Correct Answer(s)
B
Rationale
- Separating components across zones can improve fault isolation, but it deliberately makes every producer-consumer byte cross an AZ boundary and can add transfer charges. Because the stated priority permits a lower-resilience placement to reduce network spend, this approach would not remove the charge or transfer pattern identified in the question.
- AWS data transfer pricing can apply when traffic crosses Availability Zones, while keeping a high-volume path within one AZ can avoid that inter-AZ component where the resilience trade-off is acceptable. In the stated architecture, the workload is explicitly non-production and can accept single-AZ placement for this chatty path; choosing this option targets the measured source of spend.
- Cross-Region placement introduces a wider transfer boundary and is normally more expensive than same-Region, same-AZ communication for a tightly coupled data stream. For the stated workload, there is no geographic or disaster-recovery requirement for this batch exchange; selecting this would optimize the wrong layer.
- Global Accelerator optimizes paths for supported client-to-endpoint traffic but adds service charges and does not remove inter-AZ transfer between two internal batch components. The architecture needs a different lever because the two resources can be co-located instead of adding an acceleration service; this option would not materially reduce the targeted spend.
Question 18
A company has a 10 Gbps Direct Connect connection that has remained below 500 Mbps even during monthly peaks. Forecasts show no material growth, and the organization wants to reduce fixed connectivity cost while retaining Direct Connect. What is the best next step?
- Right-size the Direct Connect capacity to a lower connection speed that still covers measured peaks
- Add a second 10 Gbps connection and split traffic evenly for the current application path
- Replace Direct Connect with CloudFront Origin Shield as the selected network route for these requests
- Route Direct Connect traffic through a NAT gateway as the primary route for this traffic
Correct Answer(s)
A
Rationale
- Direct Connect port-hour pricing varies with connection type and capacity, so sustained utilization data should inform a smaller connection or hosted capacity when the existing port is materially oversized. Operationally, observed peak demand is far below provisioned bandwidth and no near-term growth justifies the larger port; the option therefore reduces unnecessary transfer or fixed networking charges.
- A second high-capacity connection may improve resilience or throughput, but it adds connectivity cost and is not justified solely by low utilization on the current port. The scenario specifies that the objective is to reduce excess capacity rather than increase it; this alternative does not align with that traffic or billing characteristic.
- Origin Shield is a CDN caching feature and does not provide private WAN connectivity between an enterprise network and AWS. Using this would be reasonable only under different constraints, because the company explicitly wants to keep Direct Connect while lowering fixed capacity cost; the current requirement points elsewhere.
- NAT gateways translate VPC egress and add processing charges; they do not reduce the provisioned bandwidth or port-hour cost of Direct Connect. This does not fit the cost model: the excessive cost is tied to an oversized dedicated connection; another choice removes the unnecessary network charge more directly.
Question 19
An application in us-east-1 sends several terabytes each day to a processing service in us-west-2 only because that service was deployed there years ago. There is no latency, compliance, or disaster-recovery requirement for separate Regions. Which change should be evaluated to reduce transfer cost?
- Add inter-Region VPC peering and keep the deployment unchanged for the affected workload
- Insert a Transit Gateway in each Region and peer them for this design
- Send the traffic through CloudFront as the main network path for this workload
- Move or redeploy the processing service into the same Region as the application
Correct Answer(s)
D
Rationale
- Inter-Region VPC peering provides private connectivity over the AWS backbone, but inter-Region transfer charges still apply to traffic crossing Regions. The mismatch is that the expensive boundary is the Region split itself rather than use of the public internet; this option introduces or retains charges that the preferred design avoids.
- Transit Gateway peering can create scalable inter-Region routing, but it adds attachment or routing complexity and does not make unnecessary cross-Region traffic free. In context, the workload does not need to remain distributed across Regions; this would spend money on a capability that is not required.
- CloudFront is optimized for viewer-facing content delivery and cacheable origin traffic; it is not a general replacement for high-volume private service-to-service processing flows. The workload does not benefit from this choice because the producer and processor can be placed together instead of adding an edge service; its primary cost remains unchanged.
- Cross-Region traffic can incur inter-Region data-transfer charges, so placing tightly coupled components in one Region removes an unnecessary regional network boundary when no business requirement depends on it. The workload profile shows that the two services are chatty and the historical Region split provides no required benefit; this design is therefore the best financial fit without breaking the requirement.
Question 20
An internet-facing Application Load Balancer fronts EC2 web targets in private subnets. The target instances still have public IPv4 addresses from an older design, but all client traffic enters through the ALB and administrators use Systems Manager. What should be removed to cut avoidable network-related cost?
- Remove the ALB and expose every instance directly to the internet
- Add Elastic IP addresses to every target for this traffic path
- Remove the public IPv4 addresses from the private EC2 targets
- Replace the private subnets with public subnets for the affected workload
Correct Answer(s)
C
Rationale
- Direct instance exposure would discard centralized load balancing and require public reachability for each target, increasing operational and security complexity rather than preserving the intended architecture. Applying this service would not help here, since the ALB is the required public entry point and only target public addresses are redundant; the scenario calls for a more targeted network change.
- Elastic IP addresses would preserve or increase public IPv4 allocation rather than eliminate unnecessary address-related cost from privately hosted targets. The design goal is narrower than this option assumes because all inbound application traffic already terminates at the load balancer; the added capability is not justified by the savings.
- Targets behind an internet-facing ALB can remain privately addressed, and Systems Manager can provide management paths without requiring direct public addressing when its connectivity requirements are met. Since the measured traffic pattern shows that the instances do not need public ingress or administration and public IPv4 addresses provide no required function, this selection avoids paying for unused network features.
- Changing subnet routing to public internet access is not necessary for load-balanced targets and would not address the requirement to remove unneeded public addressing. This is not the best answer because the workload can function privately behind the existing public ALB; the proposed component does not change the expensive path identified.