Design Cost-Optimized Architectures practice questions

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Create a gateway VPC endpoint for Amazon S3 instead.

Why it fails: 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 it fails: 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 it fails: 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.

Move the fleet to Spot Instances.

Why it fails: Spot Instances are reclaimed with a two-minute interruption notice when capacity is needed, and the stem explicitly forbids managing capacity interruptions. They are tempting because they offer the deepest discounts for fault-tolerant, stateless or checkpointed workloads that can absorb sudden termination.

Use Dedicated Hosts to reserve physical servers for the application.

Why it fails: Dedicated Hosts bill for the entire physical server and exist to satisfy licensing or compliance requirements, so they do not reduce cost for a standard 24/7 fleet. They are tempting because they are a reservation-style purchase, and would be correct when per-socket or per-core licences must be tied to hardware.

Stay entirely on On-Demand Instances because they are already the cheapest option.

Why it fails: On-Demand is the baseline the stem asks to beat, and it carries no discount for a one-year commitment, so staying on it leaves the predictable 24/7 spend unreduced. It is tempting as the zero-risk default, and would be right for short, unpredictable or interruptible workloads.

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

Why it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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.

Transition objects to S3 Glacier Flexible Retrieval after 14 days.

Why it fails: Incorrect. Glacier Flexible Retrieval is better for archives with less urgent restore needs, but the first year still requires retrieval within minutes. Standard-IA is a better fit for that requirement.

Disable versioning to make the lifecycle rules work correctly.

Why it fails: Incorrect. Versioning is not required to use S3 lifecycle transitions, and disabling it does not produce the requested access pattern or cost model. The savings come from storage-class changes, not versioning status.

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

Why it fails: 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 it fails: 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 it fails: 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 a fixed fleet of m6i.large instances in an Auto Scaling group with a higher minimum.

Why it fails: Incorrect. A higher minimum keeps capacity running even when the queue is empty, so idle cost remains high. It also does not provide the burst efficiency that queued, event-driven processing gives you.

Use Reserved Instances for the workers even though demand is highly bursty.

Why it fails: Incorrect. Reserved Instances work best for stable, predictable utilization. Bursty workers would leave committed capacity unused much of the time, which wastes money.

Process uploads only during a nightly window so the fleet looks busier.

Why it fails: Incorrect. Batch scheduling may reduce perceived complexity, but it increases latency and does not inherently reduce compute cost if the same amount of work must still be done.

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

Why it fails: 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 it fails: 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 it fails: 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.

Buy an EC2 Instance Savings Plan tied to one instance family for all workloads.

Why it fails: Incorrect. An EC2 Instance Savings Plan is more restrictive than a Compute Savings Plan and does not cover the Lambda portion of the estate. The vendor would lose flexibility without improving coverage.

Use Spot Instances for the control plane because it is the largest bill.

Why it fails: Incorrect. Control planes usually require steady availability and should not depend on interruptible capacity. Spot is a poor fit when service stability matters more than the last increment of savings.

Increase the ECS desired count so Lambda can be removed.

Why it fails: Incorrect. More ECS tasks mean more always-on compute cost, which directly conflicts with the cost-reduction goal. It also adds unnecessary operational burden instead of reducing it.

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

Why it fails: 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 it fails: 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.

Keep unattached volumes around for troubleshooting after instance termination.

Why it fails: Leaving volumes attached to nothing after instance termination means you continue paying for storage that no workload is using, directly inflating your EBS bill. While such volumes might occasionally be needed for troubleshooting, keeping them indefinitely without a policy is a major cost leakage. The proper approach is to either delete unattached volumes immediately or protect them with a snapshot and a DLM retention plan, then delete the volume after the snapshot is taken.

Raise provisioned IOPS on every volume so snapshot restore time feels faster.

