CCNA Cost and Performance Optimization Questions

The bucket policy allows s3:PutObject only when the request is made over a secure transport, as captured by the aws:SecureTransport condition key. The AWS CLI uses the HTTPS endpoint by default, so the request's SecureTransport value is true and the Allow branch applies. Consequently the upload is authorized and completes successfully.

Reserved Instances should back the predictable baseline because they offer a substantial discount (up to 72% compared to On-Demand) for a commitment you know you will use, while On-Demand covers unexpected spikes without requiring a long-term contract. This combination minimizes cost on the steady-state load while retaining the flexibility to launch extra capacity at any moment, and it avoids the interruption risk of Spot for the mission-critical spikes.

Lambda allocates CPU power in direct proportion to the memory configuration, so increasing memory gives the function more compute capacity to execute faster. For CPU-bound or memory-intensive workloads, this can dramatically reduce execution time and prevent timeouts. Since Lambda billing is based on compute time, a shorter duration may actually lower overall cost, making memory tuning the primary lever for performance optimization.

Increasing the instance size to a larger type in the same family directly adds vCPUs and baseline CPU capacity, which helps absorb the workload being distributed by the ALB. For example, moving from one size to the next doubles the number of vCPUs and often increases network bandwidth, allowing the instance to process more concurrent requests without saturating the CPU. This vertical scaling approach correctly addresses the stated CPU-bound bottleneck.

Spot Instances deliver up to a 90% discount compared to On-Demand pricing because AWS sells spare EC2 capacity through a bidding market. Nightly batch jobs that can be interrupted and restarted or resumed are textbook use cases for Spot, especially with the EC2 Fleet or Spot Fleet using a capacity-optimized allocation strategy. To tolerate eviction, you can implement checkpointing in the job and set short max-price per instance-hour, letting AWS reclaim the instance mid-run without corrupting output. The ability to tolerate interruption is precisely why Spot minimizes costs over all other options for this flexible, interruptible workload.

S3 Intelligent-Tiering automatically monitors access patterns and moves objects between frequent, infrequent, and archive-instant access tiers, charging a small monthly monitoring and automation fee per object. Unlike a static lifecycle rule, it adapts to changing access without retrieval fees or operational overhead, making it ideal for data with unpredictable usage. However, it does not compress or deduplicate data, and you still pay for the storage class actually used, but it optimizes cost by minimizing manual tier choices.

An under-provisioned database can directly cause slow application responses while keeping EC2 CPU low because the application nodes spend most of their time blocked on database queries. Inadequate IOPS, insufficient memory for the buffer cache, or a suboptimal schema can lead to high query latency and connection queueing, which is not reflected in the web-tier CloudWatch CPU metric. The low average CPU is a classic sign of an external dependency bottleneck, making the database the most plausible root cause for the degraded user experience.

AWS Budgets is the correct service because it is specifically designed to track your actual and forecasted AWS cost and usage against a defined threshold and immediately send notifications when that threshold is exceeded. You can create a cost budget, set a fixed spending amount, and configure SNS-based alerts for both actual and forecasted spending, covering scenarios like the company's need to monitor a limit. It also supports actions to prevent overages, such as applying IAM policies or terminating instances. That native, proactive alerting capability is exactly what the scenario requires.

Intelligent-Tiering handles the unpredictable access pattern automatically. Objects accessed within 30 days stay in Frequent Access. Unaccessed objects move to Infrequent Access (40 percent lower cost). No retrieval fee ensures there is no cost penalty when an old file is accessed unexpectedly. The per-object monitoring fee is offset by storage savings for objects over 128 KB.

Spot Instances offer spare EC2 capacity at discounts of up to 90% compared to On-Demand, making them ideal for fault-tolerant, interruptible workloads like a nightly 2-hour batch job. If Spot capacity is reclaimed, the job can simply be restarted on another Spot Instance, and the short run duration minimizes disruption risk. The significant cost savings together with the workload's natural resilience to interruption make Spot the most cost-effective choice.

S3 Intelligent-Tiering is the correct choice because it automatically monitors access patterns at the object level and moves data between Frequent Access, Infrequent Access, and Archive Instant Access tiers without any retrieval fees or user action. This provides low-latency access for actively requested large files while silently reducing storage cost for objects that become cold. It is ideal for unknown, unpredictable, or changing access patterns because there is no static lifecycle rule to misjudge when data will be accessed again. A small monthly monitoring and automation fee per object applies, but it is typically negligible compared to the savings and avoids the risk of archive-tier retrieval delays.

