Design Cost-Optimized Architectures practice questions

Keep all logs in S3 Standard and rely on lower request rates to reduce cost

Why wrong: Keeping all logs in S3 Standard while relying on lower request rates ignores the fact that S3 pricing separates storage cost from request cost. The storage cost per GB-month for S3 Standard is substantially higher than that of S3 Standard-IA or Glacier, so even with almost zero GET/PUT requests, your bill stays high simply because you are retaining large volumes of data in the most expensive object storage tier. Since the logs are rarely accessed after 30 days, a lifecycle policy that transitions them to a colder class directly attacks the dominant cost driver—storage footprint—rather than request activity, which is already negligible.

Copy logs to EBS snapshots each week and delete the original files

Why wrong: EBS snapshots are designed for point-in-time backups of EBS block storage volumes, not for object-level application log retention. Each snapshot is block-incremental and must be restored to a volume before you can access the files, making log retrieval and analysis cumbersome, and snapshot storage is billed per-GB with no native S3 lifecycle expiration policy. Additionally, deleting the original S3 objects forfeits S3 features such as server-side encryption, object-level versioning, and querying logs directly with Amazon Athena, while introducing new EC2/DLM management overhead—so this approach is both operationally heavier and costlier than a simple S3 lifecycle rule.

Use S3 replication to a second bucket in another region to reduce costs

Why wrong: S3 Cross-Region Replication (CRR) is a data durability and disaster-recovery feature, not a cost optimization feature. Enabling CRR adds replication request charges, inter-region data transfer charges, and a second storage charge for the replicated objects in the destination bucket; the source object's storage class remains unchanged and still incurs its original fee. Replicating to another region doubles the storage-related costs rather than reducing them, so it cannot be used to lower spend for long-term log retention.

Disable caching for the distribution so every request goes back to the origin

Why wrong: Disabling caching would force CloudFront to forward every single request to the S3 origin, completely removing the benefit of edge caches. This drastically increases origin request volume, AWS cost, and user-visible latency, especially for a static image workload. The goal is to maximize cache hits, so this option is strictly counterproductive.

Configure CloudFront to forward all request headers and query strings to the origin

Why wrong: Forwarding every request header and query string forces CloudFront to include each unique combination in the cache key, creating many distinct cache entries. For the same static image served with even slightly different query strings or headers, CloudFront cannot serve a cached copy, resulting in repeated origin fetches and a lower cache hit ratio. You should whitelist only the headers and query strings the origin actually uses.

Move the S3 bucket to a different AWS Region, without changing CloudFront caching behavior

Why wrong: Moving the S3 bucket to another AWS Region does not affect how CloudFront caches responses, because CloudFront's edge locations are global and the cache key and TTL behavior remain unchanged. The number of origin fetches is determined by cache misses and expiration times, not by the bucket's geographical location. While origin latency might improve for local users on a cache miss, it does nothing to reduce the frequency of misses.

Use Dedicated Hosts to ensure capacity for the cheapest instance

Why wrong: Dedicated Hosts are a physical-server model meant for satisfying strict licensing, compliance, or placement requirements, so they cost a premium per host and are not priced or optimized for short-lived, interruption-tolerant batch jobs. They provide guaranteed capacity, but that guarantee does not translate to the lowest cost; in fact, a per-host bill for a fleet of workers can far exceed the aggregate cost of Spot instances. Furthermore, the workload's ability to resume from checkpoints means it has no need for the dedicated tenancy or capacity control that Dedicated Hosts offer.

Use On-Demand instances and schedule extra runs to offset interruptions

Why wrong: On-Demand instances do not terminate unexpectedly, but their hourly price is substantially higher than Spot. Scheduling extra runs multiplies the total compute time, so you end up paying for more On-Demand hours just to compensate for failures that Spot would handle with checkpointing. The strategy also ignores the workload's already designed restart-from-checkpoint tolerance, making it a more expensive and less efficient approach than simply running Spot workers.

Use Reserved Instances only, because they eliminate instance termination events

