Cloud / AWS Auto Scaling Interview questions

AWS Auto Scaling is a set of capabilities that automatically adjusts the capacity of your AWS resources to match demand. For EC2 workloads this is done by Amazon EC2 Auto Scaling, which adds or removes instances in a group as load rises and falls.

You define a minimum, maximum, and desired number of instances, plus rules that say when to change that number. AWS then launches or terminates instances for you and replaces any that fail health checks.

The same idea also applies beyond EC2 through Application Auto Scaling, which handles resources like ECS services, DynamoDB tables, and Aurora replicas.

The result is better availability during spikes and lower cost during quiet periods, without anyone watching dashboards.

An Auto Scaling group (ASG) is the logical collection of EC2 instances that Auto Scaling manages as a single unit. Every instance in it is launched from the same template, and the group keeps the instance count within the limits you set.

An ASG is defined by a few core settings:

• Launch template that describes what to launch (AMI, instance type, security groups, and so on)
• Subnets that decide which Availability Zones are used
• Min, max, and desired capacity
• Optional load balancer target groups and scaling policies

If an instance dies, the group notices and launches a replacement to get back to the desired capacity.

The main benefit is that capacity follows demand automatically, so you stop guessing how many servers you need.

• Availability: unhealthy instances are replaced and instances are spread across multiple Availability Zones.
• Cost control: you scale in when traffic drops, so you pay for fewer instance hours.
• Performance: new instances come up before users feel the slowdown.
• Less manual work: no one has to launch or terminate instances by hand.
• No extra charge: EC2 Auto Scaling itself is free; you pay for the EC2 and CloudWatch resources it uses.

It also pairs naturally with Elastic Load Balancing, so new instances start receiving traffic as soon as they are healthy.

A launch template stores the settings an Auto Scaling group needs to launch an EC2 instance, so every new instance comes up configured the same way.

Typical contents include the AMI ID, instance type, key pair, security groups, IAM instance profile, EBS volume settings, user data, and metadata options such as IMDSv2.

Launch templates are versioned. You can create version 2 with a new AMI, then point the ASG at it (or at $Latest or $Default) without rebuilding everything. They also support newer features such as mixed instance types, Spot options, and attribute-based instance selection, which is why AWS recommends them over launch configurations.

EC2 Auto Scaling supports four ways of changing capacity:

Dynamic scaling itself has three policy styles: target tracking, step, and simple scaling. Most teams start with target tracking and add scheduled or predictive scaling when traffic has a clear rhythm.

These three numbers control how many instances the group runs.

• Minimum: the group never goes below this, even if load is zero.
• Maximum: the group never goes above this, even under heavy load. It acts as a cost safety net.
• Desired: the number the group tries to maintain right now.

Scaling policies change the desired value, always staying inside the min and max range. If you set desired to 4 with min 2 and max 6, the group launches or terminates instances until it has exactly 4. Setting desired outside the min-max range is rejected.

Dynamic scaling changes group capacity automatically in response to live CloudWatch metrics such as CPU utilization, request count per target, or a custom metric.

You attach a scaling policy to the group. When the metric crosses a threshold (or drifts from a target value), Auto Scaling raises or lowers desired capacity. The policy types are:

• Target tracking: keep a metric near a target, like 50% average CPU.
• Step scaling: add or remove different amounts depending on how far the alarm is breached.
• Simple scaling: one adjustment per alarm, followed by a cooldown.

It handles surprises well, but it reacts after load changes, so there is always a short lag while instances boot.

Scheduled scaling changes the min, max, or desired capacity at specific times, so capacity is ready before a known load change.

You create a scheduled action with either a one-time date or a recurring cron expression, and you can set a time zone. For example, raise the minimum to 10 at 8:30 AM on weekdays and drop it back to 2 at 7 PM.

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg \
  --scheduled-action-name weekday-morning \
  --recurrence "30 8 * * 1-5" \
  --time-zone "America/New_York" \
  --min-size 10 --desired-capacity 10

It works well for marketing launches, batch windows, and office-hours apps, and it can run alongside dynamic scaling policies.

Predictive scaling uses machine learning to study your group's past load and forecast future demand. It then schedules capacity ahead of the forecasted spike instead of waiting for a metric to breach.

It needs at least 24 hours of metric history and works best for traffic that repeats daily or weekly, such as business-hours web apps. Forecasts look ahead 48 hours and are refreshed regularly.

