CCNA Cost and Performance Optimization Questions

CloudWatch shows low CPU utilization, indicating the t3.large (or current size) is over-provisioned for the actual workload. Downsizing to t3.medium, which has the same vCPU count but half the memory (4 GiB vs 8 GiB), will reduce the on-demand hourly cost while still providing adequate compute for the observed load. Before resizing, confirm memory, network throughput, and application performance remain above the 95th percentile to avoid an undersized instance.

UltraWarm nodes in Amazon OpenSearch Service provide a warm storage tier that is dramatically cheaper per GiB than hot storage but still fully searchable, because it uses a combination of Amazon S3 and a small caching layer. By creating an Index State Management (ISM) policy that moves indices older than 30 days to UltraWarm, the company retains the ability to query compliance-related logs without paying for high-performance EBS-backed hot nodes. This meets both the cost-reduction and the 90-day compliance/retention requirements, since the data remains accessible and the policy can later delete or transition it as needed.

A 1-year Standard RI matches the 12-month stability horizon and delivers 30–40 percent savings versus On-Demand. All Upfront provides the deepest discount; Partial Upfront reduces the upfront cash requirement with a slightly lower overall saving. The 1-year commitment limits risk compared to a 3-year commitment for an uncertain future period.

Changing the launch template to t3.medium corrects the over-provisioning at the source: t3.medium provides the same 2 vCPU count but only 4 GiB of memory, halving the allocated RAM while remaining eligible for burstable CPU credits. For a workload with low average utilization and occasional spikes, t3 instances can burst using earned CPU credits, then settle back to a low baseline, making the smaller instance type adequate. This directly reduces the per-hour cost for every instance the Auto Scaling group launches, which is the most effective right-sizing action listed.

This is correct because logs are typically append-only and rarely accessed after the first 30 days, making S3 Glacier Deep Archive the lowest-cost storage class while satisfying the 3-year retention requirement. User uploads, however, are frequently accessed in the month after upload, so S3 Standard-IA after 30 days reduces cost without sacrificing retrieval performance; then transitioning to Glacier Deep Archive after 90 days aligns with the access drop-off and keeps lifecycle costs minimal.

Increasing the memory allocation is the correct approach because Lambda allocates a proportional amount of virtual CPU (vCPU) based on the configured memory value, up to the maximum allowed. More memory translates to more compute power, which directly speeds up CPU-bound and memory-intensive code, thereby reducing execution duration. For example, a function with 1,769 MB receives a full vCPU, while higher values receive more, so raising memory is effectively scaling up the function's processing capacity.

Enable RDS Performance Insights, which gives you a real-time and historical view of database load dimensioned by waits, SQL statements, and hosts. This is the correct first step because it lets you pinpoint whether the bottleneck is CPU, storage, lock waits, or an inefficient query pattern, rather than guessing. Only after identifying the specific load source should you consider changes like adding indexes, rewriting queries, or scaling the instance.

Spot Instances give the company the largest possible EC2 discount, up to 90% off On-Demand, and are ideal for fault-tolerant, interruptible workloads like the described batch job. Because the job uses checkpointing, it can safely stop after a two-minute Spot interruption notice and later resume from the last saved state, so cost savings are maximized without sacrificing data integrity or job completion.

AWS Budgets is the purpose-built service for tracking spending and usage against predefined cost thresholds, allowing you to create budgets for monthly, quarterly, or annual periods. You can set multiple alerts—both for actual spend and forecasted spend—with custom thresholds and notification preferences (email, SNS) or even Lambda triggers. This directly satisfies the requirement to receive alerts when the monthly AWS spend exceeds a specific amount, making AWS Budgets the correct answer.

Changing the launch configuration to a larger instance type (e.g., from t3.medium to t3.large) vertically scales each EC2 instance, providing more vCPUs and memory to process requests concurrently. This directly reduces per-request CPU queueing and memory pressure during traffic spikes, lowering latency. However, the launch configuration only applies to newly launched instances, so an instance refresh or replacement may be needed to realize the benefit on existing instances.

This is the correct approach because Reserved Instances provide a significant hourly discount in exchange for a one- or three-year commitment, making them ideal for the steady, predictable baseline web traffic. On-Demand Instances, though more expensive, are billed per second with no commitment, so they are perfect for absorbing temporary spikes without over-provisioning or risking capacity loss. By covering the minimum long-term load with Reserved Instances and adding On-Demand Instances only when load increases, you minimize spend while maintaining availability and elasticity — the core goal of cost-aware architecture.