Why wrong: Reserved Instances discount On-Demand pricing but do not eliminate all termination/interruption scenarios and do not provide the same level of discounting as Spot for workloads that can handle interruptions. This does not leverage the interruption tolerance that would enable the most cost savings.

Purchase Dedicated Hosts so the fleet keeps physical servers reserved for the workload.

Why wrong: Dedicated Hosts reserve entire physical servers exclusively for your use, which is beneficial for meeting strict licensing or compliance requirements, but it comes with a significant cost premium. You pay for the whole host regardless of how many instances run on it, making it very inefficient for a bursty batch job that only needs compute during rendering peaks. This option ignores the workload's fault-tolerant design and introduces unnecessary hardware commitment, so it is the opposite of a cost-minimization strategy.

Run the entire fleet on On-Demand Instances to avoid any interruption risk.

Why wrong: Running the entire fleet on On-Demand Instances eliminates interruption risk, but the job already handles interruptions gracefully by writing checkpoints to S3 and resuming from the latest checkpoint. The sharp queue depth variation means Spot Instances, which can be interrupted, would achieve the lowest compute cost by leveraging unused EC2 capacity at a steep discount. This option is tempting because On-Demand Instances guarantee continuous availability, making them the correct choice for workloads that cannot tolerate any interruption and lack checkpointing or resumption logic.

Move the workers to AWS Outposts to keep compute close to the data.

Why wrong: AWS Outposts brings native AWS services to your on-premises datacenter, which is useful for workloads with low-latency local data processing or strict data residency requirements. However, deploying workers on Outposts involves purchasing or long-term committing to physical infrastructure, adding capital expenditure and operational overhead rather than reducing costs. The rendering job already runs in the cloud and does not need local compute, so Outposts only increases cost and complexity without any benefit.

S3 Glacier Flexible Retrieval: Data accessed infrequently but requires rapid access when needed; retrieval time milliseconds

Why wrong: S3 Glacier Flexible Retrieval is an archival storage class with data access times ranging from 1 minute to several hours, not milliseconds as the scenario requires. The scenario describing rapid access with millisecond retrieval matches S3 Standard-IA, so assigning Glacier Flexible Retrieval is incorrect because it cannot meet the sub-second latency requirement and would also introduce unnecessary retrieval costs.

S3 Glacier Deep Archive: Data that can be retrieved within 1-5 minutes

Why wrong: S3 Glacier Deep Archive is the lowest-cost storage class, intended for long-term archival data with retrieval times of 12–48 hours. The scenario specifies data that can be retrieved within 1–5 minutes, which is characteristic of Glacier Flexible Retrieval, not Deep Archive; hence this option is wrong as it would fail to satisfy the defined retrieval-time constraint.

Buy EC2 On-Demand instances and rely on future Spot capacity for discounts

Why wrong: On-Demand pricing has no commitment-based discount, so a steady 24/7 workload generally remains costly. Relying on future Spot capacity does not match the predictable continuous demand and may also introduce interruptions unless the architecture is designed for them.

Buy Reserved Instances with a fixed instance type and region

Why wrong: Instance-specific Reserved Instances (Standard RIs) offer a significant discount over On-Demand but lock you into a specific instance family, size, and region for the entire term. Because the discount applies only when you run an exact matching instance, any migration to a newer generation, different family, or even a size change (e.g., from m5.large to m5.xlarge) can eliminate the discounted rate, leaving the committed capacity underutilized. For a 24/7 service that may need to evolve its infrastructure, this inflexibility makes Standard RIs less suitable than Compute Savings Plans, which automatically apply to any EC2 instance regardless of family or size changes.

Buy Spot Instances and stop scaling to avoid interruption risk

Why wrong: Spot provides lower pricing but can be interrupted when capacity is reclaimed. Stopping scaling does not remove interruption risk; it only changes how capacity is adjusted. For a 24/7 service, this can still cause outages unless substantial fault-tolerance is built.

Spot Instances: A production database server running 24/7 with predictable load

