Cost Optimization practice questions

An application runs on an EC2 Auto Scaling group. Over the last month, CPU utilization averaged 8% with no sustained memory pressure, and response times are stable. The team wants to lower monthly cost without changing the application. What is the most appropriate next step for cost optimization?

Trap 1: Increase desired capacity to 2x so utilization increases and…

Increasing desired capacity to 2x simply launches additional instances, which multiplies compute costs for a workload that is already underutilizing its current instances. The hypothesis that higher utilization means 'more efficient' confuses efficiency with artificially inflating activity; spreading the same load across twice the instances would actually reduce per-instance CPU utilization further, not improve it. This action increases total infrastructure cost and fails to address the underlying overprovisioning, making it the opposite of the optimal cost-optimization move.

Trap 2: Disable Auto Scaling so the group never scales down to preserve…

Disabling Auto Scaling would remove the group's ability to terminate unnecessary instances during low-demand periods, locking in wasted spend on idle capacity. While a static size might preserve baseline performance, it sacrifices the elasticity that keeps infrastructure aligned with actual demand, and the scenario indicates consistent low utilization—so a smaller, right-sized instance type (not disabling scaling) is the better remedy. Moreover, disabling scaling also reduces fault tolerance because the group can no longer self-heal or respond to spikes without manual intervention.

Trap 3: Switch the workload to Spot instances immediately to avoid…

Spot Instances can offer significant discounts, but they come with a two-minute interruption warning when EC2 reclaims capacity, making them unsuitable for workloads without fault tolerance or checkpointing. The scenario provides no evidence that this application is interruption-tolerant or stateless, so a blanket switch immediately exposes it to availability risks. Right-sizing the On-Demand fleet based on observed utilization is a safer, more appropriate first cost-optimization step; Spot should only be considered after confirming the workload can handle interruptions.

A
Evaluate a smaller EC2 instance type (via the Auto Scaling launch template/configuration) for the group and validate performance metrics after the change.
Right-sizing involves analyzing historical utilization metrics (e.g., CloudWatch CPU, memory) to select a less expensive instance type while still satisfying workload requirements. Changing the Auto Scaling group's launch template to a smaller instance type, then monitoring metrics such as CPU credit balance, latency, and throughput, confirms the new size can handle peak demand. This directly lowers per-instance cost without altering the number of instances needed, providing cost savings while preserving availability and performance characteristics.
B
Increase desired capacity to 2x so utilization increases and instances become “more efficient.”
Why it fails: Increasing desired capacity to 2x simply launches additional instances, which multiplies compute costs for a workload that is already underutilizing its current instances. The hypothesis that higher utilization means 'more efficient' confuses efficiency with artificially inflating activity; spreading the same load across twice the instances would actually reduce per-instance CPU utilization further, not improve it. This action increases total infrastructure cost and fails to address the underlying overprovisioning, making it the opposite of the optimal cost-optimization move.
C
Disable Auto Scaling so the group never scales down to preserve baseline performance.
Why it fails: Disabling Auto Scaling would remove the group's ability to terminate unnecessary instances during low-demand periods, locking in wasted spend on idle capacity. While a static size might preserve baseline performance, it sacrifices the elasticity that keeps infrastructure aligned with actual demand, and the scenario indicates consistent low utilization—so a smaller, right-sized instance type (not disabling scaling) is the better remedy. Moreover, disabling scaling also reduces fault tolerance because the group can no longer self-heal or respond to spikes without manual intervention.
D
Switch the workload to Spot instances immediately to avoid On-Demand charges, regardless of interruption risk.
Why it fails: Spot Instances can offer significant discounts, but they come with a two-minute interruption warning when EC2 reclaims capacity, making them unsuitable for workloads without fault tolerance or checkpointing. The scenario provides no evidence that this application is interruption-tolerant or stateless, so a blanket switch immediately exposes it to availability risks. Right-sizing the On-Demand fleet based on observed utilization is a safer, more appropriate first cost-optimization step; Spot should only be considered after confirming the workload can handle interruptions.

Question 2mediummultiple choice