Cost Anomaly Detection's ML model learns the historical spending pattern for each service. When EC2 (or any service) starts spending at an anomalous rate, the model detects it within hours. The alert subscription can notify via email or SNS with the anomaly amount, affected service, and percentage deviation. No manual threshold tuning is needed — the model self-calibrates.

The AWS Instance Scheduler is a reference solution that deploys AWS Lambda functions and Amazon DynamoDB tables via AWS CloudFormation to automatically issue EC2 StopInstances and StartInstances calls based on user-defined daily or weekly periods. It works by evaluating instance tags against stored schedules, supports time zones, and can handle large fleets across accounts and regions. Because it stops rather than terminates instances, EBS-backed volumes, private IP addresses, and instance IDs are preserved.

A mixed instances policy lets an Auto Scaling group launch both Spot and On-Demand Instances, with the ability to define a percentage split (e.g., 50% On-Demand and 50% Spot) across multiple instance types. Spot Instances can be 60–90% cheaper than On-Demand, so running a portion of the spike capacity on Spot delivers significant cost savings. The On-Demand portion maintains a stable baseline, while the Spot portion absorbs burst capacity; if Spot capacity is reclaimed, the group can optionally fall back to On-Demand, preserving availability and making this the most cost-effective, resilient choice for variable traffic.

VPC Gateway Endpoints for S3 are horizontally scaled, redundant VPC components that require no additional cost—they are free to use and carry no hourly or per-GB charges. When added to the route table, traffic destined for S3 is directed via prefix lists to stay inside the AWS network, bypassing the NAT Gateway for both data transfer and NAT processing fees. This directly cuts the most common source of S3-related cost overruns from EC2 instances in private subnets.

CloudFront caches the S3 static content at global edge locations, so users are served from nearby points of presence rather than the bucket's Region. This reduces latency and cuts data transfer costs by lowering origin fetches, satisfying both stated goals.

A target tracking scaling policy is the correct approach because it lets Amazon EC2 Auto Scaling automatically adjust the desired instance count to keep average CPU utilization near a predefined target value (e.g., 50%). CloudWatch alarms monitor the metric, and the policy scale out or scale in by incrementing or decrementing capacity based on the measured deviation from the target. This automated, reactive method handles peak load efficiently and reduces instances during low traffic, directly reducing costs without manual intervention.

Scheduled scaling allows you to scale the Auto Scaling group based on a schedule, such as increasing capacity at 8 AM and decreasing at 8 PM. Because the traffic pattern is predictable, scheduled scaling ensures that enough instances are running during peak hours and reduces cost by terminating unnecessary instances at night. This is the most cost-effective and performance-safe approach for a stateless application with known traffic patterns.

AWS Organizations is the correct answer because it provides consolidated billing, which automatically aggregates cost and usage data from all member accounts into a single payer account. This gives you a single monthly bill, enables Cost Explorer to analyze cross-account spend, and supports central cost allocation tags. It is the foundational service that allows you to see and manage costs across the entire AWS environment from one place, making it essential for central cost management.

EC2 publishes only infrastructure metrics such as CPU, network, and disk I/O by default; memory utilization is invisible unless the CloudWatch agent publishes a custom metric. By creating a custom metric like mem_used_percent and attaching a target tracking scaling policy, the Auto Scaling group continuously adjusts capacity to keep average memory utilization at a specified target (e.g., 70%). This correlates scaling decisions with the actual memory-bound workload, preventing both wasted running instances and performance degradation from memory exhaustion.

Increasing the minimum, maximum, and default TTL values instructs CloudFront to retain objects at edge locations for a longer period, so more requests are satisfied directly from the cache rather than going back to the origin. Longer TTLs mean that the same content remains fresh in the cache, directly increasing the cache hit ratio for popular objects. This is the appropriate way to improve cache efficiency, though you should balance longer TTLs against the need to serve updated content.

Using Amazon EventBridge Scheduler or the AWS Instance Scheduler solution, you can automate stopping the instance at the end of the business day and starting it again before the next workday begins. EC2 billing is per-second while the instance is in the running state, so stopping it during evenings and weekends eliminates most compute charges while retaining the EBS volumes, configuration, and data. The schedule ensures the environment is available when developers arrive and requires no manual intervention, directly matching compute spend to actual usage.

