Cost and Performance Optimization practice questions

Use S3 Standard for all objects, and manually move older objects to S3 Standard-IA after 30 days.

Why it fails: This approach lacks automation and scalability. Manually moving objects after 30 days requires custom scripts or operational effort, which is error-prone and may result in objects being left in the more expensive S3 Standard class indefinitely. Although S3 Standard gives you consistent performance, it is costlier than S3 Standard-IA for data that will soon become infrequently accessed, and manual governance does not adapt to changing access patterns or provide lifecycle enforcement.

Use S3 Standard-IA for all objects, and accept higher retrieval costs for the first 30 days.

Why it fails: S3 Standard-IA is designed for data that is accessed infrequently but needs rapid retrieval, and it charges a per-GB retrieval fee whenever objects are read. Putting all objects in this class means frequently accessed data during the first 30 days will incur repeated retrieval charges, quickly eroding the storage cost savings. Additionally, Standard-IA has a 30-day minimum storage duration, so objects that are accessed heavily and then deleted or transitioned early still cost the same as a full month, making this a poor fit for workloads with ongoing early access.

Use S3 Glacier Instant Retrieval

Why it fails: Glacier Instant Retrieval is for long-lived, rarely accessed data that needs immediate retrieval. It has a minimum storage duration charge and is not optimal for data that is frequently accessed for the first 30 days.

EC2 Instance Savings Plans

Why it fails: EC2 Instance Savings Plans apply only to EC2 instances, not RDS or Lambda, so they do not cover the full workload mix.

Compute Savings Plans

Why it fails: Compute Savings Plans cover EC2, Lambda, and Fargate, but they do not cover Amazon RDS databases, which are part of the workload.

Spot Instances

Why it fails: Spot Instances are interruptible and not suitable for steady-state, predictable workloads.

Transition to S3 Standard-Infrequent Access after 30 days, then to S3 Glacier Deep Archive after 6 months.

Why it fails: Transitioning from S3 Standard to Standard-IA after 30 days is cost-effective for the weekly access pattern, since Standard-IA has a lower storage price while still providing millisecond access. Moving to S3 Glacier Deep Archive after 6 months minimizes storage costs for rarely accessed video files, and while retrieval can take minutes, the low access frequency makes this acceptable. This combination balances the archive's minimal storage cost with adequate retrieval flexibility.

Transition to S3 One Zone-Infrequent Access after 30 days, then to S3 Glacier after 6 months.

Why it fails: One Zone-IA offers lower durability because it stores data in a single Availability Zone, making it unsuitable for long-term video retention where resilience is needed. Glacier Flexible Retrieval requires minutes to hours for standard retrievals and has a higher per-GB retrieval cost compared to Glacier Deep Archive. Given video files are accessed weekly initially and then rarely, the lack of multi-AZ resilience and slower, more expensive retrieval make this a poor lifecycle choice.

Transition to S3 Intelligent-Tiering after 30 days, then to S3 Glacier Flexible Retrieval after 6 months.

Why it fails: Intelligent-Tiering adds a monitoring and automation fee for every object, which is inefficient when the access pattern is already known and can be set with lifecycle rules. Moving to Glacier Flexible Retrieval after 6 months is not the lowest-cost choice; Glacier Deep Archive offers far cheaper storage for data accessed less than once a year. Using Intelligent-Tiering here would incur unnecessary charges without providing meaningful benefit over a predictable life-cycle transition to Deep Archive.

On-Demand Instance with a general-purpose (T-family) instance

Why it fails: T-family instances are burstable, meaning they accumulate CPU credits for short bursts, but a daily CPU-intensive batch job will rapidly exhaust those credits and throttle CPU performance to the baseline once credits are spent. On-Demand pricing also carries no discount, so you pay full list price for a workload that runs only a few hours, making it both unsafe for sustained high CPU and unnecessarily expensive compared to Spot.

Spot Instance with a compute-optimized (C-family) instance