A media company runs a 24/7 recommendation engine on EC2 in one AWS Region. The workload is interruption-intolerant, and the team expects steady usage but may change instance families and sizes during planned optimizations. Compared to the current On-Demand setup, they want the lowest cost while avoiding the rigidity of locking to a specific instance type.

What should the solutions architect recommend?

Trap 1: Switch the instances to Spot Instances and use interruption…

Spot Instances offer steep discounts (often up to 90%) but EC2 can reclaim them with only a two-minute warning when capacity is needed elsewhere, making them unsuitable for an interruption-intolerant service like a 24/7 recommendation engine that must deliver results continuously. Even with sophisticated interruption handling (checkpointing, diversified instance pools), you still face the risk of losing capacity, which breaks the workload's availability guarantees. In short, the largest discount is worthless if the workload cannot tolerate interruptions, which is why the correct answer is a Compute Savings Plan that combines significant savings with reliable capacity.

Trap 2: Purchase a Standard Reserved Instance tied to a single specific…

A Standard Reserved Instance locks you to a specific instance family and size (e.g., m5.large) for a 1- or 3-year term, and any change to a different instance type requires a modification or exchange that may not fully preserve the discount. For a media recommendation engine that might need to adopt newer instance families with better ML acceleration or newer CPU generations, this rigidity often results in overpaying or running a mismatched fleet. Compute Savings Plans cover the same steady hourly usage but allow the flexibility to change instance types without losing the commitment benefit.

Trap 3: Keep On-Demand and rely on Auto Scaling to reduce capacity when…

Auto Scaling with On-Demand instances adjusts capacity to match demand, but the workload in question runs 24/7 with steady utilization, meaning the baseline capacity must stay constantly active and incurs On-Demand rates every hour. Auto Scaling can shave off unused capacity during occasional lulls, but it cannot lower the per-hour price paid for the predictable baseline, so the total compute cost remains far higher than any commitment-based option. The best practice is to pair Auto Scaling with a Savings Plan, not to rely on Auto Scaling alone as the primary cost-control mechanism.

A
Switch the instances to Spot Instances and use interruption handling because it is the largest discount.
Why it fails: Spot Instances offer steep discounts (often up to 90%) but EC2 can reclaim them with only a two-minute warning when capacity is needed elsewhere, making them unsuitable for an interruption-intolerant service like a 24/7 recommendation engine that must deliver results continuously. Even with sophisticated interruption handling (checkpointing, diversified instance pools), you still face the risk of losing capacity, which breaks the workload's availability guarantees. In short, the largest discount is worthless if the workload cannot tolerate interruptions, which is why the correct answer is a Compute Savings Plan that combines significant savings with reliable capacity.
B
Purchase a Compute Savings Plan for the expected steady hourly usage in that Region.
Compute Savings Plans offer lower hourly rates in exchange for a 1- or 3-year commitment, but the discount applies to any EC2 instance family/type/size in the chosen Region (even Fargate/Lambda). Because the recommendation engine runs 24/7, committing to the expected steady hourly usage captures the discount while preserving the ability to change instance families or sizes as needs evolve. Unlike Standard RIs, you're not locked into a specific instance type, so you get both cost savings and operational flexibility.
C
Purchase a Standard Reserved Instance tied to a single specific instance type for the next 3 years.
Why it fails: A Standard Reserved Instance locks you to a specific instance family and size (e.g., m5.large) for a 1- or 3-year term, and any change to a different instance type requires a modification or exchange that may not fully preserve the discount. For a media recommendation engine that might need to adopt newer instance families with better ML acceleration or newer CPU generations, this rigidity often results in overpaying or running a mismatched fleet. Compute Savings Plans cover the same steady hourly usage but allow the flexibility to change instance types without losing the commitment benefit.
D
Keep On-Demand and rely on Auto Scaling to reduce capacity when utilization is low.
Why it fails: Auto Scaling with On-Demand instances adjusts capacity to match demand, but the workload in question runs 24/7 with steady utilization, meaning the baseline capacity must stay constantly active and incurs On-Demand rates every hour. Auto Scaling can shave off unused capacity during occasional lulls, but it cannot lower the per-hour price paid for the predictable baseline, so the total compute cost remains far higher than any commitment-based option. The best practice is to pair Auto Scaling with a Savings Plan, not to rely on Auto Scaling alone as the primary cost-control mechanism.

