Cost and Performance Optimization practice questions

Enable Multi-AZ deployment.

Why wrong: Incorrect. Multi-AZ provides high availability and failover, but does not reduce CPU utilization on the primary instance.

Scale up the instance size to a larger instance class.

Why wrong: Incorrect. Scaling up increases performance but also increases cost, and does not optimize cost.

Enable automated backups.

Why wrong: Incorrect. Automated backups enable point-in-time recovery but do not reduce CPU usage.

Spot Instances

Why wrong: Incorrect. Spot Instances can be terminated with little notice, making them unsuitable for a 24/7 steady workload.

On-Demand Instances

Why wrong: Incorrect. On-Demand is the most expensive option with no commitment discount.

Savings Plans (Compute)

Why wrong: Incorrect. While Compute Savings Plans offer flexibility and savings, for a steady-state workload Standard RIs often provide a higher discount.

Create an AWS Lambda function that tags instances at launch via CloudTrail events, and use AWS Budgets to enforce tagging.

Why wrong: Incorrect. AWS Budgets cannot enforce tagging; they only alert on cost. Lambda solution is more complex than Config auto-remediation.

Use AWS Cost Categories to automatically group costs based on resource tags.

Why wrong: Incorrect. Cost Categories do not tag resources; they organize costs after tagging exists.

Ensure all AMIs used have tags that propagate to instances, and enable cost allocation tags.

Why wrong: Incorrect. AMI tags do not propagate to launched instances; each instance must be tagged individually.

On-Demand Instances

Why wrong: On-Demand Instances offer full flexibility but are more expensive than Spot Instances for workloads that can tolerate interruptions.

Reserved Instances

Why wrong: Reserved Instances provide a discount for a 1- or 3-year commitment, which is not cost-effective for a workload that runs only 2 hours per night. The upfront commitment does not align with the usage pattern.

Dedicated Hosts

Why wrong: Dedicated Hosts provide physical servers dedicated to your use, typically for licensing or compliance requirements. They are the most expensive option and are not suitable for this cost-sensitive, short-duration workload.

Enable Multi-AZ for the RDS instance and scale up the instance size

Why wrong: Multi-AZ provides high availability, not read scaling. The standby is not used for reads. Scaling up increases cost without addressing the root cause (read-heavy workload) and may provide limited improvement.

Enable Amazon RDS Performance Insights and increase the storage allocation

Why wrong: Performance Insights helps identify performance bottlenecks but does not directly reduce CPU load. Increasing storage may improve I/O performance if bottlenecks are I/O-related, but it does not address high CPU from read queries and increases cost.

Implement Amazon ElastiCache for Memcached in front of the database and migrate read-heavy queries to cache

Why wrong: ElastiCache can improve performance by caching frequent reads, but it adds additional cost and operational overhead. For a workload where 90% of queries are reads, read replicas are a simpler and often more cost-effective solution, especially if the data is not highly cacheable or frequently updated.

Target tracking scaling

Why wrong: Target tracking adjusts capacity based on a metric threshold (e.g., CPU), which is reactive and may not perfectly time the morning peak.

Simple scaling

Why wrong: Simple scaling adds or removes instances based on CloudWatch alarms, but it is reactive and may have cool-down periods that cause delays.

Manual scaling

Why wrong: Manual scaling requires the administrator to adjust the desired capacity by hand, which is not automated and prone to human error.

Transition objects to S3 Standard-IA after 30 days, and to S3 Glacier after 60 days. Delete after 7 years.

Why wrong: Transitioning to Glacier after 60 days is too aggressive because the data is still accessed occasionally until 90 days. Retrieval from Glacier incurs additional time and cost. Also, Glacier is not the cheapest for long-term archival; Glacier Deep Archive is cheaper.

Transition objects to S3 Glacier Deep Archive after 30 days, and delete after 7 years.

Why wrong: Moving data to Deep Archive after only 30 days is not cost-effective because the data is still frequently accessed in the first 30 days. Retrieval from Deep Archive takes hours and incurs significant costs, making it unsuitable for data that needs quick access.