Resizing the DB instances to a smaller instance class is the correct approach because it directly reduces the per-hour compute cost that scales with instance size. By analyzing Amazon CloudWatch metrics such as CPUUtilization, FreeableMemory, and DatabaseConnections, you can confirm the current instances are over-provisioned and select a smaller class that still satisfies your workload's peak demand. This right-sizing action lowers the compute component of the RDS bill immediately without sacrificing performance.

Creating a VPC Gateway Endpoint for Amazon S3 adds a prefix list route that directs S3 traffic from private subnets directly to S3 without traversing a NAT gateway or the internet. This eliminates the per-gigabyte NAT data processing fee and internet data transfer charge while keeping traffic within the AWS network. The endpoint is horizontally scalable, highly available, and adds no hourly cost, so it has virtually no performance or operational impact.

Spot Instances are spare EC2 capacity sold at discounts of up to 90% compared to On-Demand pricing, but AWS can reclaim them with a two-minute warning. For fault-tolerant, stateless workloads that can endure interruptions, running on Spot Instances dramatically reduces compute spend without sacrificing performance. This makes Spot a primary cost-optimization lever for interruptible workloads.

Compute Savings Plans are the right choice for a mixed EC2 and Fargate environment because the hourly commitment automatically applies to eligible compute usage across EC2 instances, Fargate tasks, and Lambda functions within the chosen region. Unlike EC2 Instance Savings Plans, they do not lock you to an instance family or size, so you can change instance types or refactor to containers without losing the discounted rate. A 1-year or 3-year term with a commitment that matches steady-state spend yields significant savings over On-Demand.

A VPC gateway endpoint routes S3 traffic privately within the AWS network instead of through a NAT gateway or internet gateway, eliminating NAT data processing charges and internet data transfer for that traffic. This directly cuts the transfer costs the stem asks to reduce.

S3 Lifecycle policies are the correct, native mechanism to reduce storage costs by automatically transitioning objects to more cost-effective storage classes after a defined age, such as moving from S3 Standard to S3 Glacier Deep Archive after 30 days. Glacier Deep Archive offers the lowest per-GB storage price in S3, with retrieval times of up to 12 hours, making it ideal for rarely accessed, long-term retention data. You can define transitions based on object age, prefix, or tags, and also set expiration to delete objects, directly cutting ongoing storage spend.

An Application Load Balancer paired with an Auto Scaling group enables horizontal scaling: it distributes incoming traffic across multiple EC2 instances and automatically adjusts the fleet size based on demand. For stateful apps, ALB supports sticky sessions (session affinity) at the target group level, preserving user session data while still adding/removing instances. Because instances are added or removed dynamically, you pay only for the capacity you need, improving availability and cost efficiency.

AWS Cost Explorer is a native billing and cost management service that provides interactive charts and reports of AWS costs and usage over time. When cost allocation tags are activated and applied to resources, you can filter and group costs by tags such as department, giving each department its own spend report. It also supports forecasting and granular time-grain views, making it the correct choice for departmental cost reporting.

gp3 volumes provide a baseline of 3000 IOPS and 125 MB/s throughput for every volume, independent of size, and the per-GB price is roughly 20% lower than gp2. This makes gp3 both cheaper and more predictable for workloads under 3000 IOPS, as it does not rely on burst credits like gp2. Converting existing gp2 volumes to gp3 can be performed non-disruptively, and would reduce the running EBS cost while still exceeding the application's performance requirements.

Spot Instances are the optimal choice for this batch workload because they offer savings of up to 90% compared to On-Demand pricing, and the EC2 Spot service can reclaim the capacity with only a 2-minute interruption warning. Since the batch processing job runs only 3 hours nightly and is inherently fault-tolerant—it can be paused, checkpointed, and resumed—Spot interruptions are easily handled without significant downtime or data loss. This cost-benefit alignment makes Spot Instances the AWS-recommended purchasing model for non-critical, event-driven, or scheduled batch workloads that tolerate variable availability.

Implementing a read replica creates a separate RDS instance that uses asynchronous replication to maintain a copy of the primary database, and it has its own endpoint that can handle read traffic. By modifying the application to route SELECT queries to the read replica (and keeping write operations on the primary), you offload CPU-intensive read workloads from the primary instance, directly alleviating high CPU utilization. This is a proven pattern for read-heavy applications because it scales read capacity independently and is more cost-effective than scaling up the primary, as you only size the primary for write throughput.

Scheduled scaling actions are the correct approach for a workload with a known, predictable peak window because they proactively adjust the Auto Scaling group's desired capacity at the specified times, launching instances before traffic increases. This eliminates the delay that dynamic scaling can incur while waiting for metrics like CPU utilization to cross thresholds, ensuring capacity is available exactly when the peak begins. It also lets you scale back down after the window to avoid paying for idle resources.