Read the full NAT/PAT explanation →

Question 3hardmultiple choice

A batch analytics job currently uses two NAT gateways in each of three Availability Zones, but only one private subnet per AZ needs outbound internet access. What should the architect review first?

Trap 1: Replacing every NAT gateway with an internet gateway attached to…

An internet gateway (IGW) is a VPC-level resource, not a per-subnet device, and it cannot be 'attached' to private subnets. When a private subnet routes 0.0.0.0/0 to an IGW, instances would need public IP addresses to actually reach the internet; without them the route is ineffective, and with them the subnet is effectively public. An IGW permits bidirectional traffic, so inbound connections from the internet can reach those resources, completely undermining the isolation that private subnets and NAT gateways are designed to provide. Replacing NAT gateways with IGWs does not preserve outbound-only access and is not a valid cost optimization.

Trap 2: Disabling route tables

Disabling route tables is not a valid operation in AWS, and more importantly, route tables are the essential mechanism that tells each subnet where to send traffic. Every private subnet that uses a NAT gateway must have a route table with a 0.0.0.0/0 entry pointing to that gateway; without that route, the batch job's outbound internet traffic would have no path and would be dropped, breaking the analytics pipeline. Disabling or deleting route tables would also disrupt internal VPC routing, not just internet access, so it would cause a full network outage rather than any cost savings. The correct optimization is to simplify or consolidate routing, not to remove the routing layer itself.

Trap 3: Moving all workloads to public subnets

Moving all workloads to public subnets would require assigning public IP addresses and routing traffic directly through an internet gateway, which exposes the batch analytics instances to unsolicited inbound internet traffic. This fundamentally violates defense-in-depth principles because private subnets exist to keep sensitive data and processing logic inaccessible from the public internet, and many compliance frameworks mandate that data-processing workloads remain private. While this change could eliminate NAT gateway costs, it is not a cost-first best practice because the security risk and potential compliance breach far outweigh the savings; a better cost play is to right-size the NAT gateway count, not expose the workload.

A
Replacing every NAT gateway with an internet gateway attached to private subnets
Why it fails: An internet gateway (IGW) is a VPC-level resource, not a per-subnet device, and it cannot be 'attached' to private subnets. When a private subnet routes 0.0.0.0/0 to an IGW, instances would need public IP addresses to actually reach the internet; without them the route is ineffective, and with them the subnet is effectively public. An IGW permits bidirectional traffic, so inbound connections from the internet can reach those resources, completely undermining the isolation that private subnets and NAT gateways are designed to provide. Replacing NAT gateways with IGWs does not preserve outbound-only access and is not a valid cost optimization.
B
Whether one NAT gateway per AZ is sufficient for the required private subnets
The right cost-optimization review here is to ask whether the batch analytics job truly needs a NAT gateway in every Availability Zone or whether one per AZ is sufficient. A NAT gateway is a zonal resource, and the standard high-availability pattern is to deploy one per AZ and route each AZ's private subnets to its local gateway; having two NAT gateways in the same AZ adds no resiliency because an AZ failure affects both, and the second gateway only doubles the hourly and per-GB costs. If the batch job is not required to be highly available or can tolerate an AZ outage, a single NAT gateway per AZ (or even one total) could be enough, which is exactly what should be evaluated before paying for four gateways.
C
Disabling route tables
Why it fails: Disabling route tables is not a valid operation in AWS, and more importantly, route tables are the essential mechanism that tells each subnet where to send traffic. Every private subnet that uses a NAT gateway must have a route table with a 0.0.0.0/0 entry pointing to that gateway; without that route, the batch job's outbound internet traffic would have no path and would be dropped, breaking the analytics pipeline. Disabling or deleting route tables would also disrupt internal VPC routing, not just internet access, so it would cause a full network outage rather than any cost savings. The correct optimization is to simplify or consolidate routing, not to remove the routing layer itself.
D
Moving all workloads to public subnets
Why it fails: Moving all workloads to public subnets would require assigning public IP addresses and routing traffic directly through an internet gateway, which exposes the batch analytics instances to unsolicited inbound internet traffic. This fundamentally violates defense-in-depth principles because private subnets exist to keep sensitive data and processing logic inaccessible from the public internet, and many compliance frameworks mandate that data-processing workloads remain private. While this change could eliminate NAT gateway costs, it is not a cost-first best practice because the security risk and potential compliance breach far outweigh the savings; a better cost play is to right-size the NAT gateway count, not expose the workload.