Reserved Instances are a billing discount that requires a 1- or 3-year commitment to a specific instance family, region, and operating system. In exchange for that commitment, you receive up to a 72% discount off the On-Demand hourly rate, depending on the payment option (All Upfront, Partial Upfront, or No Upfront). For an always-on web application with predictable compute needs, this significantly lowers the monthly cost, making Reserved Instances the most cost-effective choice among the available options.

This is the most cost-effective lifecycle policy for logs that are frequently accessed for the first 30 days but rarely read afterward. A lifecycle rule can automatically transition objects to S3 Glacier Deep Archive after 30 days, where storage costs just $0.00099 per GB-month. Even though standard retrieval can take up to 12 hours, that is acceptable for compliance log analysis that is not time-sensitive.

An Auto Scaling group with a scheduled scaling policy adds EC2 instances before the peak begins and removes them after it ends, aligning running capacity with the predicted demand. This is the correct solution because it handles the peak utilization while avoiding the cost of keeping that extra capacity running all day. You can define the schedule using a cron expression, and the group can also be configured with dynamic policies to absorb unexpected spikes beyond the scheduled capacity.

This is the AWS-recommended cost-optimization pattern for transient EMR clusters: the primary node runs On-Demand to guarantee stable HDFS NameNode and ResourceManager availability, while core and task nodes run Spot Instances to exploit steep discounts (often 50–90% off On-Demand). Spot interruptions on core and task nodes are recoverable by EMR's instance-group resizing and task-node retries, but losing the primary node would fail the entire cluster. This mix preserves durability and responsiveness for the critical coordinator while dramatically lowering compute cost for the bulk of the cluster.

Reserved Instances are the most cost-effective choice for a fleet of EC2 instances running a production web application that operates continuously. By committing to 1- or 3-year terms, you can save up to 72% compared to On-Demand pricing, with Flexible size benefits and the ability to change Availability Zones or instance sizes within the same family. Payment options (All Upfront, Partial Upfront, No Upfront) let you further optimize cost based on cash flow, and unused compute capacity is applied automatically. For an always-on workload, the upfront commitment is justified by the substantial savings.

AWS Budgets is the native service for setting a custom cost budget, such as $5,000 per month, and receiving alerts when actual or forecasted charges reach or exceed that amount. You can define multiple alert thresholds (for example, 80% and 100%) and publish notifications to Amazon SNS, which can email you or trigger automated workflows. This makes AWS Budgets the correct solution for a spending alert.

AWS Budgets is the native service for creating cost, usage, and reservation budgets and for sending alerts when actual or forecasted spending exceeds defined thresholds. You can set multiple budget limits, filter by dimensions like service or linked account, and receive notifications via email or SNS. This meets the requirement to receive alerts when estimated charges reach a specified amount, making it the correct answer.

Exporting logs to Amazon S3 offloads them from CloudWatch Logs, where storage is more expensive, and then an S3 Lifecycle policy can automatically transition the objects to Glacier Deep Archive after 30 days. Glacier Deep Archive provides the lowest per-GB storage cost and still satisfies the one-year retention requirement, making this the most cost-effective compliant solution. For optimal savings, after a successful export you should also delete the original log group or set a very short CloudWatch retention so you do not pay for duplicate storage.

Spot Instances provide access to spare AWS compute capacity at discounts of up to 90% versus On-Demand, but AWS can reclaim them with only a two-minute warning. Batch processing jobs with checkpointing are a canonical Spot use case because a reclaimed instance creates no data loss and the work can simply be retried. Using Spot Fleet or EC2 Fleet with multiple instance types and Availability Zones increases resilience and maintains throughput during interruptions, making Spot the optimal and lowest-cost choice.

Stopping the RDS DB instance during non-business hours places it in a 'stopped' state (you can stop it for up to 7 days at a time), during which compute and I/O charges are no longer incurred. Storage and backup costs continue, but you effectively eliminate the expensive instance-hour component for test and development environments that are only used in business hours. This delivers direct cost savings and is the correct answer here.

This approach minimizes costs by applying the highest discount (Reserved Instances) to the steady-state capacity and leveraging the cost savings of Spot Instances for the flexible, peak-demand capacity. Auto Scaling can be configured to launch Spot Instances as needed, providing both cost efficiency and performance.