S3 Glacier Deep Archive is the lowest-cost S3 storage class, offering a storage price of about $0.00099 per GB-month and a standard retrieval time of 12 hours or more. It is explicitly designed for long-term retention of data that is accessed at most once a year, such as regulatory and compliance archives. With a 180-day minimum storage duration and a retrieval fee structure, it perfectly matches the requirement for durable, long-term, low-cost archival.

Dedicated Instances run on hardware that is physically isolated from other AWS accounts, meaning there are no 'noisy neighbors' that can monopolize CPU, memory, or I/O resources. This single-tenant environment provides strong performance consistency and can also satisfy strict compliance or licensing requirements. For a critical application running on a fleet, this isolation ensures that the behavior of other customers cannot interfere with your instances, making it the correct choice.

DynamoDB Standard-IA (Infrequent Access) is a table class designed specifically for data that is read infrequently but still requires DynamoDB's single-digit millisecond latency and full durability. It reduces storage costs by roughly 60% compared to Standard, while adding a small per-GB retrieval fee that only applies when data is actually read. This makes it the ideal choice for historical data that is stored long-term and accessed occasionally, since the storage savings outweigh the modest retrieval charges.

Spot Instances operate using spare EC2 capacity that AWS makes available at a significantly reduced hourly rate—often up to 90% off On-Demand pricing. This is the best fit here because the nightly 2-hour batch is both short and fault-tolerant: if capacity is reclaimed, work can be re-queued or resumed without violating the batch window. You can further reduce interruption risk by using a Spot Fleet with multiple instance types and by implementing checkpointing so progress is saved between runs. The result is a dramatic cost reduction for a workload that would otherwise be idling and paying full price.

A target tracking scaling policy with the ALBRequestCountPerTarget metric is purpose-built for web workloads behind an ALB because it continuously adjusts capacity to maintain a specified target value (e.g., 1000 requests per instance), automatically creating and managing the required CloudWatch alarms and scaling activities. This policy responds directly to the metric that reflects actual user traffic per instance, so it scales out quickly when request volume increases and scales in when traffic decreases, significantly reducing idle instance capacity. AWS recommends this approach over CPU or memory based scaling for HTTP(S) applications because it aligns scaling with the real bottleneck—request throughput per instance.

Ensuring instances communicate using private IP addresses within the same VPC is the correct and most cost-effective approach. Traffic sent over private IPv4 addresses stays entirely inside the VPC, never crossing the internet gateway, so it is not subject to public internet data transfer rates. For instances in the same Availability Zone, this traffic is absolutely free; even across Availability Zones, the per-GB charge is only $0.01 each way, which is far cheaper than public IP or gateway-based alternatives.

Amazon Aurora Global Database replicates data across AWS Regions with a typical replication lag of under one second, allowing application reads to be served from regional read replicas. This dramatically reduces cross-region network latency for global users, making database reads fast regardless of user location. Configuring the Auto Scaling group with a target tracking policy based on Application Load Balancer request count per target directly aligns compute capacity with incoming traffic patterns, allowing the web tier to scale quickly during demand spikes without waiting for memory or CPU alarms to fire.

S3 Lifecycle rules automatically transition objects to lower-cost storage classes (e.g., from S3 Standard to S3 Standard-IA or S3 Glacier Deep Archive) based on age or other criteria. For logs that are accessed infrequently after 30 days and must be retained for years, a lifecycle rule is the most cost-effective way to automate the transition and expiration of objects while still meeting retention requirements.

DynamoDB Accelerator (DAX) is an in-memory cache that sits in front of your DynamoDB table, serving reads at microsecond latency by avoiding disk access and the complexity of managing a separate caching tier. As a justified correct answer, it directly addresses read latency for even the most frequently accessed items, offloading repeated read traffic from the table's provisioned capacity and reducing the time each request takes from the database engine itself.

A read replica is an asynchronous MySQL replica that continuously syncs changes from the primary and can serve read-only traffic, including SELECT queries and reporting workloads. By routing non-critical reads to the replica, the primary's CPU cycles are freed up for write operations, reducing overall CPU utilization on the primary instance. This is a cost-effective scale-out approach because you add a smaller replica instance rather than resizing the primary, and read replicas can be promoted or removed as demand changes.

