EC2 Families, Auto Scaling, and Managed Compute
Key Takeaways
- Choose Amazon EC2 families by bottleneck: general purpose (M, burstable T), compute (C), memory (R, X, U), storage (I, D), accelerated (P, G, Inf, Trn), and HPC; Graviton (g suffix) is a price-performance option when the stack is multi-architecture.
- Amazon EC2 Auto Scaling target tracking is the default Professional scaling policy when the metric moves inversely with capacity; step and simple scaling need hand-tuned increments; mixed instance policies plus warm pools speed scale-out for slow-booting fleets.
- Warm pools now support mixed On-Demand instance types, but they still do not support Spot in the mixed policy or instance weighting; scale-out prefers warm types then cold-launches the rest of the policy.
- Elastic Beanstalk, AWS Batch, AWS Outposts, and AWS Wavelength reduce undifferentiated patching or place compute where latency and data residency demand; AWS documentation currently states AWS App Runner is not open to new customers.
- AWS Systems Manager Inventory and Patch Manager are the first operational layer on any EC2 you still run: collect metadata, then patch from baselines in maintenance windows—this chapter introduces them; later chapters go deeper.
Capacity first, placement later
When SAP-C02 asks you to design new compute, start with what the workload consumes (CPU, memory, GPU, local NVMe, network) and how it must grow. Placement groups, dedicated hosts, and tenancy fine-tuning show up when you improve an existing solution’s performance; this section stays on capacity: families, Auto Scaling, and managed platforms that shrink the patching surface.
Apex Health’s imaging service transcodes DICOM to web formats. The bottleneck is CPU, not RAM. A memory-optimized R family instance wastes money. A compute-optimized C family (including Graviton C7g / C8g when the container is multi-arch) is the first sketch. GPUs (G or P) appear only if a later model truly needs them—do not sprinkle accelerators on a CPU encoder.
Instance families and naming
Amazon EC2 instance types combine a family, generation, optional processor/capability letters, and a size. Current generations run on the Nitro hypervisor for almost all families you will specify in a new design; Xen remains on some previous-generation types. Launch with HVM AMIs.
| Family (examples) | Optimization | Typical new-solution use |
|---|---|---|
| M (M7i, M8g) | Balanced vCPU/memory | General APIs, mixed microservices |
| T (T3, T4g) | Burstable CPU credits | Dev, low-average CPU, not sustained 80% |
| C (C7i, C8g) | High vCPU per dollar | Transcoding, batch compute, game servers |
| R, X, U | High memory | In-memory caches, large JVMs, SAP-class RAM |
| I, D | Local instance store / dense HDD | High IOPS local disks, data warehouses on instance store (with replication) |
| P, G, Inf, Trn | GPU / Inferentia / Trainium | Training, inference, graphics |
| Hpc | Tightly coupled HPC | MPI-style jobs, often in few AZs |
Graviton types use an g in the name (M7g, C8g, T4g). They often win price-performance when Amazon Machine Images (AMIs) and containers support arm64. AMD (a) and Intel (i) variants trade price and instruction sets. Flex types (for example M7i-flex) target applications that do not need full, sustained bandwidth of the non-flex size—confirm current instance-type documentation rather than memorizing every SKU.
Burstable T instances are a classic trap: they look cheap until a production API sits at high CPU and spends CPU credits. Sustained compute belongs on M or C. Mac instances exist for iOS/macOS build farms; they are not general web-tier capacity.
Attribute-based mixed instance policies (vCPU, memory, CPU manufacturer, burstable vs non-burstable) let Auto Scaling pick from a pool when an AZ is short on c7g.xlarge. That is a capacity strategy: you care that enough vCPU launches, not that every instance is the same SKU. Weighted mixed policies assign capacity units per type; they change how desired capacity is counted.
Auto Scaling policies
An Auto Scaling group (ASG) has minimum, maximum, and desired capacity. Current capacity counts instances that finished warmup. Policies adjust desired capacity.
| Policy | When it fits | Trap |
|---|---|---|
| Target tracking | Metric falls when you add capacity (CPU, ALB request count per target, custom metrics with that shape) | AWS recommends this as the default; you set a target (for example 60% CPU), not step sizes |
| Step scaling | You know breach bands (60% add 10%, 75% add 30%) | Easy to get wrong; flapping if scale-in and scale-out thresholds are too close |
| Simple scaling | One adjustment plus a cooldown | Cooldown blocks the next action; usually inferior to target tracking |
| Scheduled | Known diurnal peaks (claims batch at 02:00) | Does not follow unexpected load |
| Predictive | Forecastable historical load | Complements, does not replace, a reactive policy |
Target tracking proportionally scales when the metric is inversely related to capacity. Step scaling uses ChangeInCapacity, ExactCapacity, or PercentChangeInCapacity (with optional MinAdjustmentMagnitude). Percentages round down above 1. Instance warmup keeps a new instance out of the aggregated metric until it is ready so you do not under-scale while Java is still compiling. While scale-out warmup is in progress, scale-in from policies is blocked.
Apex Health sets imaging ASGs to target tracking at 55% average CPU, a default instance warmup equal to the observed 12-minute JIT plus cache-load time, and a scheduled scale-out before the 07:00 clinic rush. They do not use simple scaling with a 300-second cooldown as the only policy for that fleet.
Mixed instances and warm pools
Mixed instance policies combine an On-Demand base with optional Spot above the base, across instance types or attribute-based pools. Spot improves cost for interruption-tolerant batch; it is the wrong default for a stateful warm pool of clinical viewers.
A warm pool is a set of pre-initialized instances beside the ASG. Scale-out warm-starts them instead of booting cold—critical when user data runs for many minutes. Pool size is usually max − desired unless you set MaxGroupPreparedCapacity. ReuseOnScaleIn returns instances to the pool instead of terminating them.
As of the November 2025 Auto Scaling announcement, warm pools work with mixed On-Demand instance types (manual lists or attribute-based InstanceRequirements). Constraints that still fail designs:
- No instance weighting on a mixed group that uses a warm pool.
- No Spot inside that mixed policy when a warm pool is attached.
- Hibernated warm pools need HibernationOptions in the launch template.
- Lifecycle hooks are part of the documented prerequisites so initialization can finish before the instance is
InService.
During scale-out, Auto Scaling prefers instance types already in the warm pool, then cold-launches remaining types in the mixed policy if warm launch cannot satisfy the request. That is how you keep both fast scale-out and AZ capacity diversity.
Managed compute that reduces patching
Every EC2 instance you own is an OS you patch. SAP-C02 rewards reducing undifferentiated heavy lifting when the workload fits a managed platform.
AWS Elastic Beanstalk is a platform as a service for web applications: you provide a bundle or container, Beanstalk provisions load balancer, ASG, and platform. Managed platform updates apply minor and patch platform versions in a maintenance window using rolling or immutable strategies. You still can SSH and customize, which is both a benefit and a way to create snowflakes. Beanstalk is a strong new-solution answer when a small team wants a twelve-factor web app without designing ECS.
AWS App Runner used to be the “source or image to HTTPS URL” answer with even less infrastructure. AWS documentation currently states App Runner is no longer open to new customers; existing customers can continue. For a greenfield account in 2026, do not treat App Runner as the default managed web host. Prefer Beanstalk, Amazon ECS on AWS Fargate plus an Application Load Balancer, or Lambda plus API Gateway depending on the runtime.
AWS Batch runs queued jobs on ECS, EKS, Fargate, EC2 (including Spot), and ECS Managed Instances. You define queues and compute environments; Batch provisions capacity for the job, then scales away. Use it for transcoding farms, simulations, and SageMaker Training job queuing—not for an always-on patient portal.
AWS Outposts extends AWS racks or servers to a customer site. Subnets on the Outpost stay in the same VPC as the parent Availability Zone. Racks support EC2, EBS, ECS, EKS nodes, RDS, S3 on Outposts, and Application Load Balancers; servers are smaller (EC2 and ECS, not EKS nodes or EBS in the same way). The service link reaches the Region; a local gateway (racks) talks to on-premises networks. You cannot connect one Outpost to another Outpost or Local Zone in the same VPC. Choose Outposts when data residency or on-premises latency forbids a Region-only design—not as a cheaper EC2 SKU.
AWS Wavelength places compute at a communications service provider 5G edge. A Wavelength Zone is a logical extension of a parent Region. You create Wavelength subnets, run EC2 (and in supported zones ECS/EKS/ALB), and use a carrier gateway for carrier and internet paths. Control-plane APIs stay in the parent Region. Use Wavelength for mobile ultra-low-latency; use Outposts for a hospital data center; do not swap the two.
Systems Manager inventory and patch (introduction)
If you still run EC2—including Beanstalk instances and Batch EC2 compute environments—AWS Systems Manager is how you avoid one-off SSH. Inventory collects metadata only (applications, network config, Windows updates, tags, optional custom JSON). Collection intervals start at 30 minutes. Store and query via a resource data sync to S3 and Athena across accounts. Inventory does not read application patient records; it reads software inventory.
Patch Manager (deeper in later operational chapters) applies patch baselines during maintenance windows to managed nodes. For new solutions, decide now that every instance is a managed node (SSM agent, instance profile, private connectivity to SSM endpoints) so inventory and patching are possible. Public parameters for golden AMIs (including vendor-maintained AMI IDs) belong in Parameter Store, taught with configuration management in the serverless section.
Exam traps: T-family for sustained high CPU; GPUs for a CPU encoder; warm pool plus Spot plus weights; treating App Runner as open to every new account; using Outposts for a workload that only needed a Region Multi-AZ ASG; claiming placement groups in this chapter as the primary capacity tool; skipping SSM and promising “we will patch with SSH.”
Apex Health’s Java imaging service takes about 12 minutes to JIT and load caches. The Auto Scaling group must use several On-Demand instance types so an Availability Zone capacity shortfall on one SKU does not block scale-out. Instances cannot be Spot because in-memory cache warmup is expensive to throw away. Which capacity design fits?
A small Apex Health team is launching a new internal twelve-factor web app. They want AWS to apply platform patches in a maintenance window rather than baking a new AMI every week, they are fine with Elastic Load Balancing and Auto Scaling underneath, and the AWS account is brand new. Which compute choice should you recommend for that new solution?
You are choosing instances and scaling for a CPU-bound transcoding fleet whose average CPU falls when you add instances. Sustained utilization near 60% is the goal, and the container images already run on arm64. Which combination is the best Professional starting point?