It has two modes:

• Forecast only: generates forecasts so you can review them, but changes nothing.
• Forecast and scale: actually launches instances based on the forecast.

Predictive scaling is usually combined with dynamic scaling, which still handles unexpected spikes.

A target tracking policy keeps a chosen metric close to a target value, the way a thermostat holds a room temperature. You pick the metric and the target, and Auto Scaling does the math.

Predefined metrics include ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut, and ALBRequestCountPerTarget. You can also use a custom metric.

Behind the scenes it creates and manages the CloudWatch alarms for you, so you should not edit them. It scales out quickly when the metric is above target and scales in more cautiously when it is below, to avoid flapping.

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu50 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'

A cooldown period is a pause after a scaling activity during which a simple scaling policy cannot trigger another one. It gives the new instances time to start and take load before the group decides whether more capacity is needed.

The default is 300 seconds, and you can set it for the whole group or override it for a single policy. Without it, a metric that is still high while new instances are booting could trigger repeated scale-outs and leave you with far more capacity than needed.

Target tracking and step scaling do not rely on cooldown. They use instance warmup instead, which is a more precise way to handle the same problem.

Health checks let the group decide whether an instance is fit to serve. When an instance is marked unhealthy, Auto Scaling terminates it and launches a replacement.

Several health check sources exist:

• EC2 status checks: the default. They catch hardware or hypervisor level failures, not a crashed web app.
• ELB health checks: optional. They use the load balancer's HTTP/HTTPS checks, so they detect application-level failures.
• Custom health checks: your own tooling reports status through the set-instance-health API.

If your instances sit behind a load balancer, turn on ELB health checks. Otherwise an instance with a dead application can look perfectly healthy to EC2.

The health check grace period is the time Auto Scaling waits after an instance enters InService before it starts checking that instance's health. It exists because a new instance needs time to boot, run user data, and start the application.

The commonly used default is 300 seconds. If the grace period is shorter than your real startup time, the load balancer will report the instance unhealthy, Auto Scaling will terminate it, and the group can get stuck in a launch-and-terminate loop.

Measure how long your application takes to become ready, then set the grace period slightly above that. Setting it far too high delays replacement of instances that really are broken.

A lifecycle hook pauses an instance at a transition point so you can run custom actions before it moves on. There are two hook types:

• autoscaling:EC2_INSTANCE_LAUNCHING puts the instance in Pending:Wait, useful for installing agents or pulling config before it receives traffic.
• autoscaling:EC2_INSTANCE_TERMINATING puts it in Terminating:Wait, useful for draining connections, uploading logs, or deregistering from a service.

Auto Scaling notifies you through EventBridge, SNS, or SQS. Your automation does its work, then calls complete-lifecycle-action with CONTINUE or ABANDON. If nothing responds, the hook times out (one hour by default) and the default result applies.

You can extend the wait by sending a heartbeat with record-lifecycle-action-heartbeat.

Horizontal scaling (scale out/in) changes the number of instances. Vertical scaling (scale up/down) changes the size of a single instance, such as moving from m5.large to m5.2xlarge.

EC2 Auto Scaling is built for horizontal scaling. Vertical scaling still has a place for databases or legacy apps that cannot run on several nodes.

EC2 Auto Scaling manages groups of EC2 instances. Application Auto Scaling is a separate API that scales other AWS resources through a common model of scalable targets and scaling policies.

A containerized app on ECS often uses both: Application Auto Scaling for the service task count and EC2 Auto Scaling for the cluster instances.

Both describe how to launch instances for an ASG, but launch templates are the modern replacement. Launch configurations are legacy: they are immutable and have not received new features, and AWS no longer lets new accounts create them.

If you still have an ASG on a launch configuration, AWS provides a way to migrate it to a launch template from the console or CLI.

A termination policy decides which instance is removed first during a scale-in. The default policy first picks the Availability Zone with the most instances so the group stays balanced, then prefers instances on the oldest launch template or configuration, then those closest to the next billing hour, and finally picks randomly.

You can replace the default with one or more of these:

• OldestInstance and NewestInstance
• OldestLaunchTemplate and OldestLaunchConfiguration
• ClosestToNextInstanceHour
• AllocationStrategy to align with your Spot and On-Demand mix
• A custom Lambda function for your own selection logic

Instances with scale-in protection are skipped. A common pattern is OldestLaunchTemplate so outdated instances disappear first after a rollout.

