Design Cost-Optimized Architectures practice questions

Provision On-Demand instances sized for peak capacity 24/7.

Why it fails: Provisioning for peak capacity at all times results in significant over-provisioning during off-peak hours. You would pay for compute cycles that remain idle during the night, leading to unnecessary expenses. This is the least cost-effective strategy for workloads with predictable, fluctuating traffic patterns.

Migrate the entire application to AWS Lambda functions.

Why it fails: While serverless can be cost-effective, migrating a stateless application to Lambda may involve significant refactoring costs and potential latency issues if the application is not designed for event-driven execution. It is not inherently cheaper than EC2 for high-volume, steady-state traffic workloads compared to optimized RI usage.

Use Spot Instances for the entire fleet to maximize savings.

Why it fails: Spot instances can be interrupted with only a two-minute warning, making them unsuitable for core web application tiers that require high availability. Relying on Spot for the entire fleet risks application downtime during price spikes or capacity reclamation, failing to meet production stability requirements for user-facing services.

Provision Provisioned IOPS SSD (io1) storage to handle the maximum expected load.

Why it fails: Provisioned IOPS SSD (io1) is an expensive storage option designed for high-performance, consistent I/O requirements. For a workload with low activity at night, this leads to significant over-provisioning and higher costs. General Purpose SSD (gp3) is much more cost-effective for variable workloads requiring baseline performance.

Upgrade to a larger instance type to ensure performance never drops.

Why it fails: Upgrading to a larger instance type increases the hourly compute cost without addressing the underlying issue of workload variability. If the current instance size handles peak loads successfully, a larger instance merely wastes money during off-peak hours by providing unused compute capacity that the application cannot utilize effectively.

Enable Multi-AZ deployment for all non-production database environments.

Why it fails: Multi-AZ deployments double the cost of your RDS instance because they maintain a standby replica for high availability. Enabling this for non-production environments is an unnecessary expense if those environments do not require high availability or sub-minute failover capabilities. Single-AZ is sufficient for most non-critical development workloads.

The policy should use S3 Intelligent-Tiering to automate cost savings without manual lifecycle rules.

Why it fails: S3 Intelligent-Tiering is excellent for data with changing or unknown access patterns, but it includes a small monitoring and automation fee per object. For logs that are known to be accessed rarely, transitioning directly to Glacier Deep Archive avoids these extra fees and provides a lower overall price point.

The policy should transition objects to S3 One Zone-IA to reduce costs by 20% over standard Glacier.

Why it fails: S3 One Zone-IA is cheaper than Standard-IA but is significantly more expensive than Glacier Deep Archive. Furthermore, One Zone-IA stores data in a single Availability Zone, which may not meet compliance requirements for log durability if that specific zone experiences a failure, unlike the multi-AZ durability of Glacier.

The policy is inefficient because Glacier Flexible Retrieval offers faster access at the same price point.

Why it fails: Glacier Flexible Retrieval is a separate storage class that offers faster retrieval times, typically minutes to hours, compared to Deep Archive. However, it carries a higher monthly storage cost per gigabyte. Since the company specifically accepts a 12-hour delay, paying for the faster retrieval class would be unnecessary.

Store all data in S3 Standard for the entire duration.

Why it fails: S3 Standard is the most expensive storage class for data that is not being accessed. While it provides immediate access, keeping 100 TB of rarely accessed data in this tier after the initial 30-day period results in unnecessary monthly costs that could be avoided by using an infrequent access tier.

Use S3 Lifecycle policies to move data to S3 Standard-IA after 30 days.

Why it fails: S3 Standard-IA offers a lower storage price than S3 Standard while maintaining the same low latency and high throughput. This fits the requirement perfectly because the data is rarely accessed after the first month, but must still be available instantly whenever a request is finally made by a customer.

Move data to S3 Glacier Instant Retrieval after 30 days.