Why it fails: Spot Instances offer up to a 70-90% discount over On-Demand and are ideal for fault-tolerant, stateless batch workloads because you can design the job to be interrupted and resumed on a new instance. The C-family's high per-vCPU performance directly suits CPU-intensive processing, and using Spot with a diversified allocation strategy across multiple instance types and Availability Zones reduces the risk of capacity shortages. Even if a Spot Instance is reclaimed with the two-minute interruption notice, the batch job can checkpoint or re-queue and continue, maintaining reliability at a fraction of the cost.

On-Demand Instance with a memory-optimized (R-family) instance

Why it fails: R-family instances are memory-optimized with a high memory-to-vCPU ratio, designed for workloads such as in-memory databases or large caches, not for CPU-bound batch processing. Choosing an R-family On-Demand instance forces you to pay for large amounts of unused memory, inflating cost without performance benefit for a compute-intensive job. On-Demand pricing also lacks the deep discounts of Spot, so this combination is the most cost-inefficient choice while still not delivering the right compute balance.

Spot Instances

Why it fails: Spot Instances offer deep discounts on spare EC2 capacity, but AWS can reclaim this capacity with only a two-minute warning when it needs the resources elsewhere, causing the instance to be terminated. The nightly batch process is time-sensitive and not fault-tolerant, so an interruption mid-job would either delay processing past its deadline or lose partial work already completed. Spot pricing also fluctuates with real-time supply and demand, meaning the cost benefit is not stable enough for a production workload that must run every night.

On-Demand Instances

Why it fails: On-Demand Instances provide maximum flexibility with no upfront commitment, but this convenience comes at the highest per-hour cost for equivalent compute capacity. Since the batch job runs consistently every night with a predictable duration, paying On-Demand rates for each run results in a substantially higher annual expense compared to Reserved Instances. Additionally, On-Demand does not reserve capacity, so under rare regional resource pressure, insufficient instance capacity could prevent the job from starting, jeopardizing the required completion deadline.

Dedicated Hosts

Why it fails: Dedicated Hosts supply a physical server exclusively for your use, primarily to meet per-socket, per-core, or per-VM software licensing requirements (such as Windows Server or SQL Server) and to satisfy corporate compliance constraints. Unlike Reserved Instances, you pay for the entire host per hour regardless of how many instances you place on it, making this option considerably more expensive for a simple batch-processing job that would typically run on a few general-purpose instances. This workload does not require the Bring-Your-Own-License benefits, server affinity, or compliance features that Dedicated Hosts uniquely offer, so the added cost is unnecessary.

Replace the EBS volumes with instance store volumes.

Why it fails: Instance store volumes provide temporary block-level storage for an EC2 instance; data is lost if the instance stops or terminates. They are not suitable for persistent data and cannot be used as a replacement for EBS volumes in most applications.

Change the volume type to io2 (Provisioned IOPS SSD) and reduce the provisioned IOPS.

Why it fails: io2 volumes are engineered for mission-critical workloads that demand consistent, single-digit-millisecond latency and high durability, not for cost reduction. They incur a higher per-GB storage charge than gp3 and also bill separately for every provisioned IOPS, so lowering the IOPS setting alone will not offset the inflated storage cost. Because the web application's throughput is already satisfied by gp2's baseline, migrating to io2 adds expense without delivering a meaningful performance benefit.

Change the volume type to Cold HDD (sc1) to reduce cost.

Why it fails: Cold HDD (sc1) volumes are optimized for large, sequential, infrequently accessed datasets and deliver only hundreds of IOPS, far below what a latency-sensitive web application requires. They cannot be used as boot volumes, so if these are the root volumes the migration would be invalid, and even as data volumes their high latency would cause serious timeouts under load. The volume's throughput model also charges per TB per month, but the baseline performance is inadequate for an interactive application, making any apparent cost saving a performance trade-off.

Manually move the objects to S3 One Zone-IA.

Why it fails: Manually moving objects to S3 One Zone-IA is not the optimal choice because One Zone-IA, while cheaper than Standard, still costs significantly more than Glacier Deep Archive for long-lived, rarely accessed data. Moreover, a manual process is error-prone and does not scale, whereas a lifecycle rule would automatically transition aged objects without ongoing operational overhead.