Using a shared file system like Amazon EFS or object storage like Amazon S3 lets all HPC compute nodes access the same dataset without each node needing its own EBS volume copy. EBS volumes are per-instance block storage charged by GB-month plus IOPS, so duplicating data across hundreds of instances multiplies storage cost and also creates consistency problems when output is written locally. EFS automatically scales and is designed for shared POSIX access, while S3 is ideal for input/output datasets and checkpoint artifacts—both eliminate redundant EBS allocations.

Amazon CloudFront fronts the S3 bucket with a global network of edge locations that cache static assets, so requests are served from the closest edge PoP rather than from the origin bucket directly. This reduces round-trip latency significantly for users worldwide and offloads repeated requests from S3. Additionally, CloudFront provides HTTPS termination and helps cut data transfer costs, as egress from edge locations is cheaper than direct S3 transfer for large audiences. This is the standard, designed solution for improving static site performance.

S3 Standard-IA after 7 days is a sound choice because the files are accessed weekly during that period, and Standard-IA offers the same high durability (99.999999999%) and millisecond latency as Standard while reducing storage costs. After 30 days, transitioning to S3 Glacier Instant Retrieval further cuts storage costs while still providing millisecond retrieval times, so the videos remain instantly accessible on demand. This lifecycle meets the 'within minutes' requirement without incurring the higher retrieval latency or costs of Flexible Retrieval or Deep Archive, making it the most cost-effective and compliant strategy.

On-demand capacity mode charges per request and is ideal for unpredictable traffic, but for workloads with steady or moderately variable usage, provisioned capacity with auto scaling is significantly cheaper because you commit to a baseline of capacity units and pay only for what you provision, while auto scaling adjusts the provisioned throughput based on real-time utilization via CloudWatch alarms, preventing over-provisioning and reducing cost without manual intervention.

Purchasing Reserved Instances for the RDS instance is a cost-optimization practice that does not affect the deployment architecture. Reserved Instances provide a significant hourly discount in exchange for a one- or three-year commitment, applied to the compute portion of the DB instance, while Multi-AZ and its automatic failover capability remain fully intact. This directly reduces operational costs without compromising high availability, making it a correct choice.

Reserved Instances (RIs) lock in a lower hourly rate (up to 72% off On-Demand) for a 1- or 3-year term, making them ideal for the steady, predictable baseline portion of the workload. Spot Instances, priced at up to 90% off On-Demand, provide cheap burst capacity that can be interrupted and replaced, which is acceptable for transient spikes. This combination minimizes cost while ensuring the always-on core stays reliable.

An Auto Scaling group with a target tracking scaling policy based on ALB request count per target continuously monitors the average number of requests each healthy instance receives. When the metric exceeds the target, the policy automatically launches additional EC2 instances, and when it falls below, it terminates instances, ensuring the fleet size tracks actual demand. This dynamic, horizontal scaling optimizes both cost and performance without manual intervention, making it the correct solution for a variable web workload.

A mixed instances policy lets the Auto Scaling group combine On-Demand and Spot capacity while distributing across instance types. Setting On-Demand Base to the minimum needed during business hours creates a hardened floor that will always be fulfilled by On-Demand instances, and setting On-Demand percentage above base to 0% directs all growth beyond that floor to Spot Instances. This isolates the availability-critical baseline from Spot interruptions while saving money on the burst capacity, and it automatically balances between the two markets as the group scales in and out.

This correctly combines a compliance-driven enforcement mechanism with a retroactive bulk-editing tool. AWS Config can run a managed rule that checks instances for the required tags and, if non-compliant, trigger auto-remediation via an SSM Automation document to apply those tags, covering new and modified resources continuously. Activating those tags in the Billing and Cost Management console makes them appear in cost allocation reports, and the Tag Editor can perform bulk search-and-tag across regions using a CSV import for any existing instances that predate the rule. Together, these steps tag both new and existing resources and ensure cost reporting reflects the tags.

AWS Auto Scaling is the correct service because it directly manages the size of an EC2 Auto Scaling group by launching or terminating instances in response to conditions you define. It uses scaling policies (e.g., step, target tracking, or scheduled scaling) that rely on CloudWatch metrics, such as CPU utilization or request count, to automatically adjust capacity. This is the only option here that actually performs the act of scaling EC2 instances, maintaining both performance and cost efficiency.

