Auto Scaling practice questions

A VPC endpoint for CloudWatch only

Why it fails: A VPC endpoint for CloudWatch only alters the network path used by EC2 instances to reach CloudWatch APIs, enabling private traffic that avoids the public internet. It is a connectivity and security feature, not a capacity-management mechanism. Even with a private, low-latency path to CloudWatch, the instances' vCPU resources remain unchanged, so sustained CPU saturation on the existing fleet is not resolved. The endpoint would neither add instances nor relieve compute load, leaving the ALB backend still overwhelmed.

S3 Object Lock

Why it fails: S3 Object Lock is a data-protection feature that enforces a retention period on objects in Amazon S3, preventing them from being deleted or overwritten for compliance or legal hold purposes. It has no interaction with EC2 compute capacity, Auto Scaling, or the CPU utilization of an application server. Applying Object Lock to an S3 bucket neither increases the number of EC2 instances nor changes how the ALB distributes traffic, so it cannot alleviate high CPU load. This option is a distractor that confuses a storage governance control with a compute scaling solution.

Disable health checks

Why it fails: Disabling health checks on the Application Load Balancer would stop it from detecting unhealthy or overloaded EC2 instances, causing traffic to be routed to targets that may be failing or saturated. This would degrade availability and likely worsen perceived performance, as requests could be sent to instances that cannot handle them. Moreover, health checks are not a scaling control—they do not adjust instance count or CPU capacity. Removing them eliminates the ALB's ability to stop sending requests to impaired instances, so the existing CPU pressure on the fleet remains or increases.

Increase DesiredCapacity to 4 while keeping all instances in subnet-a1.

Why it fails: This adds more instances, but they are still all in the same Availability Zone. If us-east-1a fails, every instance is lost together and the application still goes down. Capacity is not the same as fault isolation.

Replace the Application Load Balancer with a Network Load Balancer.

Why it fails: A Network Load Balancer changes the load-balancing layer, but it does not fix the root problem: all instances are still in one AZ. If that AZ fails, there are still no healthy targets to receive traffic.

Enable EBS encryption on the launch template volumes.

Why it fails: Enabling EBS encryption on the launch template volumes encrypts data at rest, which protects the confidentiality of data stored on the volumes, but it has no impact on availability or failover behavior. The Auto Scaling group still launches all EC2 instances in subnet-a1 within us-east-1a, so if that Availability Zone experiences an outage, all instances and their encrypted volumes become unreachable simultaneously. Encryption is a security control, not a resilience mechanism; it neither introduces redundant compute in another zone nor changes the failure domain, and it does not alter how the load balancer routes traffic or how the ASG replaces unhealthy instances.

Keep scaling on CPU% to avoid over-scaling

Why it fails: CPU-based scaling can lag or fail when the bottleneck is not CPU saturation (for example, thread/connection limits, queueing, downstream dependency slowness, or ALB target response time). Your symptom already shows CPU is not the limiting factor.

Disable scaling and manually increase capacity during business hours

Why it fails: Disabling auto scaling and manually adjusting capacity during business hours trades elasticity for static provisioning, requiring accurate forecasts of peak traffic. In practice, web traffic can spike unpredictably from marketing campaigns, partner referrals, or viral content, so manual changes often leave the fleet either overprovisioned (cost waste) or underprovisioned (high p95 latency) outside the predicted window. It also introduces operational overhead and human delay, whereas Auto Scaling can react in minutes to changing demand.

Scale only when network packet drops fall below a threshold

Why it fails: Scaling only when network packet drops fall below a threshold focuses on a low-level infrastructure signal that does not reflect application-layer saturation. The p95 latency is driven by queued requests, blocked worker threads, or dependent service slowness, all of which can occur while packet drops remain near zero. Moreover, packet drops are often transient and caused by network bursts or security-group limits, so they can produce noisy or inverted scaling decisions that either over-provision or leave the app short-handed exactly when latency is rising.

Increase the Auto Scaling group's desired capacity to a higher number than required.

Why it fails: Raising desired capacity does not fix the underlying problem of instances being terminated before the application finishes starting. The ASG will still perform ELB health checks and mark any instance that fails the configured health check as unhealthy, even during startup, and will replace it. A larger fleet only hides the symptom by providing extra capacity, but it also increases cost and can lead to a continuous cycle of launching and terminating instances during provisioning.

Disable ALB target group health checks so instances are considered healthy as soon as they register.