Use S3 Intelligent-Tiering.

Why it fails: S3 Intelligent-Tiering is wrong for this scenario because it is designed for data with unknown or changing access patterns and charges a monthly monitoring/automation fee per object. Although it can eventually move objects to deep archive tiers, those transitions happen after much longer periods (e.g., 180 days), not at the 90-day threshold, and the monitoring fees can make it more expensive than a simple lifecycle rule for predictable archival data.

Enable S3 Versioning and create a lifecycle rule to delete old versions.

Why it fails: Enabling S3 Versioning and creating a lifecycle rule to delete old versions does not address the cost of the current objects. Versioning actually increases storage consumption by retaining multiple versions, and while deleting old versions helps, the existing current versions remain in their original storage class, so you still need a separate lifecycle transition to archive them to a cheaper class like Glacier Deep Archive.

AWS WAF: A managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS

Why it fails: It describes AWS Shield, not AWS WAF. AWS WAF operates at the application layer (Layer 7) and filters individual HTTP(S) requests for signatures of attacks like SQL injection, cross-site scripting, or oversized requests. AWS Shield, on the other hand, is specifically designed to detect and mitigate Distributed Denial of Service attacks that try to flood infrastructure at the network/transport layers (L3/L4), although Shield Advanced also includes some application-layer protection. So the DDoS protection role belongs to Shield.

AWS IAM: A managed service that makes it easy to create and control the encryption keys used to encrypt your data

Why it fails: Managing encryption keys and creating cryptographic key material is the function of AWS KMS, not AWS IAM. IAM's role is to manage identities — such as users, groups, and roles — and define the permissions they grant, through IAM policies. While IAM policies can allow or deny an entity's ability to use a particular KMS key, IAM itself never creates, stores, or rotates any encryption keys; those operations remain wholly within KMS.

Standard for 30 days, then transition to One Zone-IA for 90 days, then to Glacier Deep Archive.

Why it fails: One Zone-IA is not durable for compliance data.

Standard for 120 days, then transition to Glacier Deep Archive.

Why it fails: Misses cost savings from Standard-IA for infrequent access period.

Standard for 30 days, then transition to Glacier for the remaining life.

Why it fails: Glacier is more expensive than Glacier Deep Archive for rarely accessed data.

Associate Elastic IP addresses with the instances.

Why it fails: Associating Elastic IP (EIP) addresses with instances provides static public IPv4 addresses that remain consistent across instance stops and restarts, but this is purely a networking feature and does not alter compute pricing. In fact, EIPs can generate additional charges: you incur hourly costs for any EIP that is not associated with a running instance, and public IPv4 addresses now carry an hourly fee even when in use. Therefore, adding EIPs would only increase your AWS bill, not reduce EC2 environment costs.

Use Dedicated Hosts.

Why it fails: Dedicated Hosts are physical servers dedicated to your use, and they are billed per host per hour (or with reserved term commitments), not per vCPU or instance. They are typically chosen to meet compliance requirements or support server-bound software licenses like Windows Server or Oracle, but they eliminate the shared infrastructure model that makes Spot and On-Demand cost-efficient. For interruptible batch jobs, paying an entire host premium provides no benefit and dramatically increases costs rather than reducing them.

Use On-Demand Instances.

Why it fails: On-Demand Instances charge the full pay-as-you-go rate without any upfront commitment or volume discounts. While they offer high reliability and no interruption, they are the least cost-efficient option for workloads that can tolerate transient failures, such as batch processing. Because Spot Instances can handle these same jobs for a fraction of the price, choosing On-Demand purely for batch jobs wastes money, especially when the job is not time-sensitive and can be paused or restarted.

Spot Instances

Why it fails: Spot Instances offer large discounts but can be interrupted at any time, which would impact performance for a production web application behind a load balancer.

On-Demand Instances

Why it fails: On-Demand Instances are fully flexible and support variable traffic, but they are the most expensive option and do not optimize costs as well as Savings Plans for long-term usage.