Why it fails: Increasing provisioned IOPS on all volumes is a misunderstanding of how EBS snapshot restore works: the restore operation streams data from the snapshot to a new volume and is bounded by the snapshot's storage tier and the volume's size, not by the destination volume's later IOPS capability. Provisioned IOPS only affect steady-state performance, not the initial volume initialization or snapshot hydration speed, so this change would raise costs without making restores feel any faster. Furthermore, the core issue here is unnecessary storage retention, not restore latency, so spending extra on IOPS does not address the real problem.

Add a lifecycle rule to transition backups older than 1 day to S3 Glacier Instant Retrieval, and keep them until day 90.

Why it fails: Instant Retrieval can meet the RTO but usually costs more than Flexible Retrieval for infrequent backups.

Add a lifecycle rule to transition backups older than 1 day to S3 Glacier Deep Archive, and keep them until day 90 with no restore configuration.

Why it fails: Deep Archive restore times are typically longer and may conflict with a strict 24-hour RTO expectation.

Add a lifecycle rule to transition backups older than 1 day to S3 One Zone-IA, and delete them after 7 days.

Why it fails: One Zone-IA reduces cost but deletion after 7 days breaks the required 90-day retention.

Reserved Instances with a fixed instance type

Why it fails: Reserved Instances with a fixed instance type (e.g., a Standard RI for m5.large) deliver substantial discounts for a steady-state workload, but they lock you into that exact instance family, region, and OS for the entire 1- or 3-year term. If your team later wants to switch to a newer generation, a different instance family for better price/performance, or a different operating system, you cannot simply change the RI; you must modify or sell it on the Reserved Instance Marketplace, which adds operational overhead. In contrast, Compute Savings Plans offer similar or better discount levels while permitting automatic flexibility across instance families and sizes, making fixed RIs the less adaptable choice for a long-running service that might evolve.

Spot Instances

Why it fails: Spot Instances let you bid for spare EC2 capacity at significant discounts, sometimes up to 90% off the On-Demand price. However, AWS can reclaim Spot capacity with only a 2-minute warning when it is needed elsewhere, meaning your production web service could be interrupted without enough time for graceful shutdown. Running a continuously available 24/7 production service on Spot would require complex interruption handling—such as cross-instance checkpointing, queue-based state, or automated replacement—and even then it risks downtime and degraded reliability. For a stable always-on service where uptime is critical and architecture should stay simple, Spot is not an appropriate foundation.

On-Demand Instances

Why it fails: On-Demand Instances provide per-second billing with no upfront payment and no obligation, which makes them the most flexible option for variable or unpredictable workloads. However, for a continuous 24/7 production web service, you are essentially paying the list price for every single hour of usage, missing out on the significant savings (often 30-70%) that a commitment-based plan would provide. While On-Demand guarantees full availability and never interrupts your workload, it is financially inefficient for a stable, always-on service that can be forecasted and committed to.

S3 Standard

Why it fails: S3 Standard is optimized for frequently accessed, low-latency workloads and charges a premium per gigabyte compared with archival storage classes. Compliance reports are rarely read, so paying for millisecond retrieval you won't use inflates operational costs without any compliance benefit, especially when the business requirement accepts retrieval measured in hours rather than milliseconds.

S3 Intelligent-Tiering

Why it fails: S3 Intelligent-Tiering automatically moves data between access tiers based on changing usage patterns, making it ideal for unpredictable workloads, but it is not designed with a specific retrieval-time guarantee for archived data. For compliance reports with a predictable, extremely low access frequency, relying on an automated tiering system introduces unnecessary complexity and potential tiering costs, whereas choosing Glacier Flexible Retrieval directly aligns with the hour-scale retrieval requirement and avoids that overhead.

S3 Glacier Deep Archive

Why it fails: S3 Glacier Deep Archive is the lowest-cost storage class, but its standard retrieval can take up to 12 hours and bulk retrieval up to 48 hours, which clearly conflicts with the stated requirement to restore compliance reports within a matter of hours. While cheaper on a per-gigabyte basis, the retrieval-time penalty makes it a poor fit when hour-scale access is mandatory, and Glacier Flexible Retrieval provides a better cost-versus-retrieval tradeoff.