Reviewing the slow query log is a direct diagnostic step because it captures SQL statements that exceed a configured execution-time threshold, allowing you to identify exactly which queries are problematic. Once identified, you can then add indexes, rewrite the query, or adjust parameters like work_mem (for PostgreSQL) to reduce execution time. This addresses the root cause of the performance issue rather than adding more resources to mask it.

Enabling CloudFront's automatic compression for compressible content (HTML, CSS, JavaScript, JSON, etc.) reduces the number of bytes sent to viewers when the request includes an Accept-Encoding header. Since CloudFront egress is billed per gigabyte delivered, compressing responses directly lowers the data transfer cost, often by 60-70%. It also improves latency and page load times, and it is a simple configuration change that does not require code changes or additional AWS services.

Stopping EC2 instances outside of business hours eliminates per-second compute charges while they are in the stopped state, while EBS volumes and their data persist. You can use AWS Instance Scheduler or Systems Manager Automation to codify the start/stop routine, ensuring instances are only running when needed. This approach directly targets idle compute waste without deprovisioning the environment.

Origin Shield adds a centralized caching layer in a specific AWS Region, so all CloudFront edge locations forward cache misses to that single regional endpoint rather than directly to your origin. This consolidates requests from multiple edges, dramatically improving the global cache hit ratio and reducing both the volume of origin requests and the data transfer from origin to edges—and because you pay less for data transfer and origin load, it directly lowers your cost. Origin Shield is an AWS-native feature purpose-built for this cost-reduction scenario.

Spot Instances let you bid for unused EC2 capacity at discounts of up to 90% compared to On-Demand pricing. AWS can reclaim that capacity with a two-minute interruption notice, but because this batch processing job is checkpointed and resumable, an interruption simply means restarting from the last saved state and continuing toward completion. This makes Spot the most cost-effective option for this workload, especially since the job is inherently fault-tolerant and runs only for short periods.

A lifecycle rule with the 'Incomplete multipart upload' action (e.g., days after initiation = 7) automatically aborts and deletes all parts of any multipart upload that was not completed due to network failure, timeout, or user cancellation. Because S3 bills for every stored part of an incomplete upload just like a full object, leaving these orphaned parts accrues storage costs indefinitely. Setting a 7-day expiration ensures orphaned data is removed without requiring manual intervention, directly reducing storage waste from failed uploads. This is a native S3 cost-control mechanism, not a data-protection feature.

This option is correct because Reserved Instances should cover the steady-state, baseline portion of the fleet at a significantly lower hourly rate, while On-Demand instances handle any demand above that baseline without requiring a long-term commitment. A target tracking scaling policy lets the Auto Scaling group proactively maintain a chosen metric, like average CPU utilization, by incrementally adjusting capacity as the actual load fluctuates. This hybrid approach keeps costs down and critically provides immediate elasticity for unpredictable spikes.

AWS Compute Optimizer is the correct choice because it is purpose-built for this exact need: it continuously analyzes EC2 instance utilization data—CPU, memory, networking, and EBS I/O—collected from CloudWatch (with optional managed or custom metrics). Using machine learning models, it generates actionable rightsizing recommendations that identify both cost savings and performance risks, often suggesting specific instance families or sizes (e.g., moving from m5.large to m6i.large). It also provides estimated monthly savings and reasons for each recommendation, which a sysops administrator can directly use to identify and optimize EC2 instances.

Amazon CloudWatch is the correct choice because it provides a comprehensive monitoring service for EC2 instances. CloudWatch collects and tracks metrics such as CPU utilization, network I/O, and disk activity, which can be visualized in dashboards and evaluated against thresholds. When these metrics breach predefined limits, CloudWatch can trigger Amazon Simple Notification Service (SNS) alarms to notify operators or initiate automated actions, making it the appropriate tool for performance monitoring and alerting.

The AWS Cost and Usage Reports (CUR) can be configured to deliver granular, hourly or daily line items to an S3 bucket in either CSV or Parquet format. CUR integrates natively with Athena, allowing you to create a table and run SQL queries over the data, making it the correct choice for multi-account cost analysis. The Parquet format is columnar and optimized for query performance, and CUR includes account-level dimensions for filtering across all linked accounts.

AWS Systems Manager is a hybrid operations service that uses the SSM Agent on managed instances to collect operational data, including inventory details and performance-related information, and can execute diagnostic commands such as CPU or memory checks via Run Command. It provides a central console for aggregating and viewing operational data across instance fleets, making it valid for monitoring performance, though its primary purpose is broader managed-instance operations rather than real-time metric storage.

