Cost Optimization practice questions

Deploy a NAT Gateway in each VPC.

Why it fails: NAT Gateways carry an hourly charge per gateway and a data processing fee per GB. While they allow access to S3 via the internet, they are significantly more expensive than using a Gateway Endpoint, which provides the same connectivity for free and without the per-GB processing costs.

Create an S3 Interface Endpoint (PrivateLink) in each VPC.

Why it fails: Interface Endpoints (AWS PrivateLink) charge an hourly fee for each Availability Zone where they are deployed, plus a data processing fee per GB. While useful for accessing S3 from on-premises or across regions, they are more expensive than Gateway Endpoints for standard VPC-to-S3 connectivity within a region.

Establish a AWS Direct Connect connection to S3.

Why it fails: Direct Connect is a high-cost physical connection between an on-premises data center and AWS. It is not a cost-effective solution for intra-region VPC-to-S3 traffic, as it involves significant setup costs, monthly port fees, and is designed for hybrid cloud connectivity rather than internal AWS traffic.

Use Amazon EC2 Reserved Instances to cover the nightly batch processing requirements over a one-year term.

Why it fails: Reserved Instances are designed for continuous workloads running 24/7 to maximize hourly savings. Because this workload only runs for 4 hours per night, paying for idle capacity during the remaining 20 hours makes Reserved Instances financially inefficient.

Provision Amazon EC2 On-Demand Instances and terminate them manually through an AWS Lambda script after completion.

Why it fails: On-Demand instances bill per second while running and offer no discount, and manual termination via Lambda adds no cost benefit over automatic lifecycle management. They are tempting when workloads cannot tolerate interruption, but this batch job explicitly can be interrupted and resumed.

Purchase Amazon EC2 Dedicated Hosts to run the nightly batch processing instances securely and predictably.

Why it fails: Dedicated Hosts bill per host for the full allocation period regardless of instance usage, defeating cost optimisation for a 4-hour interruptible job. They are tempting when licensing or compliance demands physical server isolation and tenancy visibility.

Place all EC2 instances in the public subnet to maximize accessibility.

Why it fails: Placing all instances in a public subnet exposes them directly to the internet, increasing the attack surface. Security best practices dictate that only necessary resources, like load balancers, should be public, while application and database tiers should reside in private subnets to isolate them from direct inbound traffic.

Configure Security Groups to allow all traffic (0.0.0.0/0) on all ports.

Why it fails: Allowing all traffic on all ports is a severe security risk that violates the principle of least privilege. Security groups should be configured with specific protocols and port ranges only for authorized traffic sources, ensuring that services are not exposed to unnecessary threats or unauthorized connections from the internet.

Disable VPC Flow Logs to reduce the storage costs in S3.

Why it fails: VPC Flow Logs are critical for security auditing and forensic analysis. Disabling them saves costs but obscures visibility into network traffic patterns. Best practices require keeping these logs enabled to monitor for anomalous traffic, troubleshoot security issues, and maintain a historical record of network activity for compliance and security reviews.

Amazon EC2 T3-micro instances.

Why it fails: Even a small EC2 instance like T3-micro incurs a continuous hourly charge regardless of whether it is processing requests or sitting idle. For an API called only a few dozen times a day, the instance would be idle 99% of the time, leading to wasted spend compared to serverless options.

Amazon ECS on AWS Fargate.

Why it fails: While Fargate is serverless, it charges based on the resources provisioned for the duration the container is running. If the container stays running to listen for API calls, you pay for those resources 24/7. Even with scaling to zero, the overhead and minimum billing intervals are less efficient than Lambda for this scale.

Amazon Lightsail.

Why it fails: Lightsail provides low-cost, fixed-price virtual private servers. While the price is predictable, it is still a 'per month' cost that applies even when the service is not in use. It lacks the granular per-request billing that makes Lambda the superior choice for extremely low-volume API workloads.

Backup and Restore.

Why it fails: Backup and Restore is the most cost-effective but slowest DR strategy. It involves restoring backups after a disaster occurs, which can take hours or days. This would fail to meet the 30-minute RTO requirement, as provisioning new infrastructure and restoring large datasets from backups cannot typically be completed within that aggressive time window.

Pilot Light.

Why it fails: In a Pilot Light strategy, only the most critical core elements (like the database) are kept running and up-to-date in the DR region. Other resources, like application servers, are provisioned only during a disaster. While faster than Backup and Restore, it often takes longer than 30 minutes to scale and configure the full environment.

Multi-site Active-Active.