Transition objects to S3 One Zone-IA after 30 days, and to S3 Glacier Deep Archive after 90 days. Delete after 7 years.

Why wrong: S3 One Zone-IA does not provide the same durability as Standard-IA. For compliance data that must be retained for 7 years, using One Zone-IA increases the risk of data loss if the single Availability Zone fails. Standard-IA is the safer and still cost-effective choice.

Convert the read replicas to Multi-AZ instances to improve the replication process and reduce lag.

Why wrong: Multi-AZ for read replicas provides standby replicas for failover, but it does not reduce replica lag. In fact, running Multi-AZ adds overhead because the primary in the replica's AZ must also replicate to the standby.

Add additional read replicas to distribute the read load and reduce the lag on each individual replica.

Why wrong: Adding more replicas does not reduce the lag on existing replicas; it may increase the load on the primary because it must stream the WAL to more replicas, potentially worsening the lag. The solution is to make each replica more powerful.

Upgrade the primary DB instance to a larger class with increased IOPS to reduce the amount of data that needs to be replicated.

Why wrong: While upgrading the primary could improve overall throughput, the replica lag is specifically caused by the replicas' inability to apply changes quickly. The replicas are the bottleneck. Upgrading the primary is less cost-effective and may not solve the lag issue.

Purchase EC2 Instance Savings Plans for the most commonly used instance family and region.

Why wrong: EC2 Instance Savings Plans are tied to a specific instance family in a region. They do not cover Fargate tasks and are less flexible if instance types change.

Purchase Standard Reserved Instances for the EC2 instances and convert Fargate tasks to use Spot Instances.

Why wrong: Standard RIs apply only to EC2 and not to Fargate. Spot Instances could be used for fault-tolerant workloads, but the question asks for a single purchasing option that covers both compute services.

Use On-Demand instances for both EC2 and Fargate because the administrator does not want to make a commitment.

Why wrong: On-Demand is the most expensive option. Since the workloads are steady, a Savings Plan or RI would provide significant cost savings.

Use a launch template that specifies a Spot Instance type and set the total capacity to the desired level, relying on capacity rebalance to replace interrupted Spot Instances.

Why wrong: If all instances are Spot, the baseline capacity is not guaranteed because Spot Instances can be reclaimed at any time. Capacity rebalance helps but does not ensure capacity.

Purchase Compute Savings Plans to cover the entire Auto Scaling group, and use only Spot Instances for all capacity.

Why wrong: Savings Plans provide a discount but do not guarantee capacity. Spot Instances still risk interruption, so baseline capacity is not assured.

Configure the Auto Scaling group with a launch template that sets the instance market to 'spot' and use a scaling policy that always maintains the minimum capacity.

Why wrong: Even with a scaling policy, Spot Instances can be terminated by EC2, causing the group to fall below the minimum if replacements are delayed or unavailable.

On-Demand Instances

Why wrong: On-Demand is fully priced and does not provide cost savings for a workload that can tolerate interruptions.

Reserved Instances

Why wrong: Reserved Instances require a 1- or 3-year commitment and are best for steady-state workloads. The nightly batch does not justify a long-term commitment.

Compute Savings Plans

Why wrong: Savings Plans offer discounts in exchange for a usage commitment, but the workload is short and can use Spot which provides even higher savings without commitment.

AWS Cost Explorer

Why wrong: Cost Explorer provides cost and usage data and has rightsizing recommendations based on CloudWatch metrics, but it is less specialized than Compute Optimizer for this specific requirement. Compute Optimizer is the primary service for rightsizing.

AWS Trusted Advisor

Why wrong: Trusted Advisor checks for idle instances and other cost optimization opportunities but does not provide detailed rightsizing recommendations based on historical utilization.

AWS CloudTrail

Why wrong: CloudTrail logs API calls for auditing and security, not for resource optimization recommendations.

AWS Cost Explorer

Why wrong: Cost Explorer provides historical cost data and forecasts but does not natively send proactive alerts when spending exceeds a threshold.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides cost optimization recommendations (e.g., idle resources) but does not provide budget alerts based on spending thresholds.