Group metrics are CloudWatch metrics that describe the state of the ASG itself, not the instances inside it. They report counts such as:

• GroupMinSize, GroupMaxSize, GroupDesiredCapacity
• GroupInServiceInstances and GroupPendingInstances
• GroupStandbyInstances and GroupTerminatingInstances
• GroupTotalInstances

They are sent at one-minute granularity and cost nothing, but you have to switch them on with enable-metrics-collection. They are handy for alarms like "desired capacity has been at max for 30 minutes", which usually means you are being capped.

Do not confuse them with EC2 instance metrics like CPUUtilization, which scaling policies actually act on. Turning on detailed monitoring gives those one-minute data points too.

Instance warmup is the time a newly launched instance needs before it can handle a full share of load. During that time, its metrics are left out of the group's aggregate, so Auto Scaling does not act on numbers that are still ramping up.

Without warmup, a freshly booted instance reports low CPU, drags the average down, and may trigger an early scale-in. Or the opposite: the group keeps adding instances while earlier ones are still starting.

Set a default instance warmup on the group so target tracking, step scaling, and instance refresh all use the same value. Pick a number close to the real time from launch until the app is serving normally.

Both are triggered by a CloudWatch alarm, but step scaling can pick different adjustments based on how far the metric has gone past the threshold, while simple scaling always applies a single adjustment.

With step scaling you define ranges. For example, with an alarm at 60% CPU: 60-70% adds 1 instance, 70-85% adds 2, and anything above 85% adds 4. The bigger the breach, the bigger the response.

The other difference is timing. Simple scaling must finish its activity and sit out the cooldown before it reacts again. Step scaling keeps evaluating the alarm while a scaling activity is running and uses instance warmup to avoid double-counting capacity that is still starting. This makes it far more responsive during fast spikes.

AWS now recommends target tracking or step scaling over simple scaling for most cases.

When you give an ASG subnets in several Availability Zones, it tries to keep the instance count even across zones. On scale-out, it launches into the zone with the fewest instances. On scale-in, the default termination policy removes from the zone with the most.

If the spread gets uneven, for instance after an AZ recovers from an outage or a launch fails in one zone, the AZRebalance process steps in. It launches a new instance first in the under-populated zone and only then terminates one from the crowded zone, so capacity never dips.

During rebalancing, the group can briefly go above its maximum (by up to about 10%, or one instance, whichever is larger). If you want strict numbers, you can suspend AZRebalance, but you give up automatic balancing.

For most workloads, target tracking is the better starting point because it is simpler and self-tuning. You state a goal like "keep average CPU at 50%" and Auto Scaling works out how many instances are needed, creating and adjusting alarms for you.

Choose step scaling when the metric does not fall as capacity rises, when you want an aggressive jump at a certain threshold, or when scale-in and scale-out need very different shapes. You can attach both types to the same group if you need to.

You attach one or more target groups to the ASG. From then on, the group registers each new instance with the target group once it is ready, and deregisters it before it is terminated.

flowchart LR
  A["Scale-out event"] --> B["Instance launches"]
  B --> C["Launch hook completes"]
  C --> D["Registered to target group"]
  D --> E{ALB health check passes?}
  E -- Yes --> F["Receives traffic"]
  E -- No --> G["Marked unhealthy and replaced"]

A few details matter in practice:

• Enable ELB health checks on the ASG so a failing app triggers replacement, not just a failing VM.
• On scale-in, the instance is deregistered and the target group's deregistration delay lets in-flight requests finish.
• Use the ALBRequestCountPerTarget metric for target tracking so scaling follows actual request load.
• The ASG's subnets should cover the same Availability Zones the ALB is enabled in.

Scale-in protection stops Auto Scaling from selecting an instance for termination during a scale-in event. It is useful for instances doing long jobs, like video encoding or a batch worker holding a lease.

It can be set at two levels:

• Group level: every newly launched instance starts protected.
• Instance level: you protect or unprotect individual instances, usually from the application itself when it starts and finishes work.

Be aware of what it does not cover. A protected instance can still be replaced after a failed health check, terminated manually, or lost to a Spot interruption. And if every instance is protected, a scale-in simply cannot remove anything, so cost may stay high.

An instance in Standby is still part of the group but is taken out of service. It is deregistered from the load balancer, no longer receives traffic, and Auto Scaling stops running health checks on it, so it will not be replaced while you work.