Why wrong: Spot Instances can be reclaimed by AWS at any moment, with only a two-minute warning, making them fundamentally unsuitable for a production database server that must be available 24/7 with predictable load. A production database cannot tolerate the risk of interruption, disk volatility, or potential data loss that Spot's cost-saving model introduces, so this pairing is incorrect even though Spot would minimize cost. The correct choice would be Reserved Instances or Savings Plans, which provide the reliability and persistent capacity this workload demands.

On-Demand: A fault-tolerant batch job that can handle interruptions

Why wrong: While On-Demand Instances can certainly run a fault-tolerant batch job because they provide reliable, non-interruptible compute, they are not the most directly appropriate pricing option for that workload. The entire point of a fault-tolerant job is its ability to handle interruptions, which makes Spot Instances dramatically more cost-effective—often at a tenth of the price—without sacrificing correctness. On-Demand's lack of commitment is wasted here because the workload does not require On-Demand's reliability and would incur unnecessarily high costs.

An S3 lifecycle policy that deletes objects after 1 day to eliminate storage costs

Why wrong: Deleting after 1 day would remove data before it can be used for occasional troubleshooting. Storage cost optimization must still respect retention and troubleshooting requirements; lifecycle rules should transition to cheaper classes rather than delete immediately unless deletion is explicitly acceptable.

An S3 lifecycle policy that keeps all objects in S3 Standard and only applies compression at read time

Why wrong: Staying in S3 Standard does not address the cost driver (storage class pricing based on access frequency). “Compression at read time” is not an S3 lifecycle storage class optimization mechanism and would not directly lower S3 storage class charges as requested.

A policy that changes bucket encryption from SSE-S3 to SSE-KMS to reduce storage cost

Why wrong: Switching from SSE-S3 to SSE-KMS will not lower S3 storage costs; in fact, it typically increases them because AWS KMS incurs per-request charges for encrypt and decrypt operations and a monthly key fee. S3 storage class pricing is determined by the amount of data stored and the access/retrieval rates, not by the encryption mechanism. Since the logs are infrequently accessed, the correct approach is to transition objects into a cheaper storage class via lifecycle rules, not to change encryption to a costlier KMS option.

Disable CloudFront caching so every request goes back to S3 for the latest image

Why wrong: Setting TTLs to zero or otherwise disabling CloudFront caching forces every request to be treated as a cache miss and triggers a fetch to the S3 origin that hosts the static images. This re-introduces full origin load, multiplies S3 GET request costs, and removes the edge-side response that CloudFront could have reused, which also increases user-perceived latency especially for remote clients. It directly contradicts the goal of using a CDN, because the image objects are immutable static files that should be cached for high hit ratios.

Route users directly to the S3 website endpoint to bypass CloudFront

Why wrong: Bypassing CloudFront by sending users directly to the S3 website endpoint eliminates edge caching. All image requests then traverse to the bucket's origin region, causing higher latency for global users, and S3's standard request/transfer pricing applies for every object served. Unlike CloudFront, the S3 website endpoint is typically HTTP-only (unless you use the REST endpoint with custom SSL), and it lacks the ability to enforce cache-control headers at the CDN level, so it would not reduce the volume of data pulled from the origin.

Turn on a NAT Gateway for the CloudFront origin to reduce bandwidth charges

Why wrong: A NAT Gateway is unrelated to CloudFront or S3 origin access; it provides outbound internet connectivity for resources in private subnets of a VPC. CloudFront reaches S3 through AWS's internal network, and NAT Gateway does not sit in that data path, so it cannot influence cache hit ratio or origin fetch frequency. Moreover, NAT Gateway charges an hourly fee plus per-GB processing cost, so adding one would simply increase the bill without any benefit to image delivery.

Stateful e-commerce platform with consistent load: On-Demand EC2 instances

Why wrong: On-Demand EC2 is not cost-optimal for a consistent load. Reserved Instances or Savings Plans offer significant discounts for predictable, steady-state workloads.

Add an internet gateway and move the instances into public subnets.

Why wrong: This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.

Replace the NAT Gateway with a Site-to-Site VPN connection.

