Auto Scaling practice questions

Keep a fixed fleet of m6i.large instances in an Auto Scaling group with a higher minimum.

Why wrong: Incorrect. A higher minimum keeps capacity running even when the queue is empty, so idle cost remains high. It also does not provide the burst efficiency that queued, event-driven processing gives you.

Use Reserved Instances for the workers even though demand is highly bursty.

Why wrong: Incorrect. Reserved Instances work best for stable, predictable utilization. Bursty workers would leave committed capacity unused much of the time, which wastes money.

Process uploads only during a nightly window so the fleet looks busier.

Why wrong: Incorrect. Batch scheduling may reduce perceived complexity, but it increases latency and does not inherently reduce compute cost if the same amount of work must still be done.

Place the Auto Scaling group in only one subnet so instance launches are simpler.

Why wrong: Using only one subnet/AZ removes redundancy. An AZ outage would still take down capacity until manual action occurs.

Increase the target group deregistration delay to allow old instances to stay longer.

Why wrong: Changing deregistration delay affects connection draining, not capacity placement across AZs. It doesn’t create additional resilient instances.

Use a Network Load Balancer, but keep all subnets in a single Availability Zone.

Why wrong: Switching load balancer type doesn’t fix the root cause. If capacity is only in one AZ, failures will still impact the service.

On-Demand Instances only

Why wrong: On-Demand is flexible but usually more expensive for interruptible compute.

Dedicated Hosts

Why wrong: Dedicated Hosts are used for compliance/licensing needs and are more expensive.

Provisioned IOPS volumes

Why wrong: Provisioned IOPS affects storage performance, not compute purchasing cost.

Steady increase: Simple scaling

Why wrong: Simple scaling is inappropriate for steady increases because its fixed capacity adjustments and mandatory cooldown periods lead to inefficient resource management for gradual changes. It either over-provisions significantly after a single threshold breach or under-provisions during the cooldown, failing to smoothly match a steadily growing demand. This results in suboptimal cost efficiency and potential performance degradation over time.

Unpredictable bursts: Scheduled scaling

Why wrong: Scheduled scaling is unsuitable for unpredictable bursts because it relies entirely on pre-defined time-based rules, which cannot react to unforeseen or spontaneous increases in demand. Since it lacks real-time metric evaluation, it would fail to provision additional capacity when an unexpected burst occurs, leading to performance bottlenecks or service unavailability. This policy is designed for known patterns, not dynamic, real-time reactions.

Place all ECS tasks in a single subnet to minimize network latency.

Why wrong: Placing all ECS tasks within a single subnet severely compromises the application's fault tolerance and availability. While it might marginally reduce network latency between tasks, this configuration creates a single point of failure; an outage affecting that specific subnet or its Availability Zone would render the entire application inaccessible. Best practices for resilient cloud deployments mandate distributing resources across multiple subnets in distinct Availability Zones.

Store application session data in an attached EFS file system shared across all tasks.

Why wrong: Storing application session data in an attached EFS file system contradicts the principle of a stateless web application, which should not maintain session state on the compute layer. Furthermore, EFS is a shared file system primarily designed for persistent storage, not optimized for high-performance session management. For stateful applications requiring session persistence, external, highly available services like Amazon ElastiCache or Amazon DynamoDB are more appropriate and performant.

Disable automatic task replacement to avoid unnecessary task churn during failures.

Why wrong: Disabling automatic task replacement for an ECS service would severely undermine the application's resilience and availability. This critical feature ensures that unhealthy or failed tasks are automatically stopped and replaced with new, healthy ones, maintaining the desired task count and service capacity. Without automatic replacement, task failures would lead to a permanent reduction in application capacity and potential service outages, requiring manual intervention.

Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.

Why wrong: Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.

Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.

Why wrong: Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.

Keep the ASG in one subnet/AZ, but enable ALB stickiness to reduce session interruption.

Why wrong: Stickiness affects session routing but does not create targets in a second AZ during an AZ outage.

Add a NAT gateway in the public subnets so instances can reach the internet during maintenance events.

Why wrong: NAT affects outbound connectivity, not target placement or health during an AZ outage.