Question 4easymultiple choice

CloudWatch metrics show your EC2 instances have average CPU utilization around 10% with stable performance over several weeks. The application does not require additional headroom right now. What is the most effective cost-optimization action?

Trap 1: Increase the Auto Scaling desired capacity to add more instances

Adding more instances increases total compute capacity and typically increases cost, even if CPU utilization is low. Auto Scaling is intended to respond to demand changes; raising desired capacity without a demand need does not address the current overprovisioning.

Trap 2: Switch to Spot Instances immediately even though interruptions…

Switching to Spot is a pricing decision that introduces interruption risk. The scenario’s primary measurable issue is persistent underutilization; switching to Spot would be unnecessary and potentially risky given the stated interruption impact. Cost optimization here should first target the dominant cost lever: oversized compute.

Trap 3: Disable detailed monitoring to reduce CPU usage from the monitoring…

Reducing monitoring detail might lower monitoring charges, but it does not address the main driver of EC2 cost: unused instance capacity. Any CPU impact from monitoring is usually minor compared with the savings from downsizing instances.

A
Right-size the instances to a smaller size that matches the observed utilization
Right sizing reduces cost by matching instance capacity to actual demand. If average CPU is consistently low (around 10%) and performance is stable, it strongly indicates overprovisioning. Moving to a smaller instance (or a smaller capability within the same family) typically lowers hourly cost while maintaining sufficient capacity for the workload.
B
Increase the Auto Scaling desired capacity to add more instances
Why it fails: Adding more instances increases total compute capacity and typically increases cost, even if CPU utilization is low. Auto Scaling is intended to respond to demand changes; raising desired capacity without a demand need does not address the current overprovisioning.
C
Switch to Spot Instances immediately even though interruptions would impact users
Why it fails: Switching to Spot is a pricing decision that introduces interruption risk. The scenario’s primary measurable issue is persistent underutilization; switching to Spot would be unnecessary and potentially risky given the stated interruption impact. Cost optimization here should first target the dominant cost lever: oversized compute.
D
Disable detailed monitoring to reduce CPU usage from the monitoring agent
Why it fails: Reducing monitoring detail might lower monitoring charges, but it does not address the main driver of EC2 cost: unused instance capacity. Any CPU impact from monitoring is usually minor compared with the savings from downsizing instances.

Question 5hardmulti select

A retailer runs a reporting-heavy relational app on Amazon RDS MySQL. Peak dashboard traffic lasts only three hours each day, but the database is sized for the peak all day. The business wants lower cost without rewriting the application. Which three actions are best? Select three.

Trap 1: Migrate to DynamoDB immediately because every relational workload…

DynamoDB is non-relational, so the reporting application's SQL joins and schema would need rewriting, which the business explicitly excluded. It is tempting because DynamoDB removes server management and scales elastically, making it the right choice for new key-value or document workloads with known access patterns.

Trap 2: Increase provisioned IOPS permanently so the monthly bill drops.

Raising provisioned IOPS permanently increases the hourly storage charge, so the bill rises rather than falls. It is tempting because IOPS tuning genuinely fixes throttling on steady high-throughput databases, making it correct when sustained I/O demand, not a three-hour daily peak, drives performance.