Placing a CloudFront distribution in front of the S3 bucket caches website objects at edge locations worldwide, so the vast majority of user requests are served from edge caches, not by direct S3 GETs. This dramatically reduces the number of S3 requests billed on a per-request basis, and data transfer from S3 to CloudFront is not charged, lowering egress costs. Additionally, you can restrict direct S3 access with an origin access control and use caching policies to further optimize performance and cost.

Resizing the EC2 instance to a larger type, such as changing from t3.medium to t3.large, is a vertical scaling operation that allocates more compute resources to the same virtual machine. A larger instance type typically provides more vCPUs, higher baseline CPU performance, and more memory, directly increasing the capacity to process instructions without queueing, thereby reducing CPU utilization. For t3 families, the larger size also raises the CPU credit earning rate and baseline (e.g., from 20% to 30% for medium to large), so even modest workloads experience fewer credit exhaustions and less throttling.

AWS Trusted Advisor continuously inspects your AWS environment and delivers real-time recommendations across five categories: cost optimization, performance, security, fault tolerance, and service limits. For cost optimization, it identifies underutilized Amazon EC2 instances, idle RDS databases, and untapped Reserved Instance or Savings Plan opportunities, making it a core tool for right-sizing and eliminating waste.

Configuring an S3 Lifecycle policy to transition objects from S3 Standard to S3 Standard-IA after 30 days and then to S3 Glacier Deep Archive after 90 days is the most effective approach because it automates cost optimization while preserving data availability based on predictable access patterns. Standard-IA reduces storage costs for infrequently accessed data after the initial month, and Glacier Deep Archive provides the lowest storage cost for long-term archival after 90 days. Lifecycle rules handle the transitions in batches, avoid manual effort, and ensure compliance with storage-class minimums. This balances immediate accessibility with long-term cost savings for the 1 PB dataset.

AWS Trusted Advisor is the correct choice because it directly provides cost optimization recommendations, such as identifying idle resources, underutilized Amazon EC2 instances, unattached Elastic IP addresses, and Amazon EBS volumes with low I/O activity. For a company deploying with CloudFormation, Trusted Advisor can highlight which provisioned resources are over- or under-provisioned, enabling right-sizing or termination to reduce spend. Its cost optimization checks also suggest purchasing Reserved Instances or Savings Plans based on usage patterns, making it the only listed service that explicitly targets cost reduction.

Replica lag occurs when the replica cannot keep up with the rate of changes from the primary. Increasing the replica's instance size gives it more resources to apply WAL data faster, reducing lag. This directly addresses the performance bottleneck.

S3 Standard-IA is purpose-built for data that is accessed infrequently but requires millisecond access when requested. It offers the same durability and high availability as S3 Standard at a lower storage price, with a per-GB retrieval fee and a 30-day minimum storage duration. This directly matches the company's usage pattern of infrequently accessed data without sacrificing immediate availability.

Dynamic scaling policies using a target tracking policy based on CPU utilization are correct because they automatically adjust the Auto Scaling group's desired capacity in real time to maintain CPU at a defined target (e.g., 60%). This prevents both over-provisioning and under-provisioning, enabling the web application to handle variable traffic without manual intervention, and it optimizes cost by only adding instances when demand actually increases.

This is the standard, native approach: CloudWatch continuously ingests the CPUUtilization metric from EC2, and an alarm evaluates that metric against a threshold over a specified number of consecutive evaluation periods. By setting the threshold to 80% and the evaluation periods to 5, you get an alert only after the CPU stays above 80% for five straight minutes, matching the requirement exactly. This requires no additional code, no separate services, and integrates directly with SNS for notification, making it the most efficient and reliable solution.

AWS Cost Explorer is a cost management service with an intuitive interface that lets you explore and visualize your AWS costs over time. You can filter and group by service, linked account, region, instance type, and cost-allocation tags, which enables you to produce custom views for cost allocation and chargebacks. Additionally, it supports forecasting and report sharing, making it the appropriate tool for detailed cost analysis and allocation.

Configure Scheduled Scaling to add instances before the spike and remove after. This uses Amazon EC2 Auto Scaling time-based policies to proactively adjust the desired capacity, so instances are fully registered and warmed up when the traffic surge hits. Unlike reactive dynamic scaling, scheduled scaling eliminates the lag that can cause latency or throttling during flash traffic, and then scales back down automatically after the spike to avoid paying for unused resources.