Why it fails: Disabling ALB target group health checks does not stop the ASG from considering instances unhealthy; if the ASG health check type is ELB, it relies on the target group's health status, so disabling checks will cause the ALB to always report healthy, which prevents the ASG from detecting genuine application failures. Meanwhile, the ALB will still route traffic to instances that are still warming up, causing 5xx errors for users, because the target is considered healthy regardless of actual readiness. This is an anti-pattern that sacrifices correctness for a false sense of stability.

Change the Auto Scaling health check type from ELB to EC2 so the ALB will no longer determine instance health.

Why it fails: Even if EC2 status checks pass, the application may still not be ready. The instance can remain in service while still causing failed requests, and the ASG will not use ALB readiness to enforce correct routing behavior.

A single EC2 instance with detailed monitoring

Why it fails: Detailed monitoring with CloudWatch (1-minute metrics) only increases the frequency of metric collection and alarms; it has no effect on fault tolerance or instance replacement. A single EC2 instance still resides in one Availability Zone, so an AZ outage, hardware failure, or maintenance event terminates the instance and takes the dashboard offline until manual intervention or a separate recovery mechanism acts. Detailed monitoring can help you react faster to performance issues, but it cannot restart, replace, or relocate the instance, leaving the application with a single point of failure.

All instances in one larger subnet

Why it fails: Expanding a subnet to include more IP addresses does not change the underlying physical location; a subnet exists entirely within a single Availability Zone. If all EC2 instances are launched into that one larger subnet, they all share the same AZ, so any failure of that AZ—power loss, network partition, or cooling failure—takes every instance down simultaneously. Larger subnets only provide more capacity for launching instances, not geographical or fault-domain diversity, and therefore do not address availability or redundancy requirements.

A Network Load Balancer in one subnet

Why it fails: A Network Load Balancer (NLB) is a regional service that can route traffic to targets across multiple AZs; however, if the NLB itself is placed in a single subnet (single AZ), it becomes a single point of failure at the network layer. Even if the backend instances are in multiple AZs, an AZ failure that includes the NLB's subnet will make the load balancer unreachable, and the entire application loses connectivity. NLB nodes must be deployed in at least two AZs—or the NLB must automatically have a node in each enabled AZ—to provide high availability; simply having a load balancer in one subnet adds a dependency that defeats resilience.

Increase the ASG desired capacity so that extra instances absorb the failed ones.

Why it fails: Raising the desired capacity only launches more instances; it does not alter the Auto Scaling group's health check type, which remains EC2 status checks that pass because the OS and hypervisor are healthy. The application's HTTP 500 response occurs at the endpoint level, so the extra instances would either also return 500 and remain in service, or at best mask the symptom without removing the failing instances. This action neither detects the application failure nor triggers replacement.

Replace the Application Load Balancer with a Network Load Balancer to improve failover speed.

Why it fails: A Network Load Balancer operates at Layer 4 and its health checks only verify TCP connectivity, not HTTP response codes such as the 500 shown by the application's health endpoint. Replacing the ALB with an NLB would therefore still report the instance as healthy, and the ASG's default EC2 health checks would also continue to pass. This change alters the traffic layer but leaves the actual detection and replacement mechanism unchanged.

Increase the HealthCheckGracePeriod to the maximum value so the instances have more time to stabilize.

Why it fails: The health check grace period applies only after an instance is launched, delaying the start of health checks so a new instance has time to stabilize; it has no effect on instances that are already running and returning HTTP 500s. The exhibit shows a steady-state failure, not a boot-time issue, so increasing this value to the 3600-second maximum would only postpone evaluation of new replacements, leaving the current unhealthy instances untouched. It also does not change the health check type from EC2 status checks to ELB, so application failures remain invisible.

A single EC2 instance with detailed monitoring

Why it fails: Detailed monitoring (CloudWatch metrics at 1-minute frequency) only provides visibility into CPU, memory, and status checks; it does nothing to replace an instance that fails. A single EC2 instance is a single point of failure — if its underlying host crashes or its Availability Zone goes down, the dashboard becomes unreachable despite having monitoring enabled. Even with an EC2 Auto-Recovery alarm, the instance is restarted on a new host in the same AZ and will be down for minutes, and it still cannot survive an AZ-wide failure.

All instances in one larger subnet