A
Right-size the writer based on actual utilization instead of peak guesses.
Right-sizing the writer to actual utilisation rather than peak guesses reduces instance cost while preserving the existing MySQL application. It directly addresses the stem's constraint that the database is over-provisioned for all-day peak, requiring no application rewrite.
B
Add read replicas and direct dashboard traffic away from the writer.
Read replicas offload dashboard read queries from the writer, letting the primary be sized for write workload rather than peak reporting traffic. This reduces cost without rewriting the application, satisfying the three-hour peak constraint by scaling reads independently.
C
Evaluate Aurora MySQL if the current replica-heavy design would be cheaper there.
Correct. Aurora can be more cost-efficient than a replica-heavy RDS topology because storage is shared across the cluster and replicas are simpler to operate. It is a reasonable tradeoff to evaluate when read scaling is the main issue.
D
Migrate to DynamoDB immediately because every relational workload is more expensive.
Why it fails: DynamoDB is non-relational, so the reporting application's SQL joins and schema would need rewriting, which the business explicitly excluded. It is tempting because DynamoDB removes server management and scales elastically, making it the right choice for new key-value or document workloads with known access patterns.
E
Increase provisioned IOPS permanently so the monthly bill drops.
Why it fails: Raising provisioned IOPS permanently increases the hourly storage charge, so the bill rises rather than falls. It is tempting because IOPS tuning genuinely fixes throttling on steady high-throughput databases, making it correct when sustained I/O demand, not a three-hour daily peak, drives performance.

Question 6easymultiple choice

A media company runs a batch job that processes image thumbnails. The job can be restarted from checkpoints and does not have user-facing SLAs. The batch capacity can tolerate interruptions. Which EC2 purchasing option is the best cost optimization choice?

Trap 1: Use On-Demand Instances because interruptions are not allowed for…

On-Demand Instances eliminate the risk of EC2 interruptions because you pay a higher, per-second rate for guaranteed capacity, but AWS does not forbid production workloads from using interrupting instances. The real constraint is application resilience: if the thumbnail job uses checkpointing to S3 or a shared filesystem, it can run on Spot even in production. Choosing On-Demand purely because 'production' implies no interruptions is incorrect and unnecessarily expensive for fault-tolerant batch processing.

Trap 2: Purchase Reserved Instances because they provide a discount…

Reserved Instances require a 1- or 3-year commitment and provide a discounted hourly rate only while an instance is running; if the batch job is short or sporadic, you still pay for the entire commitment even during idle time. Standard RIs are designed for predictable 24/7 or steady-state workloads, not for interruptible batch jobs that may run at irregular intervals. The discount is tied to a term, not to workload timing, so it can actually increase costs if the cluster is not continuously utilized.

Trap 3: Buy Savings Plans because they guarantee capacity and remove the…

Savings Plans are a flexible pricing model that exchanges a committed hourly spend (1- or 3-year term) for lower compute rates, but they do not guarantee capacity or provide any protection against Spot reclamation. Even if Spot usage is covered under a Savings Plan, the underlying instances can still be interrupted by EC2 at any time. Additionally, committing to a Savings Plan for a batch workload that runs only occasionally means you pay for a fixed compute baseline whether or not the job is running.

A
Use On-Demand Instances because interruptions are not allowed for production workloads.
Why it fails: On-Demand Instances eliminate the risk of EC2 interruptions because you pay a higher, per-second rate for guaranteed capacity, but AWS does not forbid production workloads from using interrupting instances. The real constraint is application resilience: if the thumbnail job uses checkpointing to S3 or a shared filesystem, it can run on Spot even in production. Choosing On-Demand purely because 'production' implies no interruptions is incorrect and unnecessarily expensive for fault-tolerant batch processing.
B
Use EC2 Spot Instances, accepting the possibility of interruptions and using checkpoints to resume.
EC2 Spot Instances offer spare compute capacity at discounts of up to 90% compared to On-Demand. Although AWS can reclaim capacity with a two-minute interruption notice, the thumbnail batch can be made resilient by checkpointing progress to Amazon S3 or Amazon EFS and resuming from the last completed step. Because image processing is idempotent and time-flexible, this provides the lowest cost without losing completed work.
C
Purchase Reserved Instances because they provide a discount regardless of the workload timing.
Why it fails: Reserved Instances require a 1- or 3-year commitment and provide a discounted hourly rate only while an instance is running; if the batch job is short or sporadic, you still pay for the entire commitment even during idle time. Standard RIs are designed for predictable 24/7 or steady-state workloads, not for interruptible batch jobs that may run at irregular intervals. The discount is tied to a term, not to workload timing, so it can actually increase costs if the cluster is not continuously utilized.
D
Buy Savings Plans because they guarantee capacity and remove the risk of interruptions entirely.
Why it fails: Savings Plans are a flexible pricing model that exchanges a committed hourly spend (1- or 3-year term) for lower compute rates, but they do not guarantee capacity or provide any protection against Spot reclamation. Even if Spot usage is covered under a Savings Plan, the underlying instances can still be interrupted by EC2 at any time. Additionally, committing to a Savings Plan for a batch workload that runs only occasionally means you pay for a fixed compute baseline whether or not the job is running.