Create a second ALB in the same Availability Zone and route traffic using DNS failover.

Why wrong: DNS failover adds complexity and still depends on healthy targets; without multi-AZ instances, failover won’t help much.

Configure a larger ALB deregistration delay so that old targets remain longer before termination.

Why wrong: ALB deregistration delay affects how long existing targets are kept during scale-in events and connection draining behavior. It does not reduce the initialization/warm-up time of newly launched instances. If new instances cannot become healthy until warm-up completes, customers can still see 5xx responses during the initial minutes after scale-out.

Increase the number of desired instances immediately without using scaling policies, and then rely on manual reconfiguration.

Why wrong: Manually changing desired capacity can work in an operational sense, but it is not a direct improvement to application warm-up time, and it is not responsive/automated for demand variability. It also doesn’t solve the core issue: newly created instances still require the same warm-up duration before they pass ALB health checks.

Switch from ALB to NLB so instances become reachable sooner without waiting for health checks.

Why wrong: NLB does not inherently remove the application’s initialization requirement. While health check behavior differs by load balancer type (e.g., NLB often uses TCP-level checks), the application still needs time to become ready to handle requests successfully. Switching to NLB may change routing and health-check characteristics, but it does not directly address the ~4-minute warm-up bottleneck.

Set the ASG min capacity to 0 so instances can be recreated faster when an AZ recovers.

Why wrong: Lowering min capacity to 0 makes it more likely the ASG can run with too little (or no) capacity in the remaining AZ(s) when one AZ is down. That can increase request failures and performance issues until capacity scales back, and it does not guarantee the ALB can maintain sufficient healthy targets during the outage.

Increase the ALB idle timeout to 120 seconds to reduce connection drops.

Why wrong: Changing the ALB idle timeout affects long-idle TCP/HTTP connections, but it does not create additional healthy targets when one AZ is unavailable. If intermittent failures are driven by reduced capacity/instance count during the outage, idle timeout alone will not reliably fix the problem.

Disable health checks on the target group so instances are not deregistered during the maintenance window.

Why wrong: Disabling health checks prevents the ALB from removing unhealthy instances, which can increase error rates by routing to targets that are failing or overloaded. It also does not address the root resilience gap: insufficient AZ coverage in the ASG.

Leave the ASG attached to the previous Launch Template version so scale-out is stable.

Why wrong: Keeping an older Launch Template version prevents new instances from receiving updates. ASG scale-out should reflect the latest desired configuration. Stability is better handled by controlled version updates.

Manually SSH into each new instance and reconfigure it after it launches.

Why wrong: Manual configuration does not scale and introduces drift between instances. It also delays readiness and can cause inconsistent behavior during rapid scaling. Launch Templates are intended to automate instance configuration.

Move the configuration changes into a security group rule so the ASG updates them automatically.

Why wrong: Security groups control network access, not application configuration or runtime parameters. Putting configuration into security group rules is not an appropriate mechanism. ASG instance configuration is managed via Launch Template data.

Backup and restore only, relying on scheduled snapshots and manual restores during incidents.

Why wrong: Backup/restore can meet data-loss tolerance in some cases, but RTO of 1 hour is often too aggressive for manual restores.

Pilot light, keeping only minimal infrastructure in the secondary Region and starting full services after failover.

Why wrong: Pilot light is cheaper, but RTO of 1 hour may not be achievable if full compute/services must be brought up from near-zero.

Active/active, routing production traffic to both Regions continuously and accepting dual-region complexity.

Why wrong: Active/active best fits very low RTO and high availability, but it usually costs more than the stated budget constraints.

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

Why wrong: 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 wrong: Restricting tasks to one Availability Zone can reduce placement options and increase the likelihood of insufficient capacity. It may also reduce availability. It does not automatically trigger EC2 scale-out when tasks increase.

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

Why wrong: 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.

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

Why wrong: 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 wrong: Changing from ALB to NLB does not address the root cause: there is no instance capacity in other AZs. Without multi-AZ compute capacity, any load balancer cannot serve traffic during the AZ outage.

Add an Amazon SQS queue to buffer requests during failures.

Why wrong: 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.

All instances in one larger subnet