Reserved Instances

Why it fails: Reserved Instances require a 1- or 3-year commitment to a specific instance family in a region, which is less flexible for variable traffic patterns compared to Savings Plans.

S3 One Zone-Infrequent Access (S3 One Zone-IA)

Why it fails: S3 One Zone-Infrequent Access (S3 One Zone-IA) is incorrect for this archival use case because it stores data in a single Availability Zone, providing only 99.99% durability, which is far below the 99.999999999% durability offered by S3 Glacier Deep Archive. Additionally, its per-gigabyte cost is notably higher than Glacier Deep Archive, and while it is designed for infrequently accessed data, it sacrifices the multi-AZ redundancy necessary for long-term archival without risk of data loss if that single AZ fails.

S3 Intelligent-Tiering

Why it fails: S3 Intelligent-Tiering is not the lowest-cost solution because it charges a monthly monitoring and automation fee per object to track access patterns and move data between tiers. For static data that is rarely accessed, these ongoing operational charges quickly exceed the flat, low per-gigabyte cost of S3 Glacier Deep Archive. Furthermore, Intelligent-Tiering is designed for actively changing access patterns, not purely archival data, so it fails to meet the requirement for minimal cost with no need for frequent retrieval.

S3 Standard-Infrequent Access (S3 Standard-IA)

Why it fails: S3 Standard-Infrequent Access (S3 Standard-IA) is cheaper than S3 Standard but still more expensive than S3 Glacier Deep Archive on a per-gigabyte basis, so it does not satisfy the requirement for the lowest cost. It offers millisecond retrieval and 99.99% availability, which are unnecessary for static data that is rarely accessed, and its infrastructure is optimized for quick access rather than ultra-low-cost storage. Consequently, while Standard-IA might suit infrequent but time-sensitive retrieval, it lacks the cost efficiency of Deep Archive for purely archival workloads.

Dedicated Hosts

Why it fails: Dedicated Hosts provide a physical server fully dedicated to your account, enabling you to use existing server-bound software licenses and satisfy compliance or licensing requirements that are not met by other EC2 tenancy models. However, you are billed for the entire host per hour, regardless of how many instances you run, making this option extremely expensive for a batch workload that executes only intermittently. Since batch processing is typically stateless, fault-tolerant, and does not require a specific physical server, the high cost of Dedicated Hosts cannot be justified.

Reserved Instances (Standard)

Why it fails: Standard Reserved Instances require a 1-year or 3-year commitment in exchange for a discounted hourly rate, but they are only cost-effective when you have steady-state, predictable usage that operates 24/7 month after month. For an intermittent batch workload, committing to fixed capacity would mean paying for a reserved instance even when no job is running, leaving expensive capacity idle and erasing the savings commitment was supposed to provide. Additionally, Standard RIs are inflexible because you cannot easily modify them to a different instance family, making this option ill-suited for a dynamic, cost-effective batch architecture.

Capacity Reservations

Why it fails: On-Demand Capacity Reservations guarantee access to compute capacity in a specific Availability Zone for any duration, but you incur charges for every instance that you reserve for the entire time the reservation is active, regardless of whether the instances are actually running. This means that for a batch job that only executes a few hours a day, you would pay for the reserved capacity during all the idle hours, which directly undermines the goal of cost-effectiveness. While capacity reservations can be valuable for critical, unpredictable workloads, batch processing is generally not so latency-sensitive that it justifies paying a premium for guaranteed capacity that remains mostly unused.

Increase the EC2 instance sizes to handle peak load at all times.

Why it fails: Right-sizing to larger EC2 instance types permanently means paying for vCPUs, memory, and network capacity that remains idle for most of the day. This classic over-provisioning directly inflates hourly costs without improving performance during off-peak periods, and it still leaves a single instance as a potential bottleneck during extreme spikes. The real issue is that you are paying for peak capacity continuously, rather than matching compute resources to actual demand over time.

Purchase Reserved Instances for all instances to get the lowest hourly rate.