Why it fails: A subnet is always contained within one Availability Zone; making a subnet 'larger' by expanding its CIDR does not change its zone boundary. Placing all instances in a single large subnet means they all share the same physical infrastructure and same failure domain. If that AZ suffers a loss of power or network connectivity, every instance goes down together — increasing instance count or subnet size provides zero additional resilience.

A Network Load Balancer in one subnet

Why it fails: A Network Load Balancer in a single subnet is bound to exactly one Availability Zone and has a node only in that zone. If that AZ fails, the NLB endpoint becomes unreachable and it cannot forward traffic, even if backend instances in other AZs are healthy (and in this design there are no other configured target AZs anyway). Health checks on the NLB help route around unhealthy instances, but they cannot help when the load balancer's own single node is down — the NLB must itself be enabled in multiple AZs (subnets) to be resilient.

Enable termination protection on the EC2 instances and configure an Elastic IP address per instance so that clients can reconnect to the same address after a zone failure.

Why it fails: Termination protection only blocks accidental instance termination; it does nothing when an Availability Zone itself is impaired. Elastic IP addresses are Regional and can be remapped, but clients are connecting to the load balancer endpoint, not to instance addresses, so this design neither preserves the endpoint nor provides running capacity in a second zone.

Replace the Network Load Balancer with an Application Load Balancer deployed in one Availability Zone and attach an Auto Scaling group with a desired capacity of two instances.

Why it fails: An Application Load Balancer is also a Regional resource, but keeping the Auto Scaling group in a single Availability Zone means the workload still has no capacity in a second zone, so a zone failure still takes down every instance. This option changes the load balancer type and its DNS name, which also violates the requirement that clients keep using the existing API endpoint.

Create a second Network Load Balancer in a different Availability Zone and use Amazon Route 53 weighted routing to send half the client traffic to each load balancer.

Why it fails: A second Network Load Balancer in another zone does not protect the instances, which remain in one zone, and weighted routing does not automatically withdraw a failed endpoint from DNS. Weighted records keep resolving to the failed load balancer until health checks and TTL expire, and clients would also need to tolerate two different endpoint names, which the scenario forbids.

All instances in one larger subnet

Why it fails: Even if the subnet is large (i.e., has many IP addresses), all instances reside within a single Availability Zone. An AZ failure, such as a power outage or network partition, would take down every instance in that subnet, making the system unavailable. Scaling by adding more instances within the same AZ does not provide redundancy against AZ-level failures; it only adds capacity within a failure domain.

A Network Load Balancer in one subnet

Why it fails: The NLB itself is a single point of failure when placed in only one subnet/AZ. If that AZ fails, the NLB becomes unreachable, and all traffic to the application is lost, regardless of how many EC2 instances are running behind it. A properly designed NLB should be placed in multiple subnets across AZs, or use an Application Load Balancer that is inherently multi-AZ, to ensure the load balancer itself survives an AZ outage.

A single EC2 instance with detailed monitoring

Why it fails: Detailed monitoring (CloudWatch metrics at 1-minute frequency) only provides better visibility into the instance's health, but it does not provide any redundancy. If the instance fails, no automatic replacement occurs, and the ticket booking system remains down until manual intervention. There is still a single point of failure in both compute and the AZ.

Place the instances in a single subnet and increase the instance size.

Why it fails: Collapsing all instances into a single subnet means they reside in one Availability Zone, so an AZ outage takes the entire web tier down; increasing the instance size only adds vertical capacity within that same failure domain. A larger instance is still a single fail point and can be terminated or become unhealthy, and without an Auto Scaling group or load balancer, there is no mechanism to replace it or distribute traffic. This approach sacrifices the horizontal elasticity and fault isolation that a multi-AZ Application Load Balancer plus Auto Scaling group design provides.

Use a network ACL to detect failed instances and restart them.

Why it fails: A network ACL is a stateless VPC-level firewall that filters traffic entering or leaving a subnet; it has no visibility into instance health, no ability to communicate with EC2 or the orchestration layer, and cannot initiate a restart of a failed instance. It simply allows or denies packets based on rules, so it never detects process failures or triggers recovery for the web tier. This is a network security control, not a resilience mechanism.

Store the web servers on EBS volumes so the data survives failures.