A mixed instances policy in an Auto Scaling group lets you define an On-Demand base capacity plus Spot percentage for the remaining instances. This maintains baseline availability through On-Demand instances while using lower-cost Spot capacity to absorb unpredictable traffic spikes. Spot interruptions can occur, but the ASG automatically replenishes capacity, and you can configure instance rebalancing and termination handling.

Standard Reserved Instances require a 1- or 3-year commitment to a specific instance family and Region, and optionally an Availability Zone. In exchange, AWS provides a significant hourly discount (up to roughly 72% compared to On-Demand) plus a capacity reservation when you specify an Availability Zone. This makes them the most cost-effective and dependable choice for a stateless web app that has a predictable, steady baseline load and must remain consistently available.

A read replica in the same region is the most direct and cost-effective way to offload read traffic from the primary RDS MySQL instance. It uses asynchronous replication to keep a copy of the database and can handle a large number of SELECT queries, reducing the load on the source instance. Because it is in the same region, replication latency is low, and it also offers the benefit of being promotable to a standalone instance if needed for disaster recovery or migration scenarios.

Scheduled scaling is the correct approach for a predictable, recurring daily spike because it allows you to add capacity in advance and remove it afterward based on a schedule, without any manual intervention. You can configure the Auto Scaling group to increase the desired capacity at, for example, 1:30 PM to give new instances time to enter the InService state and start receiving traffic before the 2 PM spike, then decrease it at 4 PM to terminate unneeded instances. This directly balances performance and cost, and it integrates with CloudWatch metrics and ELB health checks to ensure the added instances are truly ready. It is the idiomatic AWS solution for traffic patterns that repeat on a known timetable.

Spot Instances offer access to spare EC2 capacity at discounts of up to 90% off On-Demand prices, which makes them the most cost-effective choice for a batch job that runs for only 3 hours every Saturday. The key trade-off is that Spot capacity can be reclaimed with a 2-minute warning, so the workload must be fault-tolerant—for example, using checkpoints or saving results to S3 and restarting on new Spot capacity. Because the job is batch-oriented and resumable, interruption is not a blocker; you can also use a Spot Fleet with multiple instance types and Availability Zones to improve the odds of maintaining capacity.

This lifecycle provides cost-optimized storage: S3 Standard for the first 30 days (frequent access), S3 Glacier Flexible Retrieval for the next 335 days (rare access, 12-hour retrieval acceptable), and S3 Glacier Deep Archive for the final 4+ years (extremely rare access, lowest cost). This minimizes overall costs while meeting retrieval requirements.

For a workload with a predictable baseline and only occasional spikes, on-demand capacity's per-request pricing leads to unnecessary cost during the sustained baseline. Provisioned capacity bills a fixed hourly rate per read/write capacity unit, and DynamoDB auto scaling adjusts the provisioned units based on target utilization (e.g., 70%), so you pay for the baseline plus a small margin instead of paying each time a request occurs. This approach significantly reduces costs when the baseline traffic is steady, as the auto-scaling can scale up during known spike windows and scale down afterward. Because the question highlights cost reduction for recurring spikes, this is the correct action.

Creating a read replica allows you to offload read traffic to a separate, dedicated instance, freeing the primary to handle writes. You can specify a smaller instance type for the replica, such as a db.t3.medium, because read replicas do not need to match the primary's size; this reduces cost while still providing the read scaling needed. This directly addresses the read-heavy workload without migrating or overprovisioning the primary.

AWS Instance Scheduler is a purpose-built solution that uses a CloudFormation stack and tags to automatically start and stop RDS instances on a defined schedule. It leverages Lambda functions and an Amazon DynamoDB state table to track and apply the schedule without requiring you to build a custom scheduler. This reduces compute charges during off hours while storage and backup costs continue, precisely matching the requirement for a business-hours-only database.

Scheduled scaling allows you to define a recurring or one-time schedule to adjust the desired capacity of an Auto Scaling group at a future time. Because the company's workload follows a predictable pattern (e.g., a morning peak), scheduled scaling can proactively add EC2 instances before the traffic arrives, eliminating the lag inherent in reactive methods. After the initial configuration, it runs automatically without manual intervention, making it the most efficient choice for a known, consistent demand curve.

Reserved Instances offer a significant hourly discount in exchange for a one- or three-year commitment, and a Standard RI is best suited for steady-state, predictable production workloads like this always-on web app. By paying all or part of the cost upfront, you can reduce the effective hourly price by up to 72% compared to On-Demand. Because the workload is constant, the utilization will easily justify the commitment, making this the optimal cost-optimization strategy.