This is the clean way to patch, debug, or inspect a live instance. When you call enter-standby, you choose whether to decrement desired capacity. If you do, the group will not launch a substitute. If you do not, it launches a new instance to keep the count.

Calling exit-standby puts the instance back in service and re-registers it. You keep paying for a standby instance, so do not leave it there for weeks.

Auto Scaling does its job through named internal processes. Suspending one stops that behavior until you resume it, while the others keep running.

Teams suspend AZRebalance or ReplaceUnhealthy during troubleshooting or deployments. The risk is forgetting to resume. A group with Launch suspended will not heal itself, which can quietly cause an outage.

Queue length alone is a poor scaling signal, because the right number of workers depends on how many instances you already have. The recommended approach is a backlog per instance metric used with a target tracking policy.

The formula is ApproximateNumberOfMessagesVisible / number of InService instances. You can build it with CloudWatch metric math directly in the policy, so no Lambda is needed.

Then work out the target. If a worker handles one message in 10 seconds and you accept a 10-minute wait, the target backlog per instance is 600 / 10 = 60 messages. Auto Scaling then adds or removes instances to hold that ratio.

Pair it with a sensible minimum so the first message is picked up quickly, and use scale-in protection or lifecycle hooks so a worker is not killed halfway through a message.

Every instance moves through a defined set of states from launch to termination, and lifecycle hooks can pause it at two of the transitions.

flowchart LR
  A[Pending] --> B["Pending:Wait (launch hook)"]
  B --> C["Pending:Proceed"]
  C --> D[InService]
  D --> E[Terminating]
  E --> F["Terminating:Wait (terminate hook)"]
  F --> G["Terminating:Proceed"]
  G --> H[Terminated]
  D --> I[EnteringStandby]
  I --> J[Standby]
  J --> D
  D --> K[Detaching]
  K --> L[Detached]

• Pending: the instance is being launched. If a launch hook exists, it waits in Pending:Wait until the hook completes.
• InService: running, registered with the load balancer, and counted as capacity.
• Standby / Detached: manually removed from service or from the group.
• Terminating: being shut down, optionally held in Terminating:Wait for cleanup, then Terminated.

Only InService instances count toward the group's healthy capacity.

Use a warm pool when new instances take a long time to become useful, for example a large AMI, heavy user data, or a slow application bootstrap. Scale-out then pulls an already-initialized instance from the pool instead of starting from scratch.

Pool instances can be kept in one of three states:

A launch lifecycle hook is commonly used to run the long initialization once, while the instance is in the pool. You can also let instances return to the pool on scale-in so they can be reused. If your app starts in under a minute, a warm pool adds complexity without much benefit.

Instance refresh replaces the instances in an ASG in rolling batches so that every instance picks up a new launch template version, a new AMI, or changed settings. You trigger it once, and Auto Scaling handles the replacement order.

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name web-asg \
  --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":120,"AutoRollback":true}'

The main preferences to know:

• MinHealthyPercentage: how much of the group must stay healthy during the roll (90% by default).
• InstanceWarmup: how long to wait before a replacement counts as healthy.
• Checkpoints: pause at chosen percentages, such as 20% and 50%, so you can verify before continuing.
• AutoRollback: revert to the previous configuration if the refresh fails or an alarm fires.
• SkipMatching: skip instances that already match the desired configuration.

Instance refresh replaces instances in place within the same group, so it suits routine AMI updates. For a safer cutover with instant rollback, a blue/green approach with two groups is more suitable.

A mixed instances policy lets one ASG use several instance types and combine On-Demand with Spot capacity. The main reasons are lower cost and better resilience to capacity shortages.

You control the blend with a few settings:

• On-Demand base capacity: a fixed number of On-Demand instances that always run.
• On-Demand percentage above base: the share of extra capacity that stays On-Demand, with the rest on Spot.
• Instance type overrides: a list such as m5.large, m5a.large, m6i.large, c5.xlarge.
• Allocation strategy: for Spot, price-capacity-optimized is the usual recommendation.

If one instance type runs out in a zone, the group can launch another, so you are less likely to hit InsufficientInstanceCapacity. It requires a launch template.

Spot Instances can be reclaimed with a two-minute warning, so the goal is to make an interruption boring rather than rare.