Why it fails: EBS volumes provide durable block storage, but attaching them to EC2 instances does nothing to detect an unhealthy instance, replace it, or reroute traffic; a web server process crash or instance failure leaves the application down even if its disk data is intact. In fact, a stateless web tier should treat compute as disposable and offload session state to external stores such as ElastiCache or S3—relying on EBS to survive failures does not restore service. Additionally, an EBS volume is confined to one Availability Zone, so it cannot provide cross-zone failover when the instance fails.

Reserved capacity for maximum daily traffic

Why it fails: Reserved capacity (formerly reserved capacity) locks you into a minimum level of provisioned throughput for a 1-year commitment, with a reduced hourly rate in exchange for that fixed spend. In a dev sandbox with long idle periods, that commitment is wasted every minute the table is unused, because you pay for capacity regardless of actual traffic. It also cannot scale down to zero to match the unpredictable, idle-heavy workload, making it a poor fit for this scenario.

Provisioned capacity set for peak traffic

Why it fails: Provisioned capacity set for peak traffic forces you to pay a fixed per-hour rate for the peak read/write capacity needed only during the busiest moments, while the table sits idle for the rest of the time. This creates the classic cost-inefficiency problem: you are paying for capacity you do not actually consume. Furthermore, if traffic unpredictably exceeds that peak value (even briefly), DynamoDB will throttle requests and return errors unless you also enable auto scaling, which still has a minimum threshold and cannot eliminate the idle waste.

Global tables in every Region

Why it fails: Global tables in every Region replicate the DynamoDB table across multiple AWS Regions to provide low-latency reads and disaster recovery, but they also add per-Region storage and cross-Region replication write costs for every item change. Selecting this option would not address the idle-capacity waste at all; instead, it would multiply the cost by the number of Regions and introduce additional operational complexity. Since the workload is a dev sandbox that does not require multi-Region access or high availability, this option is both irrelevant and counterproductive.

Increase provisioned concurrency to 100 so that cold starts never occur, regardless of traffic patterns.

Why it fails: Setting provisioned concurrency to a fixed 100 means you are billed for 100 initialized environments around the clock, even when no requests arrive during low-traffic periods. This creates significant idle cost without solving the actual problem, because any spike beyond 100 concurrent invocations will still trigger cold starts for the extra executions. Moreover, a static value ignores the predictable timing of campaign windows, so you pay for capacity even when it is not needed instead of aligning cost with demand.

Turn provisioned concurrency off permanently and rely on retries at the client side to mask cold starts.

Why it fails: Disabling provisioned concurrency reintroduces cold starts for every new execution environment, and client-side retries do not remove the initialization delay—they only send the request again after a timeout, which degrades user experience and may cause duplicate processing. During a spike, the Lambda service has to initialize many new environments at once, and you can hit regional burst concurrency limits, leading to throttling errors that retries will only amplify by adding more load. This approach trades latency guarantees for cost savings, which is the opposite of what a latency-sensitive API requires.

Replace Lambda with a single always-on EC2 instance sized for peak demand to eliminate cold starts.

Why it fails: Replacing Lambda with a single always-on EC2 instance sized for peak demand means you pay for compute capacity continuously, even when traffic is near zero, which is usually more expensive than paying only for Lambda invocations. That instance is also a single point of failure: if it fails or needs patching, the API goes down completely, and it cannot handle traffic beyond its fixed size without you manually intervening. In contrast, scheduling provisioned concurrency on Lambda gives you the same low-latency behavior during spikes while preserving the serverless benefits of automatic scalability and no idle cost.

Increase the desired capacity in the existing Availability Zone to handle all traffic during an outage.

Why it fails: Raising the desired capacity within the current single Availability Zone merely adds more instances that share the same failure domain. When that whole AZ becomes unavailable—due to power loss, network disruption, or other zone-level events—every one of those instances, regardless of count, goes down together. There is no independent infrastructure remaining to accept traffic, so this approach cannot preserve availability during an AZ outage.

Enable longer ALB health check intervals so failing instances are detected more slowly.

Why it fails: Lengthening health check intervals makes the ALB less responsive at detecting an already-failing instance, but it does not create any redundant compute capacity elsewhere. In fact, slower health checks delay the Auto Scaling group's ability to replace unhealthy instances, extending the period of reduced availability. This change only alters detection timing; it does not address the fundamental dependency on a single AZ for both the load balancer and the instances.

Switch from the ALB to an Internet Gateway so instances can fail over to the public internet.