CloudFront Origin Shield acts as an intermediary caching layer between all edge locations and the origin, located in a specific AWS Region. When an edge cache misses, it forwards the request to Origin Shield; if the object is already cached there, Origin Shield serves it directly, preventing a redundant fetch to the origin. This aggregation of requests from multiple edges substantially reduces the number of origin requests and the associated compute and data transfer costs, while also providing a single point for cache fills and origin protection.

RDS instance pricing is based on the instance class and size, so choosing a smaller class directly reduces the hourly compute charge. Since CPU utilization is consistently low, a smaller instance type can meet the workload's performance requirements while still leaving headroom for spikes. This is the most straightforward and effective way to reduce database costs without sacrificing availability or storage.

A predictive scaling policy uses machine learning to analyze historical traffic patterns and forecast future demand, allowing Auto Scaling to launch instances ahead of the actual spike. This proactive approach is ideal for a stateful web application because it eliminates the cold start lag and reduces the risk of insufficient capacity during sudden bursts. It also improves cost efficiency by avoiding over-provisioning, and when combined with a dynamic scaling policy, it can handle both anticipated trends and unexpected deviations. The key is that predictive scaling learns from recurring patterns (daily, weekly, or monthly) and smooths out the capacity curve before the load actually arrives.

CloudFront serves cached objects directly from edge locations that are geographically closer to viewers, so repeat requests for the same content are satisfied without contacting the origin server. This reduces the number of origin fetches and, consequently, the data transfer out of your origin, which is often the largest variable cost. Setting appropriate TTLs and cache policies (including honoring Cache-Control headers) maximizes cache hits and minimizes origin bandwidth usage.

Batching the small objects into larger files, such as 1 MiB objects, directly attacks the root cause because S3 bills every PUT request individually regardless of object size. One million 1 KB PUTs cost the same per-request as one million 1 MB PUTs, so consolidating 1,000 small objects into a single object reduces the number of PUT requests by 99.9%. This is the intended way to reduce per-request charges while retaining the same logical data, and it also lowers the overhead of managing millions of keys.

Spot Instances are the correct choice because they offer significant cost savings, up to 90% off On-Demand pricing, in exchange for the possibility of interruption with a two-minute warning. A batch processing job is typically fault-tolerant and can be designed to checkpoint progress or be reprocessed from the last saved state, making it an ideal Spot workload. Even if Spot capacity is reclaimed, you can automatically relaunch the instance or use AWS Batch to retry the job, so the job still completes every night at a fraction of the cost.

AWS Compute Optimizer is the correct service because it uses machine learning to analyze historical CloudWatch metrics—CPU, memory, network, and storage—and generates specific, right-sized recommendations for EC2 instances. It can suggest downsizing an instance family or size, or even terminating instances that are consistently underutilized, while estimating the monthly cost savings and performance risk. This granular, workload-specific analysis directly addresses the goal of identifying underutilized Amazon EC2 resources.

AWS Budgets lets you define a cost budget with a threshold and configure alerts that trigger when actual or forecast spend exceeds it, directly satisfying the requirement to be notified when costs cross a set limit. CloudWatch billing alarms alone cannot express budget thresholds.

Amazon RDS Performance Insights is the correct choice because it is a database performance tuning and monitoring feature specifically designed for RDS. It provides an interactive dashboard that visualizes database load, waits, and identifies the top SQL queries consuming resources. With Performance Insights, you can quickly detect bottlenecks, analyze query performance, and troubleshoot issues in real time, making it directly relevant to monitoring database performance.

Implementing RDS Read Replicas is an effective solution for high CPU utilization when the workload is read-heavy. Replicas are asynchronous read-only copies of the primary instance, and routing SELECT traffic to them offloads query processing and reduces CPU spent on reads on the primary. The primary still handles writes and synchronized reads, but by scaling out read capacity you can prevent CPU saturation without upgrading the primary instance. This approach also delivers cost efficiency because you can choose smaller replicas or a smaller primary rather than purchasing a larger single instance.