1. Diversify: use many instance types and several Availability Zones so no single capacity pool dominates.
2. Choose a good allocation strategy: price-capacity-optimized picks pools that are both cheap and less likely to be interrupted.
3. Keep an On-Demand base for the minimum capacity your service cannot lose.
4. Enable Capacity Rebalancing: the group launches a replacement as soon as AWS signals a Spot instance is at elevated risk, and then drains the old one.
5. React to the notice: use a termination lifecycle hook or the EventBridge interruption event to drain connections and checkpoint work.
6. Stay stateless: store sessions and results outside the instance.

Spot works best for stateless web tiers, queue workers, CI runners, and batch jobs. It is a poor fit for a single-node database.

Attribute-based instance type selection (ABIS) lets you describe the instance requirements instead of listing instance types by name. Auto Scaling then chooses every matching type available in your Region.

You specify limits such as vCPU count, memory size, CPU architecture, and instance generation, and you can exclude families you do not want.

"InstanceRequirements": {
  "VCpuCount": {"Min": 2, "Max": 4},
  "MemoryMiB": {"Min": 8192},
  "CpuManufacturers": ["intel", "amd"],
  "ExcludedInstanceTypes": ["t2.*"]
}

The big win is future proofing: when AWS releases a new instance type that fits your rules, the group can use it without anyone editing the template. It also widens the pool of Spot capacity. It works with mixed instances policies, so you can still define the On-Demand and Spot split.

Scale-in terminates instances, so the application needs a window to finish what it is doing. Several mechanisms combine to give it one.

1. Deregistration delay: the target group stops sending new requests and gives in-flight ones time to complete (default 300 seconds).
2. Termination lifecycle hook: the instance waits in Terminating:Wait while a script or Lambda drains work, flushes logs, or hands off a lease.
3. Heartbeat: if cleanup takes longer, call record-lifecycle-action-heartbeat to extend the timeout.
4. Complete the action: call complete-lifecycle-action with CONTINUE so termination proceeds.

For workers handling long jobs, add scale-in protection while a job is running and clear it afterward. Also make sure your process handles SIGTERM properly, since the OS signal is what actually reaches the application.

Start with the Activity history of the group (console or describe-scaling-activities). Each failed launch has a status message that usually names the cause.

Also check that desired capacity is not already at the maximum, that the instance profile can be passed, and that the key pair still exists. If launches keep failing for a long time, Auto Scaling backs off and may stop retrying, so fix the cause and verify that the group has resumed.

If instances launch fine and then disappear within minutes, Auto Scaling is almost always replacing them as unhealthy. Check the activity history for a cause such as "Health check failed" or "ELB health check failed".

The usual suspects:

• Grace period too short: the load balancer checks before the app is ready.
• Wrong health check path or port: the target group probes a URL that returns 404 or 500.
• Security group blocks the ALB: the instance cannot receive health check traffic.
• User data failed: the application never started because a script errored out.
• Encrypted volume problem: the instance cannot start because of missing KMS permissions.
• Lifecycle hook abandoned: a hook timed out with ABANDON as the default result.

To investigate, temporarily put an instance in Standby or suspend ReplaceUnhealthy, then connect and read /var/log/cloud-init-output.log and the application logs.

Use them together when you know a surge is coming but cannot predict its exact size. Dynamic scaling alone reacts after traffic arrives, and a fresh instance needs minutes to boot. Scheduled scaling closes that gap.

A practical pattern: at 8:00 AM, a scheduled action raises the minimum capacity from 4 to 12. Dynamic scaling is still active and can go above 12 if load demands it, and can come back down to 12 but not below. At 7:00 PM, another scheduled action lowers the minimum to 4.

Raising the minimum, not the desired value, is the key trick. Dynamic policies keep working on top of that floor, whereas a scheduled change to desired alone can be overwritten by the next policy evaluation.

For launches, sales events, or school-term traffic, schedule extra headroom 15 to 30 minutes early. If the pattern recurs reliably, consider predictive scaling instead of maintaining many schedules.

An ASG can have several policies, for example one tracking CPU and another tracking request count. If more than one wants to change capacity at once, Auto Scaling resolves it by choosing the option that gives the largest capacity.

• Scale-out: Policy A wants +1 and policy B wants +3, so the group adds 3.
• Scale-in: Policy A wants -1 and policy B wants -2, so the group removes only 1, because that leaves more capacity.
• Scale-out vs scale-in: scale-out wins over scale-in.

For target tracking, there is an extra rule: the group scales in only when all target tracking policies are ready to scale in. This prevents one metric from removing capacity that another metric still needs.