Why it fails: Multi-site Active-Active involves running the full production environment in two or more regions simultaneously and splitting traffic between them. This provides the lowest RTO and RPO (near zero) but is the most expensive strategy because you are paying for full duplicate infrastructure at all times, which does not align with the goal of minimizing costs.

Increase the EC2 instance size.

Why it fails: Increasing the instance size provides more CPU and RAM but does not inherently improve network throughput if the bottleneck is the path to S3. While larger instances have higher network limits, the fundamental issue of network routing remains. Optimizing the network path via VPC endpoints is more effective.

Enable S3 Transfer Acceleration.

Why it fails: S3 Transfer Acceleration is designed for long-distance uploads to S3 from client machines over the public internet using CloudFront edge locations. It is not intended for high-speed data transfer between AWS services within the same internal network, making it an inappropriate solution for this specific EC2-to-S3 bottleneck.

Use CloudFront to cache the images.

Why it fails: CloudFront is excellent for distributing content to users, but for an EC2 instance pulling data for processing, adding a caching layer adds architectural complexity without guaranteeing performance improvements. The instance should be pulling directly from S3, ideally via a VPC endpoint, for the most efficient, low-latency performance.

Use a fixed size Auto Scaling group at maximum capacity.

Why it fails: Maintaining a fixed size at maximum capacity ensures performance but is highly cost-inefficient. It wastes resources during off-peak hours and does not scale dynamically to meet unexpected traffic surges. This approach ignores the cost-saving benefits of cloud elasticity and is generally not recommended for variable production workloads.

Configure the ALB to handle all scaling automatically.

Why it fails: An Application Load Balancer manages the distribution of traffic among instances, but it does not control the scaling of the instances themselves. While the ALB itself is highly scalable, the underlying EC2 instances require an Auto Scaling group to handle changes in compute capacity based on demand.

Use reserved instances to handle all peak traffic.

Why it fails: Reserved Instances offer significant cost savings, but they commit you to a specific instance count. If you reserve capacity for peak traffic, you pay for unused resources during low-traffic periods. Auto Scaling is required to adjust the actual fleet size in response to real-time traffic fluctuations.

AWS Certificate Manager (ACM) to request public certificates for the services.

Why it fails: Public certificates from ACM require domain ownership validation via DNS or email and are only suitable for publicly accessible endpoints. For internal microservices that do not have public DNS records, public certificates cannot be issued, making a private CA the necessary solution for internal encryption.

AWS CloudHSM to store and manage the private keys for the certificates.

Why it fails: AWS CloudHSM is a cloud-based hardware security module that allows you to generate and use your own encryption keys. While it can be used as a backend for a CA, it requires significant manual configuration and management of the PKI software, which does not meet the requirement of reducing overhead.

Amazon Inspector to audit the certificates used by the microservices.

Why it fails: Amazon Inspector is a vulnerability scanning service and does not have the capability to issue or manage SSL/TLS certificates. While it might identify if a service has an expired certificate, it is a detective tool rather than a management or issuance service for cryptographic identities and secure communication.

Use Multi-AZ deployments for all read-only workloads.

Why it fails: Multi-AZ deployments are primarily used for high availability and failover, not for cost optimization. In fact, Multi-AZ doubles the cost of the database because it provisions a standby instance in a different Availability Zone. For read-only workloads, Read Replicas are a better performance choice, though they also increase costs.

Switch to an Amazon RDS Custom for MySQL instance.

Why it fails: RDS Custom is designed for applications that require access to the underlying operating system or specific database settings not available in standard RDS. It does not provide cost savings and may actually increase operational overhead and licensing costs, making it a poor choice for a purely cost-focused optimization task.

Enable Provisioned IOPS (PIOPS) for all storage volumes.

Why it fails: Provisioned IOPS storage is more expensive than General Purpose SSD (gp3) storage. While PIOPS provides consistent, high-performance I/O, it should only be used when specific performance requirements cannot be met by gp3. Enabling it across all volumes would increase the monthly storage bill without necessarily providing a cost-benefit.

On-Demand Instances

Why it fails: On-Demand instances are the most expensive way to consume EC2 capacity because you pay for flexibility without any long-term commitment. For a workload that runs every night and can handle interruptions, paying the full hourly rate is unnecessary and results in significantly higher costs than using spare AWS capacity.

Dedicated Hosts

Why it fails: Dedicated Hosts are physical servers dedicated to a single customer, usually required for specific compliance needs or complex licensing models (BYOL). They are much more expensive than standard multi-tenant EC2 instances and offer no benefit for a simple batch processing workload that can run on shared infrastructure.

Reserved Instances