Why wrong: A Site-to-Site VPN connects your VPC to an on-premises network over encrypted tunnels; it does not provide outbound internet access for resources inside the VPC. Replacing a NAT Gateway with a VPN would not allow the private instances to reach Amazon S3 or DynamoDB over the public internet, because those services are accessed via AWS public endpoints. Moreover, the VPN itself incurs hourly charges and data transfer costs, so it would not reduce the cost of the existing S3 and DynamoDB traffic. The appropriate fix is to use a gateway VPC endpoint, which keeps all traffic within the AWS network and eliminates NAT data processing fees.

Create an interface endpoint for S3 instead of a gateway endpoint.

Why wrong: An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.

Transit Gateway: Point-to-point connectivity between two VPCs

Why wrong: AWS Transit Gateway is a hub-and-spoke router that connects hundreds of VPCs and on-premises networks through a central gateway, enabling transitive routing across all attachments. For only two VPCs, this is over-engineered and more expensive because you pay hourly for the gateway and data processing charges per GB, whereas VPC peering provides free, direct, point-to-point bandwidth at lower cost. Thus, Transit Gateway is not the most suitable match for simple two-VPC connectivity.

Global Accelerator: Low-latency content delivery to edge locations

Why wrong: AWS Global Accelerator uses Anycast to provide static public IP addresses at AWS edge locations, routing TCP/UDP traffic over the AWS backbone to optimal application endpoints in one or more regions to improve latency and jitter. It does not cache or store content, and all traffic is forwarded to the origin server, so it does not deliver content from the edge. CloudFront, in contrast, caches content at edge locations and is purpose-built for low-latency content delivery, making Global Accelerator an incorrect match for this scenario.

EC2 On-Demand Instances to avoid interruptions

Why wrong: On-Demand Instances provide full compute capacity with no interruption, but you pay the full list price per hour. Because the workload already tolerates interruptions via checkpointing, you are essentially paying a premium for a guarantee you don't need. Spot Instances can deliver the same compute at up to a 70-90% discount, so On-Demand is the least cost-optimized choice for a batch job that can restart from the last checkpoint.

Savings Plans to guarantee capacity for the entire year

Why wrong: Savings Plans provide discounted pricing based on usage commitment, but they do not guarantee Spot-like interruption behavior and they do not specifically address the interruption-tolerant execution model. Since your main lever for maximum savings here is accepting interruption for lower Spot pricing, Savings Plans are not the best fit.

Reserved Instances with no interruption handling

Why wrong: Reserved Instances reduce cost compared to On-Demand, but they still assume more stable capacity usage. They are not the best choice when interruptions are acceptable and you can directly use Spot’s lower interrupted pricing with checkpoint recovery.

Create a gateway VPC endpoint for Amazon S3 instead.

Why wrong: An S3 gateway endpoint is useful when workloads need private access to S3, but this startup path is for Secrets Manager and Parameter Store. Adding S3 endpoints would not remove the NAT charges described in the scenario.

Add an Internet Gateway and send the traffic through public subnets.

Why wrong: Adding an internet gateway and placing the service in public subnets would expose the workload to the internet, contradicting the stated private-subnet requirement and risking public inbound access to the container. It also does not eliminate the NAT charges: the NAT Gateway would still handle outbound traffic from any remaining private resources, and forcing traffic through public subnets would require public IPs and a default route to the IGW, likely increasing data transfer costs if outbound internet traffic is heavy. The correct cost-reduction path is to keep the workload private and use VPC endpoints for the AWS APIs it actually calls.

Replace the NAT Gateway with a NAT instance.

Why wrong: A NAT instance can sometimes reduce cost, but it still requires an egress path and adds patching, scaling, and availability management. It does not eliminate the AWS API traffic cost the way the right VPC endpoints do.

Transition the objects to S3 Standard-IA after 30 days.

Why wrong: Standard-IA is a valid infrequent-access class, but it is typically more expensive than Glacier Instant Retrieval for data that is rarely read. Since the question explicitly asks for the most cost-optimized choice while preserving immediate retrieval, this is not the best answer.

Keep the logs in S3 Standard indefinitely and delete them manually when needed.