The practical effect is that the group favors availability over savings. Overlapping policies are safe, but each additional policy can slow scale-in.

Start in forecast only mode. Auto Scaling builds the forecast and shows it next to actual load, but does not launch anything. You get a risk-free way to judge accuracy.

1. Create the predictive policy with mode ForecastOnly after the group has at least a day of data (a week or more gives better results).
2. Open the policy's graphs and compare forecasted load and forecasted capacity with what actually happened over several days.
3. Check that the chosen scaling metric (for example CPU) really tracks the load metric (for example request count). A weak correlation gives poor forecasts.
4. Review how the forecast treats your maximum capacity, and decide whether it may exceed it using MaxCapacityBreachBehavior.
5. Switch to ForecastAndScale and tune SchedulingBufferTime so instances launch early enough to finish booting.

Keep your dynamic policies attached. Predictive scaling covers the pattern, and dynamic scaling still covers the surprise.

The idea is to run the new version in a second ASG next to the current one, shift traffic gradually, and keep the old group around until you are confident.

flowchart LR
  U[Users] --> L["ALB listener with weighted rules"]
  L -- 90 percent --> TB["Target group blue"]
  L -- 10 percent --> TG["Target group green"]
  TB --> AB["ASG blue - v1"]
  TG --> AG["ASG green - v2"]

1. Create a launch template version with the new AMI and a new ASG (green) attached to its own target group.
2. Wait until green instances pass health checks.
3. Change the ALB listener to weighted forwarding, for example 90/10, then 50/50, then 0/100 while watching error rate and latency.
4. If metrics degrade, set the weights back to blue. Rollback takes seconds because blue is still running.
5. After a bake period, scale blue down to zero or delete it.

The trade-off is paying for roughly double capacity during the switch. If that is too costly and a brief rolling change is acceptable, instance refresh with checkpoints and auto rollback is simpler. AWS CodeDeploy can also automate the blue/green flow for ASGs.

Cost in an ASG comes from how many instances run, how long, and at what price. Work on each of those three.

• Run fewer instance hours: use target tracking with a realistic target (60 to 70% CPU is often safe, 30% wastes money) and scheduled scale-in for nights and weekends.
• Pay a lower price: use a mixed instances policy with Spot for the flexible share and an On-Demand base for the floor.
• Cover the baseline: buy Savings Plans or Reserved Instances for the minimum capacity that always runs.
• Right-size the instance: review utilization, and consider Graviton-based types if your software supports ARM.
• Scale in faster where safe: shorten instance warmup and cooldown values to your real startup time, so excess capacity is released sooner.
• Use warm pools carefully: prefer the Stopped state over Running.

Set a sensible maximum capacity and a CloudWatch billing alarm too, so a bug or traffic attack cannot scale you into a surprise bill.

An instance maintenance policy controls how much capacity an ASG keeps during replacements that Auto Scaling starts, such as replacing an unhealthy instance or one that has reached its maximum lifetime. You set it by choosing a minimum and maximum healthy percentage.

The max cannot be more than 100 percentage points above the min. Without a policy, the default behavior is to terminate first and then launch.

Choose launch before terminating for latency-sensitive services where losing even one instance hurts. Choose terminate-and-launch for batch groups where a brief dip is fine.

ECS has two layers, and each one scales separately.

For EC2-backed clusters, create an ASG capacity provider with managed scaling turned on. ECS publishes a CapacityProviderReservation metric and creates a target tracking policy to keep it at your target (commonly 100%), which means "just enough instances for the tasks that need to run".

Turn on managed termination protection as well. ECS then protects instances that have running tasks from scale-in, which prevents tasks from being killed mid-flight.

With Fargate there are no instances to manage, so only the service-level task scaling applies.

For tables in provisioned mode, use Application Auto Scaling. It adjusts read and write capacity units for the table and each global secondary index to follow actual usage.

1. Register the table (or index) as a scalable target with a minimum and maximum capacity.
2. Attach a target tracking policy for read or write usage, with a target utilization such as 70%.
3. Application Auto Scaling creates the alarms and raises or lowers provisioned capacity when consumption drifts from the target.

aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/Orders \
  --scalable-dimension dynamodb:table:WriteCapacityUnits \
  --min-capacity 5 --max-capacity 500