Read the full NAT/PAT explanation →

Question 7hardmultiple choice

A batch analytics job currently uses two NAT gateways in each of three Availability Zones, but only one private subnet per AZ needs outbound internet access. What should the architect review first? The design must avoid adding custom operational scripts.

Trap 1: Replacing every NAT gateway with an internet gateway attached to…

An internet gateway (IGW) attaches to a VPC, not directly to subnets, and its default behavior is to provide internet connectivity only to resources that have public IPv4 addresses or are using IPv6. A private subnet's instances typically lack public IPs, so an IGW cannot be used as a direct next hop for them; attempting this forces you to assign public IPs, destroying the private-subnet security model. To enable outbound-only internet access from private subnets, you must route 0.0.0.0/0 to a NAT gateway or NAT instance in a public subnet, not to an IGW.

Trap 2: Disabling route tables

Route tables are mandatory VPC components; every subnet must be associated with a route table, and AWS does not allow you to 'disable' or delete the main route table or the route tables required for the VPC to function. Removing or disabling route tables would break all routing in the private subnets, cutting off the batch job from the NAT gateway, other VPC resources, and any connected services. Cost savings cannot justify eliminating the core routing mechanism, and the correct approach is to review and prune unused route entries rather than disabling the tables themselves.

Trap 3: Moving all workloads to public subnets

Placing all batch workloads in public subnets would remove the need for NAT gateways, but this dramatically increases the attack surface, as every instance would receive a public IP and be directly reachable from the internet. It would also require reconfiguring security groups and network ACLs to mitigate exposure, and may incur costs for Elastic IPs if static addresses are needed, making the 'savings' from NAT gateways illusory. Cost optimization must preserve the security architecture's intent—private instances with controlled egress—not shift the workload to an openly exposed environment.

A
Replacing every NAT gateway with an internet gateway attached to private subnets
Why it fails: An internet gateway (IGW) attaches to a VPC, not directly to subnets, and its default behavior is to provide internet connectivity only to resources that have public IPv4 addresses or are using IPv6. A private subnet's instances typically lack public IPs, so an IGW cannot be used as a direct next hop for them; attempting this forces you to assign public IPs, destroying the private-subnet security model. To enable outbound-only internet access from private subnets, you must route 0.0.0.0/0 to a NAT gateway or NAT instance in a public subnet, not to an IGW.
B
Whether one NAT gateway per AZ is sufficient for the required private subnets
NAT gateways are provisioned per Availability Zone, and the standard high-availability pattern is one NAT gateway per AZ, not multiple in the same AZ. If the batch analytics job runs in only one AZ or its required private subnets are all within a single AZ, a second NAT gateway in that same AZ provides no additional resilience while doubling the hourly and data-processing charges. The cost optimization is to confirm that each AZ contains at least one private subnet needing egress; if not, the NAT gateway count should be reduced to one per AZ with active private workloads.
C
Disabling route tables
Why it fails: Route tables are mandatory VPC components; every subnet must be associated with a route table, and AWS does not allow you to 'disable' or delete the main route table or the route tables required for the VPC to function. Removing or disabling route tables would break all routing in the private subnets, cutting off the batch job from the NAT gateway, other VPC resources, and any connected services. Cost savings cannot justify eliminating the core routing mechanism, and the correct approach is to review and prune unused route entries rather than disabling the tables themselves.
D
Moving all workloads to public subnets
Why it fails: Placing all batch workloads in public subnets would remove the need for NAT gateways, but this dramatically increases the attack surface, as every instance would receive a public IP and be directly reachable from the internet. It would also require reconfiguring security groups and network ACLs to mitigate exposure, and may incur costs for Elastic IPs if static addresses are needed, making the 'savings' from NAT gateways illusory. Cost optimization must preserve the security architecture's intent—private instances with controlled egress—not shift the workload to an openly exposed environment.