Why wrong: Keeping logs in S3 Standard for the full year means paying the highest per-GB storage rate for data that is accessed rarely or never, wasting money compared to moving it to Glacier Instant Retrieval after 30 days. Manual deletion is an operational liability because a missed or delayed action could leave data beyond the retention period, violating compliance, or remove it too early. An S3 Lifecycle expiration rule would achieve the same result automatically with no human intervention.

Replicate the logs to another Region for cheaper archival storage.

Why wrong: Cross-Region replication would duplicate the logs into a second S3 bucket, doubling the storage footprint and incurring inter-Region data transfer fees for every replicated object. The destination region's storage rates are often similar or only marginally lower, so the replication costs would swamp any hypothetical savings. Replication is designed for disaster recovery or latency reduction, not for lowering archival storage costs, and it does not replace the need for a lifecycle policy to enforce retention.

Attach Elastic IP addresses to instances in private subnets

Why wrong: Elastic IP addresses are static public IPv4 addresses that require an instance to reside in a public subnet with a route to an Internet Gateway to be useful for egress; they do not create any private path from a private subnet to AWS service APIs. Even if you attach an EIP to an instance in a private subnet, outbound traffic would still need a NAT Gateway or similar egress device, so it cannot satisfy the cost-avoidance goal. EIPs also incur additional charges for idle addresses and fail to provide the PrivateLink-like connectivity that VPC endpoints offer.

Install a NAT Gateway in every subnet to minimize routing hops

Why wrong: Installing a NAT Gateway in every subnet does not remove the need for an Internet Gateway (IGW) nor does it bypass pay-per-hour and per-GB data processing charges; in fact, it compounds those costs across multiple gateways. NAT routing still forces traffic through the public border (IGW) before reaching AWS services, adding latency and complexity, which is the opposite of the low-hop private path provided by a VPC endpoint. The premise of 'minimizing routing hops' is also incorrect: a gateway endpoint for S3 or an interface endpoint for other services routes directly from your VPC to the service, without any NAT device.

Open outbound internet access with a security group rule to reach service endpoints directly

Why wrong: Reaching AWS service endpoints via the internet typically reintroduces outbound connectivity (and associated data-transfer costs and security considerations). It also does not provide the NAT-avoidance behavior of VPC endpoints for private access to AWS services.

Keep all objects in S3 Standard because lifecycle transitions add too much management.

Why wrong: Keeping all objects in S3 Standard is the most expensive common general-purpose class; Standard is optimized for frequently accessed data, not for files that age into low or zero usage. Lifecycle rules are a one-time configuration that runs automatically, so they do not introduce ongoing management overhead. By declining to use lifecycle transitions, the workload would overpay for every binary that stays in the bucket long after users stop downloading it, directly undermining the cost objective in the question.

Copy all binaries to Amazon EFS so retrieval is faster.

Why wrong: Amazon EFS is a POSIX file system designed for shared access from EC2 instances; its per-GB cost is typically much higher than S3 for the same volume, and you also pay for throughput classes or burst credits. Copying user-uploaded binaries to EFS would not make retrieval faster for typical web or mobile clients because S3 can serve objects directly over HTTPS with high durability and scaling. The correct approach is to keep the binaries in S3 and use storage-class and lifecycle automation to reduce cost as access frequency declines.

Disable versioning because S3 Intelligent-Tiering needs it to work.

Why wrong: Intelligent-Tiering does not require versioning; the two features are completely independent. Versioning preserves multiple versions of an object to protect against accidental deletion or overwrite, and each version can still be assigned its own storage class. Disabling versioning would remove that data-protection capability without affecting Intelligent-Tiering's access-frequency monitoring, and it would not save money on storage tiers, so it is a wrong move for this cost-optimization problem.

Replace the API fleet with Dedicated Hosts to lock in lower rates.