Why it fails: Reserved Instances require a 1-year or 3-year commitment and are best suited for steady-state workloads that run continuously. While they offer a discount over On-Demand, they do not provide the same level of savings as Spot Instances for workloads that are only active for a few hours per night.

On-Demand Instances

Why it fails: On-Demand Instances are the most flexible but also the most expensive purchasing option. They are best suited for short-term, unpredictable workloads that cannot be interrupted. For a batch job that runs periodically and can handle interruptions, using On-Demand would result in significantly higher costs than other available AWS options.

Reserved Instances

Why it fails: Reserved Instances require a one-year or three-year commitment to a specific instance type and region. While they offer substantial discounts, they are designed for steady-state workloads that run 24/7. Paying for a reservation that is only utilized during weekends would result in a higher effective hourly rate than Spot.

Dedicated Hosts

Why it fails: Dedicated Hosts provide a physical server fully dedicated to a single customer, usually to meet strict licensing or regulatory requirements. They are the most expensive way to run EC2 instances. Using them for a batch processing job without a specific licensing requirement would be an inefficient and costly architectural decision.

Intelligent-Tiering is only supported for objects larger than 128 KB.

Why it fails: Intelligent-Tiering does not have a hard requirement for object size, though very small objects may not benefit from storage class transitions as much as larger ones. The primary issue here is the cost structure of the monitoring fees when applied to a very high volume of individual objects.

The lifecycle rule should use S3 Glacier Deep Archive instead of Intelligent-Tiering.

Why it fails: While Deep Archive is cheaper for storage, it is intended for long-term archival with retrieval times of hours. If the logs need to be accessed occasionally for troubleshooting, Deep Archive would be too slow. The issue in the exhibit is the monitoring fee for millions of files in Intelligent-Tiering.

The prefix filter is too broad and will include active logs.

Why it fails: The prefix 'logs/' is a standard practice for grouping objects. Assuming the application writes logs to this path, the lifecycle rule correctly targets them. The prefix itself does not cause cost inefficiencies; the cost issue stems from the choice of storage class and the volume of small objects.

Scale up the primary RDS instance to a larger instance class with more RAM.

Why it fails: Scaling up the primary instance is a vertical scaling strategy that increases the cost of the entire database 24/7. Since the write activity is low, paying for a larger instance just to handle peak read traffic is inefficient compared to using Read Replicas, which can be scaled more granularly.

Switch the database to Amazon RDS for SQL Server to take advantage of License Inclusion.

Why it fails: Switching to SQL Server from MySQL would likely increase costs due to licensing fees and architectural changes. MySQL is an open-source engine with no licensing costs. Moving to a commercial engine would be counterproductive for a project specifically focused on reducing the overall cost of the database layer.

Enable Multi-AZ for all Read Replicas to ensure high availability.

Why it fails: Enabling Multi-AZ on Read Replicas doubles the cost of each replica because AWS provisions a standby instance. While this improves availability, it is often unnecessary for read-only traffic that can be rerouted if a replica fails, making it a poor choice for a strategy focused strictly on cost reduction.

Store all images in S3 Intelligent-Tiering from the start.

Why it fails: While S3 Intelligent-Tiering is effective for data with unknown access patterns, it includes a monitoring and automation fee per object. For data with a known access pattern—frequent access for exactly 30 days followed by rare access—lifecycle policies offer more precise control and lower costs without automation fees.

Transition objects to S3 Glacier Deep Archive after 30 days.

Why it fails: S3 Glacier Deep Archive is designed for long-term archival with retrieval times of 12-48 hours. If the application needs to access these images occasionally, the high retrieval latency makes this class unsuitable. Furthermore, the storage is cheaper, but the operational impact of long retrieval times exceeds the cost benefits.

Manually move images to S3 One Zone-IA after 30 days.

Why it fails: Manual intervention is operationally inefficient and prone to errors. S3 lifecycle policies automate this process, ensuring consistency and cost savings without human overhead. Additionally, S3 One Zone-IA lacks the multi-AZ resilience of S3 Standard-IA, which may not meet the availability requirements for critical user-uploaded image data.

Amazon RDS for MySQL on a T3-medium instance.

Why it fails: Using a standard RDS instance results in continuous hourly charges. Even with a small T3 instance, the company would be paying for the database 24/7, even during the days when there is no activity. This leads to significant wasted expenditure compared to a serverless model.

Amazon Aurora with a Reserved Instance.

Why it fails: Reserved Instances offer a discount for a committed term but are designed for steady-state workloads that run 24/7. For a database that is unused for days at a time, the cost of the reservation—even with the discount—is much higher than the on-demand serverless charges for occasional bursts.