Why it fails: Reserved Instances are a contractual commitment to a specific instance family, region, and term (typically 1 or 3 years), which is fundamentally incompatible with a variable workload whose burst capacity needs fluctuate. If traffic drops or the architecture changes, you are still paying for capacity you no longer use, and RI discounts do nothing to help you scale beyond the committed baseline. This approach sacrifices flexibility for a predictable hourly rate, which is the opposite of what an elastic, cost-sensitive architecture requires.

Use Dedicated Hosts to ensure consistent performance.

Why it fails: Dedicated Hosts provide instance placement on a physical server dedicated to your use, but that isolation addresses licensing, compliance, or regulatory requirements—not raw performance. AWS Xen/Nitro virtualization already delivers consistent compute performance for standard instance types, so the perceived 'noisy neighbor' problem is rarely a real bottleneck in modern EC2. Since Dedicated Hosts also incur high upfront and hourly costs, using them solely to improve performance is an expensive solution that ignores the actual scaling design needed for variable traffic.

Upgrade the instance to db.r5.xlarge and enable automatic backups.

Why it fails: Upgrading to db.r5.xlarge only increases compute and memory capacity for the single primary instance, which remains vulnerable if the Availability Zone fails. Enabling automatic backups merely supports point-in-time recovery to a specific timestamp; it does not create a standby or a separate routable endpoint for reads. This approach addresses capacity but not high availability or read workload distribution, making it an incomplete production fix.

Enable Multi-AZ on the existing instance to provide automatic failover but no read scaling.

Why it fails: Enabling Multi-AZ on the existing instance creates a standby that is not accessible for any read or write traffic; only the primary endpoint answers requests. The standby exists solely for automatic failover, so while it improves availability, it does nothing to distribute or scale read queries away from the primary. For a system with heavy read traffic, this leaves the primary under the same load and only adds a replicating standby, not a read-only workload target.

Use Amazon ElastiCache for Redis to cache frequent queries.

Why it fails: ElastiCache for Redis is an in-memory data store that can serve cached query results, drastically reducing repeated hits to PostgreSQL, but it is not a database scaling construct for RDS itself. It requires application-level logic to populate and invalidate cache entries, and it does not provide durable storage, automatic failover for the primary database, or physical replicas of table data. While it might be a useful supplement, it does not replace the need for Multi-AZ or read replicas, and it cannot be used as a direct endpoint for SQL read traffic.

Store all data in S3 Standard for the first year, then delete.

Why it fails: Storing all data in S3 Standard for a full year before deleting it violates the requirement to retain backups and logs for the entire retention period; deletion after one year makes the data unrecoverable if retention is longer. Additionally, S3 Standard is the most expensive storage class, with no lifecyle optimization, so you would pay premium prices for data that is rarely accessed. This approach ignores the cost-saving opportunities of tiering to lower-cost storage classes and risks compliance failures if the retention policy mandates data availability for several years.

Use S3 Glacier Flexible Retrieval to allow data retrieval in minutes.

Why it fails: S3 Glacier Flexible Retrieval (formerly Glacier) offers retrieval times of minutes to hours, but its storage price is higher than Glacier Deep Archive and the requirement here is only to keep backups and logs—there is no stated need for rapid access. Choosing Flexible Retrieval would incur unnecessary costs for the same retention duration, because Deep Archive is purpose-built for long-term archival where retrieval is rare and minutes-to-hours latency is acceptable. The phrase 'allow data retrieval in minutes' is a red herring: if the business does not actually need fast retrieval, you should prioritize the lowest-cost archival tier.

The policy is too restrictive because it only allows t3.micro instances, which may not be sufficient for production workloads.

Why it fails: While it is true that t3.micro is a small burstable instance, the premise that this is a problem is off-target for a cost-optimization question. The policy intentionally restricts the instance type to control per-unit cost, and the real issue is that it places no ceiling on the total number of instances, so a production workload could circumvent the cost control by launching many t3.micro instances in parallel rather than one larger instance.

The policy does not allow launching any instances because the condition is on RunInstances.