It reacts to consumed capacity over a few minutes, so very sharp spikes can still throttle before scaling catches up. For unpredictable or spiky traffic, on-demand mode is the simpler choice. For known peaks, add scheduled actions to the same scalable target.

There are three main channels, and they suit different needs.

A solid minimum is an alarm on failed launches and one on desired capacity equal to max for a prolonged period. The first catches broken templates or quota problems, the second tells you traffic is being capped. Lifecycle hook events also arrive through EventBridge, which is how automation reacts to instances entering Pending:Wait.

Because every instance comes from the same template, security is mostly decided once in the launch template and the surrounding IAM setup.

• Instance profile: give instances a least-privilege IAM role, not broad admin access.
• IMDSv2 required: set HttpTokens to required in the template's metadata options to block SSRF-style credential theft.
• Encryption: enable EBS encryption and make sure the KMS key policy allows the Auto Scaling service-linked role, AWSServiceRoleForAutoScaling.
• Network: launch into private subnets with no public IP, and let security groups allow only the load balancer.
• Access: use Systems Manager Session Manager instead of open SSH ports and shared keys.
• Patching: bake updates into a new AMI and roll it out with instance refresh.

The people creating the group also need iam:PassRole for the instance profile, so limit who holds that permission.

Auto Scaling treats instances as disposable, so the safest design is to keep state off the instance. Anything that must survive a replacement should live somewhere else.

• Sessions: store them in ElastiCache or DynamoDB instead of local memory.
• Files and uploads: use S3 for objects, or EFS when many instances need a shared file system.
• Databases: use RDS, Aurora, or DynamoDB, not a database on the ASG instance.
• Configuration: pull from Parameter Store or Secrets Manager at boot.

Sometimes you truly need per-node data, for example a clustered service with its own EBS volume. A workable pattern is one ASG per Availability Zone with min and max both set to 1, plus a launch lifecycle hook that attaches the persistent EBS volume to the new instance before it goes InService. You get automatic healing without losing the data.

Sticky sessions on the load balancer can help short term, but they make scale-in disruptive and should not replace external session storage.

Target tracking turns a metric target into instance launches through a short chain of automated steps.

sequenceDiagram
  participant I as Instances
  participant CW as CloudWatch
  participant AS as Auto Scaling
  participant EC2 as EC2
  participant LB as Load Balancer
  I->>CW: Publish metric (CPU 75%)
  CW->>CW: AlarmHigh breaches target 50%
  CW->>AS: Alarm triggers scaling policy
  AS->>AS: Compute new desired capacity
  AS->>EC2: Launch new instances
  EC2->>AS: Instances reach InService
  AS->>LB: Register with target group
  Note over AS: Warmup excludes new instances from metrics

1. Instances publish their metric to CloudWatch (one-minute data with detailed monitoring).
2. The alarm that the policy created goes into ALARM after a few consecutive breaching data points, while the scale-in alarm needs far more, so the group scales out fast and in slowly.
3. Auto Scaling calculates the capacity that would bring the metric back to the target. With 4 instances at 75% CPU and a 50% target, it needs about 4 x 75 / 50 = 6 instances, so it adds 2.
4. EC2 launches instances from the launch template, any launch hook runs, and the instances are registered with the load balancer.
5. During instance warmup, the new instances are not counted in the aggregate, which prevents another round of over-scaling.

The new capacity is capped by the group's maximum, and the metric settles back near the target once the new instances share the load.

Instances in the impaired zone start failing health checks. Auto Scaling marks them unhealthy, terminates them, and launches replacements in the remaining healthy zones of the group, so the instance count recovers without anyone acting.

flowchart TD
  A["AZ-a becomes impaired"] --> B["Instances fail ELB or EC2 health checks"]
  B --> C["Marked unhealthy and terminated"]
  C --> D["Replacements launched in AZ-b and AZ-c"]
  D --> E["AZ-a recovers"]
  E --> F["AZRebalance evens out the zones"]

A few things decide how smooth this is:

• Headroom: if you run 3 zones, size the group so that losing one still leaves enough capacity. Otherwise the survivors are overloaded until replacements are ready.
• Subnets in several zones: an ASG with a single AZ cannot fail over.
• ELB health checks: without them, the load balancer may keep sending traffic to dead targets.
• AZRebalance: after recovery, it gradually moves capacity back, launching before terminating.

For a prolonged, partial impairment you can also remove the affected subnet from the group. Auto Scaling then replaces its instances in the other zones.