This is optimal because an S3 Lifecycle rule can automatically transition objects from S3 Standard, which is used during the 30-day active period when logs are written and frequently queried, to S3 Glacier Deep Archive, the lowest-cost storage class. Deep Archive is designed for long-term retention of rarely accessed data, offering 99.999999999% durability and a default retrieval time of 12 hours, which is acceptable for 7-year-old logs. This combination minimizes storage spend over the retention period while keeping the logs recoverable for compliance purposes.

A Spot Fleet is the correct choice here because it lets you request Spot Instances at a significantly lower cost while maintaining reliability with an On-Demand fallback. The nightly batch job is fault-tolerant, meaning it can restart or rerun if Spot capacity is reclaimed. If Spot capacity is unavailable or gets interrupted, the Spot Fleet automatically launches an On-Demand instance to ensure the job still completes, giving you a balance of cost savings and capacity assurance.

Amazon CloudFront serves as a content delivery network, caching responses at edge locations so repeat requests never reach the EC2 origin. This reduces the volume of data transferred directly from EC2 to the public internet and, for requests that do go to the origin, the AWS-to-CloudFront leg is free while CloudFront's egress rate is lower than EC2's standard internet data transfer rate. Offloading delivery to edge servers therefore both cuts total egress gigabytes and shifts remaining traffic to a cheaper pricing tier, directly lowering the monthly bill.

DynamoDB auto scaling uses CloudWatch metrics (ConsumedWriteCapacityUnits and ConsumedReadCapacityUnits) to automatically adjust provisioned capacity between configured minimum and maximum limits. This handles predictable spikes by scaling up in advance and reduces costs by scaling down during low usage, eliminating manual intervention. With a target utilization set (e.g., 70%), auto scaling maintains enough capacity to handle demand while avoiding overprovisioning.

AWS Compute Optimizer is a machine-learning-based service that analyzes your instance utilization (CPU, memory, network, and disk) over the previous 14 days or longer, and generates right-sizing recommendations that match instance type and size to actual workload requirements. By migrating to recommended smaller or more modern instance families, you eliminate over-provisioning and reduce monthly EC2 costs without degrading application performance, making it a direct and effective cost-optimization action.

Standard Reserved Instances for a 1-year term are the most cost-effective choice for a predictable, always-on fleet because they apply a significant hourly discount (up to 40% relative to On-Demand) while requiring no management overhead. By committing to a 1-year term with an All Upfront or Partial Upfront payment, you lock in that discounted rate for the entire year, directly reducing costs for steady-state usage without sacrificing reliability or capacity. This makes them the correct answer for an administrator tasked with trimming costs on a non-interruptible workload.

This lifecycle policy matches the access patterns: frequent access -> Standard-IA after 30 days, occasional access for next 60 days (still in IA), then rarely accessed -> Deep Archive after 90 days. Deep Archive is the lowest-cost storage option for long-term retention. Deleting after 7 years meets compliance. This is the most cost-effective configuration.

Switch to on-demand capacity mode: On-demand mode instantly accommodates usage spikes without requiring capacity planning or pre-provisioning. You pay per request, so there is no charge for unused provisioned capacity, making it highly cost-effective for unpredictable write traffic. It eliminates throttling errors because DynamoDB automatically scales write and read capacity to match your application's actual demand, even during sudden bursts.

CPU Utilization is a fundamental performance metric that shows the percentage of allocated EC2 compute capacity being consumed. Prolonged high CPU utilization indicates the application is compute-bound and may be reaching its processing limits, causing higher latency and reduced throughput. CloudWatch provides this metric by default, enabling quick identification of CPU bottlenecks. Setting alarms on CPU Utilization helps trigger scaling actions or performance tuning.

Spot Instances make unused EC2 capacity available at discounts of up to 90% compared to On-Demand prices, making them the cheapest option for fault-tolerant, stateless, or interruptible workloads. Because the workload is inconsistent and can accept interruptions, Spot's main risk (instances being reclaimed with a two-minute warning when EC2 needs capacity back) is not a blocker. You can launch and terminate Spot Instances elastically to match demand, and even use Spot Fleet triggers to replace reclaimed capacity, giving massive cost savings for this use case.

Increasing reserved concurrency to 1000 allows AWS Lambda to scale out to handle a high volume of SQS messages without throttling, as the event source mapping automatically exercises up to that concurrency. Setting a batch size of 10 instructs the SQS event source to deliver up to 10 records per Lambda invocation, reducing the total number of invocations and overhead while dramatically improving throughput. This is the recommended pattern for processing large SQS workloads in a serverless architecture.