Why it fails: While Glacier Instant Retrieval provides immediate access and lower storage costs than Standard-IA, it is intended for data accessed once a quarter. If the 'rare' access pattern in this scenario is more frequent than once a quarter, the higher retrieval fees of Glacier could offset the storage savings compared to Standard-IA.

AWS Trusted Advisor

Why it fails: Trusted Advisor provides high-level recommendations for cost optimization, such as identifying buckets without versioning or lifecycle policies. However, it does not provide the granular, object-level access analysis or automated tiering capabilities required to manage millions of objects with unknown access patterns as effectively as specialized S3 tools.

Amazon S3 Inventory

Why it fails: S3 Inventory provides a CSV or ORC file listing objects and their metadata, which is useful for auditing or encryption checks. While it helps with visibility, it does not provide access frequency data or automate the movement of data between storage classes, making it less direct for cost optimization than other tools.

AWS Budgets

Why it fails: AWS Budgets allows you to set custom budgets that alert you when your costs or usage exceed your budgeted amount. While it is a critical tool for monitoring overall spend, it is a reactive reporting tool and does not provide the technical insight or automation needed to optimize S3 storage tiers specifically.

Standard Reserved Instances

Why it fails: Standard Reserved Instances (RIs) are limited to EC2 and are locked to a specific instance family and region. They do not cover Lambda or Fargate usage. If the company decides to migrate an EC2 workload to Lambda, the Standard RI would no longer provide any savings, making it an inflexible choice.

EC2 Instance Savings Plans

Why it fails: While more flexible than RIs, EC2 Instance Savings Plans are still limited to a specific instance family within a region (e.g., M5 in us-east-1). They do not cover Lambda or Fargate, which fails to meet the company's requirement for a single commitment that covers their diverse range of compute services.

Convertible Reserved Instances

Why it fails: Convertible RIs allow you to change instance families, but they only apply to EC2 and require manual management to perform the conversion. They do not provide any cost benefit for Lambda or Fargate. Compared to Compute Savings Plans, they involve more administrative effort and offer less coverage for modern serverless architectures.

Enable S3 Transfer Acceleration for the bucket.

Why it fails: S3 Transfer Acceleration is designed to speed up uploads to S3 from distant locations using the AWS Edge network. It does not reduce data transfer costs for downloading content to users and actually incurs an additional per-GB fee, making it the wrong choice for optimizing egress costs for a static website.

Replicate the S3 bucket to regions in Asia and Europe.

Why it fails: Cross-Region Replication (CRR) would incur additional storage costs for the duplicate data in every region, as well as inter-region data transfer fees for the initial replication. While it might improve performance, it is significantly more expensive and complex than using a CDN like CloudFront to cache the data.

Use an Application Load Balancer to distribute traffic between regions.

Why it fails: An Application Load Balancer (ALB) is used for routing traffic to compute resources like EC2 or Lambda. It is not a caching solution and does not reduce data transfer costs for S3. Using an ALB for a static site would introduce unnecessary hourly costs and complexity without solving the global latency issue.

Create a script to move old files from EFS to an S3 Glacier bucket.

Why it fails: While S3 Glacier is cheaper, moving files from a filesystem (EFS) to an object store (S3) requires changing how the application accesses that data. This adds significant architectural complexity and development effort. EFS Lifecycle Management provides similar savings natively within the filesystem, keeping the process transparent to the application.

Use EFS Provisioned Throughput to optimize data transfer speeds.

Why it fails: Provisioned Throughput is a feature used to guarantee performance for high-throughput workloads; it does not reduce storage costs. In fact, it adds an additional hourly charge. For a cost-optimization goal, the company should use Bursting Throughput and focus on storage tiering rather than throughput provisioning.

Migrate the data to an Amazon EBS volume with Multi-Attach enabled.

Why it fails: EBS Multi-Attach only works with specific volume types (io1/io2) and has limitations on the number of instances and filesystem types (it requires a cluster-aware filesystem). This is much more expensive and complex than EFS and would not provide the same ease of scaling or the cost-effective 'Infrequent Access' tier.