Why wrong: One AZ remains a single point of failure.

A Network Load Balancer in one subnet

Why wrong: A load balancer in one AZ does not make the application resilient to AZ failure.

A single EC2 instance with detailed monitoring

Why wrong: Monitoring does not provide redundancy.

Add more subnets across additional Availability Zones to distribute the same instances more widely.

Why wrong: Adding subnets/AZs increases fault tolerance, but it does not address the immediate cause of the outage: the target group (via ALB health checks) is marking instances unhealthy before the application is ready. The unhealthy/replace loop would still occur for each instance that starts during deployments.

Switch the load balancer target type from instance targets to IP targets to avoid health check failures.

Why wrong: Target type does not change application readiness. Even with IP targets, the ALB health check fails until the application starts responding on the configured health check path/port, so the Auto Scaling group would still see unhealthy targets and replace instances.

Reduce the ALB health check interval so unhealthy targets are removed faster.

Why wrong: Reducing the interval makes ALB detect failure conditions sooner. With a ~2-minute initialization time, this increases the chance that instances are marked unhealthy and replaced before they can become ready, making the problem worse rather than improving start-up resilience.

Increase the instance size to reduce CPU throttling risk

Why wrong: The metrics show sustained low CPU with no reported throttling risk. Increasing size would likely increase cost immediately without addressing an existing performance problem.

Switch the group to Spot Instances to reduce cost without changing instance sizing

Why wrong: Spot could reduce compute price, but it introduces interruption risk and additional operational complexity. When the primary waste is clearly overprovisioned capacity, downsizing is the more direct and lower-risk cost optimization.

Buy Reserved Instances with a long term commitment before making any sizing changes

Why wrong: Purchasing capacity commitments can reduce unit price, but it does not fix the cost waste from running much larger-than-needed instances. Since the instance utilization indicates overprovisioning, right sizing should come first to maximize savings with minimal risk.

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

Why wrong: 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 wrong: Restricting tasks to one Availability Zone can reduce placement options and increase the likelihood of insufficient capacity. It may also reduce availability. It does not automatically trigger EC2 scale-out when tasks increase.

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

Why wrong: 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.

Increase the t3.large maximum CPU credits and keep the Auto Scaling group using the same burstable instance type.

Why wrong: Increasing credits can reduce throttling for short or intermittent bursts, but t3 instances still depend on accumulated CPU credits. During sustained peak traffic, credits will deplete and the instance can throttle, so p95 latency predictability remains limited.

Add a placement group to the existing t3.large instances so they are packed close together for lower latency between nodes.

Why wrong: Placement groups can help certain network-oriented communication patterns by improving latency and/or bandwidth, but the observed symptom is CPU credit depletion on burstable instances. Changing placement does not address CPU throttling caused by credit exhaustion.

Switch the workload to run on Lambda with the same logic so invocations automatically scale without instance selection changes.

Why wrong: Lambda may scale automatically, but provisioned and on-demand execution characteristics do not inherently remove the underlying issue you observed (burstable CPU throttling on t3). For CPU-bound, latency-sensitive batch-like processing, moving to Lambda could introduce other constraints (cold starts, execution limits, concurrency dynamics) and does not directly target credit-based throttling as the root cause.

Increase the desired capacity in AZ-a so more instances can absorb the failure of that same Availability Zone.

Why wrong: Adding more instances in the same Availability Zone does not protect against an AZ-wide outage because all of those instances fail together.

Disable health checks so the ALB stops removing targets during brief infrastructure issues.

Why wrong: Disabling health checks hides failures instead of recovering from them. The load balancer would continue sending traffic to unhealthy targets, which makes the outage worse rather than better.

Move the application to a single larger instance type so the fleet has fewer moving parts.

Why wrong: A single larger instance increases concentration risk and does not remove the Availability Zone single point of failure. It reduces the number of instances, but it also reduces redundancy.

A VPC endpoint for CloudWatch only

Why wrong: A VPC endpoint changes network path, not instance capacity.

S3 Object Lock

Why wrong: Object Lock controls retention, not EC2 compute capacity.

Disable health checks

Why wrong: Disabling health checks weakens availability and does not improve capacity.