Why it fails: This is incorrect because the condition key 'ec2:InstanceType' is used inside a condition that applies specifically to the ec2:RunInstances action. The condition explicitly allows instances with a type of t3.micro, so the RunInstances action is permitted for that instance type. The condition does not deny the action; it only narrows the allowed value, so launching a t3.micro instance is fully authorized.

The policy ensures cost control by allowing only t3.micro instances, which are the cheapest.

Why it fails: The policy does allow only t3.micro instances, but that does not automatically guarantee cost control. There is no limit on instance count, so a user could launch many t3.micro instances, and the total cost could exceed the cost of a single larger, more expensive instance. Moreover, t3.micro is not necessarily the cheapest instance type; smaller or older families like t2.nano or t4g.nano may be less expensive in some AWS regions, so the assumption that this policy selects the absolute cheapest option is unfounded.

Set a reserved concurrency limit to cap the number of concurrent executions.

Why it fails: Setting a reserved concurrency limit only caps how many Lambda functions can run at the same time; it does not reduce the total number of invocations triggered by S3 events. When the concurrency limit is reached, additional events are throttled, which can cause failed or dropped processing attempts rather than lowering compute costs. The cost is driven by total compute time across all invocations, so this measure does not address the actual expense.

Change the function to be invoked on a schedule instead of by S3 events.

Why it fails: Switching from S3 event-based invocation to a scheduled invocation fundamentally changes the trigger model. S3 events invoke the function immediately per object creation, while a schedule (cron) evaluates the bucket at set intervals, potentially missing objects created between runs and requiring extra logic to list and process unprocessed files. This approach may not process all objects and can introduce data staleness or loss, making it an incorrect way to reduce Lambda costs.

Reduce the function's memory allocation to lower cost per invocation.

Why it fails: Reducing memory allocation lowers the cost per unit of time, but it also reduces the CPU and I/O resources available to the function, which typically makes execution slower. Since total Lambda cost is memory size multiplied by execution duration, the increased runtime often offsets or exceeds the per-second savings, potentially raising total cost. In some cases, the function may even near or exceed the timeout limit, causing failures rather than cost reductions.

Migrate the database to Amazon Aurora with Auto Scaling enabled.

Why it fails: Migrating to Aurora does not inherently reduce read load unless you provision Aurora Replicas, and Aurora's minimum cost profile is typically higher than a single MySQL instance with RDS Read Replicas. Aurora Auto Scaling primarily adjusts storage volume automatically, not compute or reader capacity in the way needed here, so this option still requires additional reader nodes. The migration also introduces downtime and application compatibility risk, making it a more expensive and complex answer than simply adding RDS Read Replicas to the existing instance.

Change the storage type to gp3 and increase IOPS.

Why it fails: Changing to gp3 and raising IOPS only improves the storage layer's throughput and latency; it does nothing to reduce the number of queries hitting the primary DB instance. The bottleneck from heavy read traffic is typically CPU and connection handling on the instance, not raw EBS performance, so the primary would remain saturated. This is a performance-tuning measure, not a read-scaling architecture, and it would not lower cost while addressing the actual problem.

Upgrade the DB instance to a larger instance type with more vCPUs.

Why it fails: Scaling up to a larger instance type with more vCPUs addresses the read load by giving the single instance more compute headroom, but it incurs full price for that larger instance even when read spikes subside. This vertical scaling approach has a hard limit at the largest available instance size, and it does not create redundancy or separation of read and write workloads. RDS Read Replicas are a pay-as-you-use horizontal solution that offers better cost efficiency for a read-heavy pattern.

Stop the instance during off-hours using Instance Scheduler, but keep the RI as-is.

Why it fails: RI benefit applies to running instances; stopping the instance wastes the RI payment for those hours.

Sell the current RI on the Reserved Instance Marketplace and purchase a new Convertible RI for a smaller instance type.

Why it fails: Selling the RI may incur loss and does not optimize the current usage pattern.

Convert the RI to a Convertible RI and exchange it for a larger instance family to get more compute per hour.

Why it fails: Larger instance would increase cost, not decrease.