Question 8mediummulti select

A company is migrating its on-premises workloads to AWS and wants to optimize costs. Which three strategies should the company implement to achieve a cost-optimized architecture? (Choose three.)

Trap 1: Provision additional EC2 instances to handle peak load at all…

Provisioning additional EC2 instances to handle peak load at all times is an inefficient and costly approach. This strategy leads to significant over-provisioning during off-peak periods, where a large portion of the allocated resources remains idle and unused. Consequently, the company incurs unnecessary expenses for compute capacity that is not actively contributing to workload performance, directly contradicting cost optimization goals.

Trap 2: Store all data in Amazon S3 Standard storage class to avoid any…

Storing all data exclusively in Amazon S3 Standard storage class is not an optimal cost-saving strategy, as S3 Standard does incur data retrieval costs, albeit typically lower than other classes for frequent access. For data that is accessed less frequently or archived, using lifecycle policies to transition objects to S3 Infrequent Access, Glacier, or Glacier Deep Archive would yield significant storage cost reductions, despite potentially higher retrieval fees or longer retrieval times.

Trap 3: Deploy all resources in a single Availability Zone to minimize data…

Deploying all resources within a single Availability Zone (AZ) to minimize data transfer costs is a critical misstep for production workloads. While it might reduce cross-AZ data transfer charges, this approach creates a single point of failure, severely compromising the application's high availability and fault tolerance. The potential cost savings are far outweighed by the increased risk of downtime and data loss in the event of an AZ-wide outage.

A
Use Reserved Instances or Savings Plans for predictable workloads to reduce costs compared to On-Demand pricing.
Using Reserved Instances (RIs) or Savings Plans (SPs) is a highly effective cost optimization strategy for workloads with predictable, consistent resource usage over a 1-year or 3-year term. By committing to a specific instance family, region, or compute usage, customers receive substantial discounts, often up to 72% compared to On-Demand pricing, significantly reducing the total cost of ownership for stable applications.
B
Provision additional EC2 instances to handle peak load at all times, ensuring maximum performance.
Why it fails: Provisioning additional EC2 instances to handle peak load at all times is an inefficient and costly approach. This strategy leads to significant over-provisioning during off-peak periods, where a large portion of the allocated resources remains idle and unused. Consequently, the company incurs unnecessary expenses for compute capacity that is not actively contributing to workload performance, directly contradicting cost optimization goals.
C
Implement auto scaling to match capacity with demand, avoiding over-provisioning and reducing waste.
Implementing Amazon EC2 Auto Scaling is a fundamental cost optimization technique that dynamically adjusts compute capacity to match actual demand. By automatically launching or terminating instances based on predefined metrics, Auto Scaling prevents both over-provisioning during low demand and under-provisioning during peak loads, ensuring optimal resource utilization and significantly reducing wasted expenditure on idle resources.
D
Use Spot Instances for fault-tolerant, flexible workloads to achieve significant cost savings.
Leveraging Spot Instances offers the most substantial cost savings, often up to 90% compared to On-Demand prices, for fault-tolerant and flexible workloads. These instances utilize unused EC2 capacity and are suitable for batch processing, stateless applications, or development/testing environments that can tolerate interruptions, as AWS can reclaim them with a two-minute warning.
E
Store all data in Amazon S3 Standard storage class to avoid any data retrieval costs.
Why it fails: Storing all data exclusively in Amazon S3 Standard storage class is not an optimal cost-saving strategy, as S3 Standard does incur data retrieval costs, albeit typically lower than other classes for frequent access. For data that is accessed less frequently or archived, using lifecycle policies to transition objects to S3 Infrequent Access, Glacier, or Glacier Deep Archive would yield significant storage cost reductions, despite potentially higher retrieval fees or longer retrieval times.
F
Deploy all resources in a single Availability Zone to minimize data transfer costs.
Why it fails: Deploying all resources within a single Availability Zone (AZ) to minimize data transfer costs is a critical misstep for production workloads. While it might reduce cross-AZ data transfer charges, this approach creates a single point of failure, severely compromising the application's high availability and fault tolerance. The potential cost savings are far outweighed by the increased risk of downtime and data loss in the event of an AZ-wide outage.