Why wrong: Dedicated Hosts are physical EC2 servers dedicated to a single customer, billed per host rather than per instance, and are designed for scenarios with existing server-bound licenses (e.g., Microsoft or Oracle) or strict compliance requirements. They do not inherently provide lower rates than On-Demand or Savings Plans; in fact, Dedicated Hosts typically cost more than shared tenancy because you pay for the entire host even when not all of its vCPUs are used. The API fleet is a standard 24/7 web workload with no licensing or compliance constraint that would justify dedicated hardware. Thus, replacing the fleet with Dedicated Hosts would increase cost, not lower it.

Buy Standard Reserved Instances for the batch workers and keep them running 24/7.

Why wrong: Standard Reserved Instances require a 1- or 3-year commitment and bill you for the full instance hour each month, even if the instance is stopped or has no work. The transcoding workers are batch jobs that run only when new media arrives, meaning they are often idle or stopped for significant periods. Committing to a Standard RI for these workers would force the company to pay for capacity that goes unused most of the time, making it more expensive than On-Demand or Spot Instances. Additionally, Standard RIs lock you into a specific instance family, reducing flexibility to change instance types as encoding requirements evolve, unlike a Compute Savings Plan or Spot.

Increase the worker Auto Scaling minimum to prevent Spot interruptions.

Why wrong: Increasing the Auto Scaling minimum for the worker fleet does not prevent Spot interruptions; Spot capacity can still be reclaimed at any time regardless of the desired capacity. Raising the minimum forces more instances to run continuously, including during periods of low or no demand, which increases baseline cost and erodes the savings that Spot Instances provide. It also makes the system less responsive to actual workload, because the scaling policy is driven by a fixed minimum rather than queue depth or utilization. Therefore, the correct fix is to embrace Spot's interruptible nature with checkpointing, not to boost minimum capacity.

Keep both workloads on large provisioned RDS instances and add read replicas for the cart store.

Why wrong: Provisioned RDS instances incur charges regardless of utilisation, so keeping large instances idle during unpredictable traffic directly contradicts the requirement to avoid paying for unused capacity. The cart store’s key-value workload would also suffer unnecessary relational overhead and licensing costs. This option is tempting because read replicas can offload read traffic from a primary database, which would be correct if the cart store required strong consistency and the workload were predictable enough to justify fixed provisioning.

Use DynamoDB provisioned capacity with a fixed minimum despite the unpredictable traffic.

Why wrong: DynamoDB provisioned capacity bills a fixed number of read/write capacity units regardless of actual usage, so a fixed minimum would leave you paying for idle capacity during the unpredictable drops the company is trying to avoid. Even with auto-scaling, the minimum provisioned floor still incurs continuous charges, whereas on-demand capacity has no minimum and is designed exactly for fluctuating, hard-to-forecast traffic.

Replace the relational order system with a wide-column table to reduce SQL licensing.

Why wrong: Replacing the relational order system with a wide-column store would sacrifice relational constraints, joins, and ACID transactions that are critical for order accuracy and inventory integrity. The cost savings from avoiding SQL licensing are minimal because Amazon RDS and Aurora have no per-processor license fees, and the migration would require rewriting application code and implementing custom consistency guarantees, multiplying risk and engineering cost.

Migrate to DynamoDB immediately because every relational workload is more expensive.

Why wrong: Migrating to DynamoDB immediately is wrong because DynamoDB is a NoSQL key-value and document store, so SQL joins, aggregations, and flexible reporting queries are not natively supported. A reporting-heavy relational app would require a full application rewrite to model denormalized access patterns, and DynamoDB costs scale with provisioned capacity and storage which often exceed RDS for complex relational workloads. Furthermore, 'every relational workload is more expensive' is a false generalization; DynamoDB may be cheaper for some access patterns but is not a drop-in replacement.

Increase provisioned IOPS permanently so the monthly bill drops.

Why wrong: Permanently increasing provisioned IOPS would raise, not lower, the monthly bill because every IOPS beyond the instance's baseline is billed hourly, even when unused. The real problem is overprovisioned compute and read traffic hitting a single writer, not a lack of disk throughput; IOPS provisioning won't reduce the writer's idle capacity or offload dashboards. This option treats a symptom of an oversized instance while adding an additional recurring storage charge.