Provisioned capacity with Auto Scaling.

Why it fails: Provisioned capacity with Auto Scaling is best for predictable traffic that changes gradually. However, it takes time for the scaling policy to trigger and provision new capacity. During sudden, sharp spikes, the application might experience throttling before the scaling can catch up, or you might over-pay for idle capacity.

Reserved Capacity.

Why it fails: Reserved Capacity allows you to pay a one-time upfront fee for a 1-year or 3-year commitment to a minimum level of provisioned throughput. This is only cost-effective for very stable, high-baseline workloads. It is not suitable for unpredictable spikes as it still relies on the provisioned capacity model.

Provisioned capacity with a high fixed limit.

Why it fails: Setting a high fixed limit for provisioned capacity ensures that spikes are handled without throttling, but it is the least cost-optimized approach. You would be paying for the maximum possible capacity 24/7, even when traffic is low, leading to significant waste and unnecessary cloud expenditure.

Use a VPC Peering connection between the ALB and CloudFront.

Why it fails: CloudFront is a global service that exists outside of a specific VPC. It is not possible to establish a VPC Peering connection between a VPC-based resource like an ALB and the CloudFront edge network. AWS handles this connectivity internally through the AWS global backbone.

Ensure the ALB is the origin for the CloudFront distribution.

Why it fails: When an ALB is configured as the origin for CloudFront, there is no charge for the data transfer from the ALB to CloudFront (Data Transfer Out to CloudFront). This is a built-in cost benefit of using CloudFront with other AWS services, effectively reducing the total cost of data delivery.

Implement AWS Global Accelerator.

Why it fails: AWS Global Accelerator is used to improve network performance by routing traffic through the AWS global network, but it is not a caching service like CloudFront. In fact, Global Accelerator adds its own hourly and data transfer charges, which would increase the total cost rather than reducing it.

Amazon Elastic File System (EFS) with Provisioned Throughput.

Why it fails: Amazon EFS is a great general-purpose file system, but its cost for high-throughput HPC workloads is very high compared to FSx. Provisioned Throughput adds a significant monthly fee that is charged 24/7, even if the HPC job only runs for a few hours per day.

Amazon FSx for Lustre using Persistent 2 deployment.

Why it fails: Persistent file systems are designed for longer-term workloads and provide high availability through data replication and automatic failover. This added durability comes at a higher price. For a short-lived HPC task where data can be easily reloaded from S3, the extra cost of Persistent storage is not justified.

Amazon S3 using S3 Transfer Acceleration.

Why it fails: S3 Transfer Acceleration speeds up data uploads to S3, but it is not a file system. HPC applications typically require POSIX-compliant shared storage with sub-millisecond latencies. S3 is an object store and cannot provide the IOPS or file-level performance needed for high-performance computing applications.

Store all images in S3 Standard-Infrequent Access (S3 Standard-IA) from day one.

Why it fails: S3 Standard-IA has a minimum storage duration of 30 days and charges a retrieval fee per GB. Since images are accessed frequently during the first month, these retrieval fees would significantly increase total costs compared to S3 Standard, making this choice less optimal for the initial high-access phase.

Configure an S3 Lifecycle policy to move objects to S3 Glacier Deep Archive after 30 days.

Why it fails: Glacier Deep Archive is intended for long-term retention of data that is rarely accessed and requires hours for retrieval. Because the requirement states that some images may still be accessed daily after the 30-day mark, the high retrieval costs and long latency of Deep Archive make it unsuitable.

Implement an S3 Lifecycle policy to transition objects to S3 One Zone-IA after 30 days.

Why it fails: S3 One Zone-IA stores data in a single Availability Zone, which reduces costs but increases the risk of data loss if that zone fails. While cheaper than Standard-IA, it still carries retrieval fees that would be costly for images accessed daily, and it lacks the automated tiering benefits.

On-Demand Instances