Why it fails: An Internet Gateway (IGW) is a horizontally scaled, redundant network component that simply provides bidirectional routing between a VPC and the public internet. It does not perform load balancing, does not evaluate target health, and has no concept of application-level failover between compute instances. Replacing the ALB with an IGW would actually remove the only mechanism that can route requests to healthy instances across multiple AZs, thereby guaranteeing that an AZ outage takes down the application.

Increase desired capacity to 2x so utilization increases and instances become “more efficient.”

Why it fails: Increasing desired capacity to 2x simply launches additional instances, which multiplies compute costs for a workload that is already underutilizing its current instances. The hypothesis that higher utilization means 'more efficient' confuses efficiency with artificially inflating activity; spreading the same load across twice the instances would actually reduce per-instance CPU utilization further, not improve it. This action increases total infrastructure cost and fails to address the underlying overprovisioning, making it the opposite of the optimal cost-optimization move.

Disable Auto Scaling so the group never scales down to preserve baseline performance.

Why it fails: Disabling Auto Scaling would remove the group's ability to terminate unnecessary instances during low-demand periods, locking in wasted spend on idle capacity. While a static size might preserve baseline performance, it sacrifices the elasticity that keeps infrastructure aligned with actual demand, and the scenario indicates consistent low utilization—so a smaller, right-sized instance type (not disabling scaling) is the better remedy. Moreover, disabling scaling also reduces fault tolerance because the group can no longer self-heal or respond to spikes without manual intervention.

Switch the workload to Spot instances immediately to avoid On-Demand charges, regardless of interruption risk.

Why it fails: Spot Instances can offer significant discounts, but they come with a two-minute interruption warning when EC2 reclaims capacity, making them unsuitable for workloads without fault tolerance or checkpointing. The scenario provides no evidence that this application is interruption-tolerant or stateless, so a blanket switch immediately exposes it to availability risks. Right-sizing the On-Demand fleet based on observed utilization is a safer, more appropriate first cost-optimization step; Spot should only be considered after confirming the workload can handle interruptions.

Tune the container health check settings so tasks stop failing and stay running.

Why it fails: Health checks affect task readiness and replacement behavior, but they don’t create more EC2 capacity. If no container instances are available, tasks still cannot be placed. Scaling container health checks alone won’t address placement delays.

Pin all tasks to a single Availability Zone to reduce placement overhead.

Why it fails: Pinning tasks to one Availability Zone reduces resilience and does not accelerate EC2 scale-out when tasks queue for capacity. It is tempting because placement overhead sounds like the bottleneck, but the actual constraint is insufficient cluster capacity, addressed by a capacity provider with managed scaling.

Switch the tasks to run only on Fargate so EC2 scaling is no longer relevant.

Why it fails: Migrating to Fargate changes the compute model but is not the best first step for optimizing current ECS-on-EC2 placement latency. The question asks about faster EC2 scale-out when tasks increase. Using ECS capacity provider integration is the targeted fix.

AWS Config

Why it fails: AWS Config is a governance and compliance service that records resource configuration changes, maintains configuration histories, and evaluates resource settings against rules. It does not index application document content or expose a text search API; its data is metadata about AWS resources, not the unstructured text used for full-text search.

Amazon EFS

Why it fails: Amazon EFS provides a scalable, POSIX-compliant network file system for Linux workloads, typically used as shared storage for EC2 instances or containers. While EFS holds files, it offers no built-in indexing, tokenization, or query engine to perform full-text search over that content; you would need a separate service like OpenSearch to index and query the stored documents.

Amazon SQS

Why it fails: Amazon SQS is a fully managed message queuing service designed for decoupling application components and enabling asynchronous processing. Messages in SQS are transient and not indexed or searchable; it has no capability to store document collections or execute text search queries, so it cannot satisfy full-text search requirements in any way.

Keep the ASG in one Availability Zone, but reduce ALB health check intervals.

Why it fails: Reducing health check intervals only changes how quickly the ALB marks targets unhealthy. It does not create capacity in other AZs, so the ALB still has no healthy instances to route to when the only ASG AZ fails.

Switch the load balancer from an ALB to an NLB to remove HTTP health check dependency.

Why it fails: An NLB still relies on the same single-AZ subnets, so the AZ outage persists; swapping listener type does not add subnets. NLB suits TCP/UDP workloads needing static IPs or extreme throughput, not HTTP resilience. The fix is adding subnets in a second AZ to the ASG.

Add an Amazon SQS queue to buffer requests during failures.