AWS CloudTrail

Why wrong: CloudTrail records API calls for auditing and compliance, not for monitoring spending.

Use S3 Standard for 30 days, then transition to S3 Glacier Deep Archive.

Why wrong: While this saves storage costs after 30 days, Glacier Deep Archive has retrieval times of hours and significant data retrieval costs if files need to be accessed. It also does not automatically adapt if access patterns change.

Use S3 Standard then transition to S3 Glacier Flexible Retrieval after 30 days.

Why wrong: Glacier Flexible Retrieval has retrieval times of minutes to hours and retrieval costs. The transition is static and does not adapt to changing access patterns, potentially costing more if files are accessed again.

Use S3 One Zone-IA for the first 30 days, then transition to S3 Standard-IA.

Why wrong: S3 One Zone-IA does not provide the same durability as other classes and is not recommended for critical data. Also, the transition does not automatically adapt to access patterns.

On-Demand Instances

Why wrong: On-Demand provides no interruption but is the most expensive option, not optimal for cost minimization.

Reserved Instances

Why wrong: Reserved Instances require a 1 or 3 year commitment and are best for predictable, continuously running workloads. The batch job runs only 3 hours nightly, which does not justify a reservation.

Dedicated Hosts

Why wrong: Dedicated Hosts provide physical servers for licensing compliance but are significantly more expensive and not needed for this workload.

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

Why wrong: Manual moves are error-prone and incur overhead. Also, S3 Standard is more expensive for infrequently accessed data.

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

Why wrong: Standard-IA has per-GB retrieval charges and is not cost-effective for frequently accessed data.

Use S3 Glacier Instant Retrieval

Why wrong: 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.

AWS Cost Explorer

Why wrong: AWS Cost Explorer provides cost and usage reports and forecasts, but it does not provide specific EC2 rightsizing recommendations based on utilization metrics.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor includes a cost optimization check for idle instances and underutilized Amazon EBS volumes, but it does not provide detailed rightsizing recommendations for EC2 instance types.

Amazon CloudWatch Dashboard

Why wrong: CloudWatch Dashboards display metrics but do not generate recommendations; they are used for visualization, not automated optimization.

Transition to S3 Standard-IA after 7 days, then to S3 Glacier Flexible Retrieval after 30 days.

Why wrong: Glacier Flexible Retrieval has retrieval times of 1-5 minutes typically (expedited) or 3-5 hours (standard). Though expedited can be minutes, it incurs additional cost, and the standard retrieval may exceed the 'within minutes' requirement. Glacier Instant Retrieval is a better and more cost-effective option.

Transition to S3 One Zone-IA after 7 days, then to S3 Glacier Deep Archive after 30 days.

Why wrong: One Zone-IA does not provide the same durability as Standard-IA and is not recommended for critical data. Glacier Deep Archive has retrieval times of 12 hours or more, which fails the 'within minutes' requirement.

Transition to S3 Intelligent-Tiering after 7 days.

Why wrong: Intelligent-Tiering automatically moves data between tiers based on access patterns, but it charges a monthly monitoring fee per object that may be cost-prohibitive for many small files. Additionally, it does not transition to the cheapest long-term tier like Glacier Instant Retrieval, so overall costs may be higher.

EC2 Instance Savings Plans

Why wrong: Locked to a specific instance family in a region.

Standard Reserved Instances

Why wrong: Less flexible than Savings Plans for changing instance types.

Spot Instances

Why wrong: Not suitable for steady-state workloads due to potential interruptions.

S3 Standard for 30 days, then transition to S3 Glacier (Flexible Retrieval)

Why wrong: Higher storage cost than Deep Archive for rarely accessed data.

Use S3 Intelligent-Tiering from the start

Why wrong: Adds monitoring and automation costs; not the cheapest for rarely accessed data.

S3 Standard for 30 days, then transition to S3 One Zone-IA

Why wrong: Not redundant; unsuitable for long-term compliance retention.