Amazon RDS with Multi-AZ enabled.

Why it fails: Multi-AZ is a high-availability feature that doubles the number of instances and nearly doubles the cost. It provides no cost-optimization benefits and is unnecessary for a legacy application with infrequent usage where a slight delay in scaling or recovery might be acceptable.

Amazon S3 Standard-IA.

Why it fails: Standard-IA is cheaper than Standard for storage, but it is more expensive than Glacier Instant Retrieval. Since the data is kept for 7 years and rarely accessed, the higher monthly storage fee of Standard-IA adds up significantly over time compared to the more specialized archival tiers.

Amazon S3 Glacier Flexible Retrieval.

Why it fails: Glacier Flexible Retrieval offers very low storage costs, but retrieval times range from 1 to 5 minutes (expedited) to several hours. While it meets the 'few minutes' requirement if expedited retrieval is used, the per-request cost for expedited retrieval is high. Instant Retrieval is often more predictable for small objects.

Amazon S3 Glacier Deep Archive.

Why it fails: Glacier Deep Archive is the lowest-cost storage in the cloud, but it has a minimum retrieval time of 12 hours. This fails the company's requirement to be able to retrieve records within a few minutes for audits, making it an unsuitable choice despite its superior cost-optimization for storage.

Amazon EC2 with Auto Scaling

Why it fails: EC2 instances are billed per second with a minimum of 60 seconds. In a bursty scenario where the task only lasts 30 seconds, an EC2 instance would likely spend more time booting up and shutting down than doing work. Even with Auto Scaling, the overhead and idle time make it less efficient than serverless.

AWS Fargate

Why it fails: Fargate is a serverless container service, but it is generally better for tasks that run for longer periods (minutes to hours). For a 30-second task, the time required to pull the container image and start the task would be inefficient, and the billing granularity is not as fine as Lambda's millisecond-based model.

Amazon EC2 Spot Instances

Why it fails: While Spot Instances are cheap, they are not designed for tasks that only last 30 seconds. The overhead of provisioning an instance, waiting for it to be available, and managing the application lifecycle for such a short duration is impractical. Lambda provides better cost-efficiency and much lower operational complexity for this specific use case.

Enable S3 Cross-Region Replication for all objects.

Why it fails: Cross-Region Replication provides disaster recovery across regions but does not inherently protect against accidental deletions within the source bucket. If an object is deleted in the source, the delete marker is replicated to the destination. Versioning is required to truly protect against accidental deletions in S3.

Modify the IAM policy to include s3:DeleteObject in the Deny statement.

Why it fails: Applying a broad Deny on delete operations makes it impossible to manage data lifecycles or clean up temporary files. This is not a scalable way to protect against accidental deletions. Robust protection should rely on S3 bucket features like Versioning and MFA Delete rather than restrictive IAM policies alone.

Use S3 Intelligent-Tiering for all objects to reduce storage costs.

Why it fails: S3 Intelligent-Tiering is a cost-optimization feature that moves objects between access tiers based on usage patterns. While it reduces costs, it does not provide protection against accidental deletion. Resilience and data protection must be addressed through features like Versioning, independent of the storage tiering strategy implemented for cost.

AWS CloudTrail.

Why it fails: CloudTrail is a service that records API calls and account activity for security, auditing, and compliance. While it tells you who created a resource, it does not provide analysis of resource utilization or cost-saving recommendations, making it the wrong tool for identifying idle resource waste.

Amazon Inspector.

Why it fails: Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. It focuses on finding vulnerabilities and deviations from best practices in security, not on cost optimization or identifying idle infrastructure resources.

Convert the RDS instances to Multi-AZ deployments.

Why it fails: Multi-AZ deployments provide high availability and failover support by maintaining a synchronous standby in a different Availability Zone. This doubles the hourly cost of the database instance. Since this is a development environment where high availability is not a requirement, Multi-AZ would significantly increase costs without providing necessary value.

Purchase All Upfront Reserved Instances for the development environment.

Why it fails: Reserved Instances (RIs) provide a discount for a committed term of 1 or 3 years. However, RIs are most cost-effective for instances that run 24/7. If an instance is stopped for more than 60-70% of the time, the savings from stopping the instance actually exceed the discount provided by an RI.

Move the databases to Amazon DynamoDB to utilize on-demand scaling.

Why it fails: While DynamoDB On-Demand can be cost-effective, migrating from a relational MySQL database to a NoSQL DynamoDB table requires a complete rewrite of the application code and data schema. The operational and development costs of such a migration usually far outweigh the simple infrastructure savings achieved through instance scheduling.