Why it fails: A queue can help with asynchronous work, but a typical web request/response path still requires immediate compute capacity to accept and handle requests. Queueing does not eliminate the loss of in-AZ instances when the only ASG AZ fails.

Reduce the ALB health check timeout to 1 second so failures are detected faster.

Why it fails: Reducing the ALB health check timeout to 1 second makes the health check overly sensitive to transient network latency and slow application startup. The ALB will often mark instances unhealthy due to a single slow response, causing Auto Scaling to terminate instances that are still initializing. This accelerates instance churn rather than solving the problem, because the grace period, not the health check speed, is what protects instances during boot.

Enable connection draining on the ALB target group but set deregistration delay to 0 seconds.

Why it fails: Connection draining with a deregistration delay of 0 seconds disables the feature entirely, since the ALB will immediately close all connections when an instance deregisters. Even if draining were enabled, it only affects instances being intentionally deregistered, not instances being terminated by Auto Scaling because they failed health checks. The issue here is premature replacement due to missed grace period, which connection draining cannot address.

Switch the ALB target group health checks from HTTP to TCP so the application does not need to return HTTP 200.

Why it fails: TCP health checks only verify that the listener port accepts a TCP connection, not that the application can actually serve HTTP requests. During startup, the web server may be listening before it is ready to handle traffic, so TCP checks can mark the instance healthy prematurely and send production traffic to an unprepared instance. This increases the risk of user-facing errors and still does not fix the fundamental mismatch between the instance launch time and the Auto Scaling group's health check grace period.

Use a fixed-size Auto Scaling group and increase capacity manually once per hour.

Why it fails: A fixed-size Auto Scaling group with manual hourly adjustments requires an operator to predict future load and act proactively, but a stateless web API can experience sudden traffic spikes at any time. Between hourly checks, a surge of requests will saturate the existing instances, causing degraded response times and rejected connections until the next manual change. This approach lacks any automated feedback loop and cannot adapt to real-time demand.

Scale based only on EC2 instance memory utilization, regardless of load.

Why it fails: For a stateless web API, memory utilization often remains flat because no session state is stored locally, so it does not reveal CPU saturation, request queue depth, or user-facing latency. Scaling solely on memory would ignore the actual bottleneck—compute capacity for processing requests—and could leave the fleet under-sized during CPU-intensive spikes. Additionally, if instances have ample memory but are CPU-bound, the scaling policy will never add capacity when it is most needed.

Use step scaling with a single threshold on average network-in bytes.

Why it fails: Step scaling with a single threshold on average network-in bytes is a poor proxy for application load because API request bodies are often small, while responses and processing demands are not captured by network-in. A single threshold only triggers one level of adjustment, which can be too coarse to counter a rapidly growing queue, and network-in metrics tend to lag behind CPU or request-rate spikes. This can lead to either over-provisioning for bulk uploads or under-provisioning for many small requests.

Buy EC2 Spot Instances for the Auto Scaling group to maximize savings

Why it fails: Spot Instances can deliver substantial discounts, often 60-90% off on-demand, but AWS can reclaim them with a two-minute warning when it needs the capacity elsewhere. A production API with steady 24/7 demand is not fault-tolerant to interruption, and relying exclusively on Spot would create serious availability risk. Even with a diversified Spot allocation strategy, the workload still needs a reliable baseline, so this option is wrong for maximizing savings on a critical always-on service.

Purchase Reserved Instances that are limited to a single specific instance type in the Auto Scaling group

Why it fails: A standard Reserved Instance commits you to a specific instance family and can provide strong discounts, but the benefit only applies when the Auto Scaling group launches instances that exactly match that family, size, and scope. If the group uses different instance families or you later change the launch template to a newer generation, the reservation becomes idle and loses value. For a region-based ASG that may rebalance across multiple instance types, this rigidity is the wrong contrast to the flexible, dollar-per-hour compute pricing of a Compute Savings Plan.

Use on-demand only, and rely on Auto Scaling to reduce cost during low utilization

Why it fails: Running entirely on on-demand instances is the most expensive option for predictable, high-utilization workloads because there is no lower tier for committed usage. Auto Scaling only reduces spend when there is low utilization, but a production API with steady 24/7 demand never experiences that contraction, so you would be paying the full on-demand price around the clock. A Savings Plan or Reserved Instance is designed specifically to lower the hourly cost of that always-on baseline, making this approach weak for cost optimization.