Adding one or more Read Replicas in the same Region creates independent, actively readable database copies that serve SELECT traffic, leaving the primary free to handle writes. Because the replicas stay in the same Region, you avoid inter-Region data transfer charges, and you can select smaller instance classes for the replicas to closely match the read-only workload. This horizontal scaling approach is cost-efficient because you add capacity only for the traffic that needs it, and it also preserves the primary's performance for the write-heavy portion of the workload.

Amazon EC2 automatically publishes CPUUtilization to the AWS/EC2 namespace in CloudWatch Metrics, providing the data source for evaluation. A CloudWatch Alarm continuously compares the metric against a threshold over a specified period and transitions between OK, ALARM, and INSUFFICIENT_DATA states. When the alarm enters ALARM, it invokes an action that publishes a message to an Amazon SNS topic, which then delivers notifications through endpoints such as email, SMS, or HTTP. This is the standard, minimal pattern for metric-based alerting.

Standard Reserved Instances are ideal for a steady, predictable 24/7 workload because they offer the deepest discount, up to 72% compared to On-Demand, when you commit to a 1-year or 3-year term. You can choose All Upfront, Partial Upfront, or No Upfront payment options, which further optimize cash flow while locking in the lowest hourly rate for a specific instance family and region. For a workload that runs continuously without interruption, this commitment maximizes cost savings while guaranteeing capacity, making it the most economical choice.

Cost Explorer is the native AWS service for visualizing, understanding, and analyzing your costs and usage over time. It provides an interactive graph of daily, monthly, or yearly spend, with the ability to filter by EC2-specific attributes like instance type, purchase option (On-Demand, Reserved, Spot), or custom tags. This makes it the correct tool for monitoring EC2 cost trends, predicting future spending, and identifying what is driving your bill.

AWS Compute Optimizer uses machine learning to analyze historical utilization metrics — including CPU, memory, EBS volume I/O, and network throughput — over a 14-day period and delivers specific recommendations for right-sizing EC2 instances, Auto Scaling groups, and EBS volumes. It provides a projected monthly cost savings estimate and a performance risk score for each recommendation, helping you balance cost and performance. You can also enable enhanced infrastructure metrics for even more precise suggestions, making it the appropriate tool for rightsizing EC2 instances.

A mixed-instance Auto Scaling group with On-Demand and Spot Instances is cost-optimal because Spot Instances are available for up to 90% lower hourly price, and the target tracking scaling policy automatically adjusts the desired capacity based on a selected metric such as average CPU utilization, maintaining a baseline with On-Demand while absorbing traffic spikes with Spot. The ASG's capacity rebalancing feature monitors Spot interruption warnings and proactively launches replacement instances, making this an ideal, resilient and inexpensive solution for a fault-tolerant web tier.

A target tracking scaling policy works by setting a target value for a metric—such as average CPU utilization at, say, 60%—and Auto Scaling continuously reads CloudWatch alarms to add or remove instances, keeping the metric near that target. This approach is reactive and automatic, handling sudden traffic surges by launching instances and terminating idle ones when demand falls. It is the most cost-effective and hands-off option for variable web workloads.

Reserved Instances provide a significant hourly cost reduction over On-Demand pricing in exchange for a one- or three-year commitment, directly addressing the stem’s requirement to optimise costs. By purchasing Reserved Instances for the baseline capacity—the minimum number of instances always running—the company locks in lower rates for that steady-state workload while retaining On-Demand or Spot instances to handle any variable traffic spikes, thus preserving performance.

Enabling provisioned IOPS on the DB instance creates an io1/io2 storage volume with a fixed, predictable IOPS level, decoupling performance from burst balances. This gives consistent low-latency I/O for transactional workloads and avoids the variability of general-purpose SSD when sustained throughput is required. It directly addresses storage I/O performance, making it a correct configuration choice.

Transitioning objects to S3 Glacier Deep Archive after 90 days is correct because it directly addresses the long-term retention requirement while minimizing storage costs. After 90 days, the logs are almost never accessed, so the multi-hour retrieval time of Deep Archive is an acceptable trade-off for its extremely low per-GB price. Lifecycle policies can automatically move objects between storage classes based on age, and Glacier Deep Archive is the cheapest option for data that must be kept for years. This approach preserves the logs for compliance while using the most cost-effective storage class available.