A team is creating a new EC2 Auto Scaling group for a web tier behind an Application Load Balancer. They need the group's instance specification to support a mix of instance types together with both On-Demand and Spot capacity, and they want to publish updated specifications over time without recreating the group. They also want capacity to track demand by holding a steady number of requests per instance as traffic rises and falls, without authoring individual capacity steps. Which two choices together meet these requirements? (Select TWO.)
- AHave the Auto Scaling group reference a launch template, which supports mixed instance types across On-Demand and Spot purchasing and is published as new numbered versions. Correct
- BAttach a target tracking scaling policy that keeps the ALB request count per target at a chosen value so the group sizes itself toward that set point automatically. Correct
- CHave the Auto Scaling group reference a launch configuration, then edit it whenever the instance specification needs to change for the running group.
- DAttach a step scaling policy with several breach bands on request count so each band applies a different capacity adjustment as the metric rises.
- EConfigure a scheduled scaling action that raises the desired capacity at fixed times of day, on a recurring cron expression, to follow the expected daily traffic curve.
Why A is correct: Launch templates support a mixed instances policy across On-Demand and Spot and are versioned, so the group can adopt new specifications without being rebuilt.
Why B is correct: Target tracking on the ALBRequestCountPerTarget metric maintains a steady requests-per-instance figure and adjusts capacity without hand-authored steps.
Why C is wrong: A launch configuration is immutable and cannot mix instance types or purchase options, so it fails both the mixed-capacity and the versioning requirement.
Why D is wrong: Step scaling does maintain capacity, but it forces the team to author the individual adjustment steps the requirement says they want to avoid.
Why E is wrong: Scheduled scaling reacts to the clock, not to live request volume, so it cannot hold a steady requests-per-instance figure as demand varies.