Read the full NAT/PAT explanation →

Question 9hardmultiple choice

A batch analytics job currently uses two NAT gateways in each of three Availability Zones, but only one private subnet per AZ needs outbound internet access. What should the architect review first? The architecture review board prefers a managed AWS-native control.

Trap 1: Replacing every NAT gateway with an internet gateway attached to…

An internet gateway is a VPC-level component that only provides direct internet access to instances with public IP addresses and a route table entry targeting the IGW; it does not perform source NAT for private instances. Private subnets have no public IPs, so replacing NAT gateways with IGWs would neither route outbound traffic nor support return traffic. IGWs are also free, but requiring public IPs destroys the private subnet boundary and is not a like-for-like replacement.

Trap 2: Disabling route tables

Route tables are mandatory for all subnets; every subnet must be associated with a route table, and each route table must contain at least the local VPC route to allow internal communication. There is no supported operation to 'disable' a route table, and doing so would cause all traffic in the affected subnets to fail, including the VPC-internal traffic required by the batch analytics job. This is not a valid cost-optimization action and would break networking entirely.

Trap 3: Moving all workloads to public subnets

Moving batch workloads to public subnets would require assigning public IP addresses and adding internet gateway routes, exposing the instances to inbound internet traffic and significantly increasing the attack surface. Security groups and network ACLs would need major redesign, and the private-subnet architecture that supports outbound-only internet access would be lost. Eliminating NAT gateway costs by placing workloads in public subnets is a security anti-pattern, not a cost-first best practice, and it fundamentally changes the system's networking model.

A
Replacing every NAT gateway with an internet gateway attached to private subnets
Why it fails: An internet gateway is a VPC-level component that only provides direct internet access to instances with public IP addresses and a route table entry targeting the IGW; it does not perform source NAT for private instances. Private subnets have no public IPs, so replacing NAT gateways with IGWs would neither route outbound traffic nor support return traffic. IGWs are also free, but requiring public IPs destroys the private subnet boundary and is not a like-for-like replacement.
B
Whether one NAT gateway per AZ is sufficient for the required private subnets
NAT gateways are zonal resources, and AWS best practice is to deploy one per Availability Zone for high availability; multiple NAT gateways in the same AZ offer no added resilience because an AZ failure takes them all down. Before optimizing cost, verify whether each private subnet in each AZ actually needs outbound NAT capacity. If batch workloads run primarily in one AZ or can tolerate reduced availability, a single NAT gateway may be sufficient, but cross-AZ traffic from other AZs will incur inter-AZ data transfer charges in addition to the NAT gateway hourly and per-GB processing costs.
C
Disabling route tables
Why it fails: Route tables are mandatory for all subnets; every subnet must be associated with a route table, and each route table must contain at least the local VPC route to allow internal communication. There is no supported operation to 'disable' a route table, and doing so would cause all traffic in the affected subnets to fail, including the VPC-internal traffic required by the batch analytics job. This is not a valid cost-optimization action and would break networking entirely.
D
Moving all workloads to public subnets
Why it fails: Moving batch workloads to public subnets would require assigning public IP addresses and adding internet gateway routes, exposing the instances to inbound internet traffic and significantly increasing the attack surface. Security groups and network ACLs would need major redesign, and the private-subnet architecture that supports outbound-only internet access would be lost. Eliminating NAT gateway costs by placing workloads in public subnets is a security anti-pattern, not a cost-first best practice, and it fundamentally changes the system's networking model.