Why it fails: On-Demand Instances are the most expensive option and are best suited for short-term, unpredictable workloads that cannot be interrupted. For a fault-tolerant batch job that runs regularly, using On-Demand would result in significantly higher costs than leveraging the spare capacity pricing offered by the Spot Instance market.

Dedicated Hosts

Why it fails: Dedicated Hosts are physical servers with EC2 instance capacity fully dedicated to a single customer. They are typically used for compliance requirements or specific software licensing needs. Using Dedicated Hosts for a simple batch job would be extremely expensive and provide no cost benefit for this specific scenario.

Reserved Instances

Why it fails: Reserved Instances require a one-year or three-year commitment for a specific amount of capacity. Since the batch jobs only run twice a week for 6 hours each, the instances would sit idle for the vast majority of the time, resulting in poor utilization and higher costs compared to Spot Instances.

Use Public IP addresses for all communication between EC2 instances.

Why it fails: Using Public IP addresses for communication between instances, even within the same region, always incurs data transfer charges. This is because the traffic is routed through the internet layer. To minimize costs, instances should always communicate using Private IP addresses, which is free when the instances are in the same AZ.

Enable Cross-Zone Load Balancing on the Application Load Balancer.

Why it fails: Cross-Zone Load Balancing on an ALB is always enabled and included in the price, but it can actually increase inter-AZ data transfer if the ALB nodes send traffic to instances in different zones. While it improves availability, it is not a direct method for reducing data transfer costs in this scenario.

Use AWS Direct Connect for all inter-region data transfers.

Why it fails: While Direct Connect can offer lower data transfer rates than the public internet for very high volumes, the monthly port fees and physical connection costs often make it more expensive for standard inter-region traffic. It is generally not the first choice for cost optimization unless the traffic volume is massive.

Route traffic through a Transit Gateway to consolidate data paths.

Why it fails: While Transit Gateway itself has costs, it can help reduce overall complexity and, when combined with VPC Peering for specific high-traffic paths, can optimize the network. However, in this specific context, Transit Gateway is often used with VPC Endpoints to share services across VPCs, reducing the need for multiple expensive NAT Gateways.

Switch the ALB to a Network Load Balancer to reduce fixed costs.

Why it fails: Network Load Balancers are designed for ultra-high performance and static IP requirements, not for cost savings. In fact, NLBs can be more expensive than ALBs for certain traffic profiles because they charge per LCU-hour, and they lack the intelligent routing features that help optimize application-level traffic efficiency.

Replace the ALB with a single large EC2 instance to act as a proxy.

Why it fails: Replacing a managed service like an ALB with a single instance creates a single point of failure and increases operational burden. The cost saved on the load balancer is outweighed by the loss of high availability and the increased engineering time required to maintain the proxy instance effectively.

Move all EC2 instances to a single Availability Zone.

Why it fails: Consolidating all instances into a single Availability Zone significantly reduces the availability of the application. If that zone experiences an outage, the entire service goes down. Saving on inter-AZ data transfer costs is not worth the risk of catastrophic failure and potential violation of service level agreements.

Enable S3 Transfer Acceleration on the bucket.

Why it fails: S3 Transfer Acceleration is designed to speed up uploads to S3 using AWS edge locations, not to optimize data egress or reduce costs. Enabling this would actually add extra costs to the architecture rather than reducing the existing data transfer charges incurred by standard egress traffic.

Enable S3 Intelligent-Tiering on the bucket.

Why it fails: S3 Intelligent-Tiering optimizes storage costs based on access patterns, but it has no impact on data transfer out charges. Since the issue is related to egress costs, changing the storage class will not provide any relief and would likely increase costs due to the monitoring fees involved.

Switch the bucket storage class to S3 Glacier Instant Retrieval.

Why it fails: Glacier Instant Retrieval is a storage class intended for archives that require millisecond access. It does not reduce data transfer out costs. In fact, it may increase costs for certain access patterns and does nothing to mitigate the egress traffic resulting from public access to the bucket.

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.

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.

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.

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.