Spot, Mixed Auto Scaling, Compute Optimizer, and Storage Lens

Existing waste versus a blank architecture

SAP-C02 will offer you a fleet that has been oversized for months and, in the next item, a service that has never produced a CloudWatch datapoint. Rightsizing existing resources (Task 3.5) uses measured CPU, memory, network, and storage counters. Selecting the right size for a new solution (Task 2.6) uses requirements, the AWS Pricing Calculator, current generation families, and a purchase mix. Organizational visibility (Task 1.5) still matters: opt Compute Optimizer in from the management account to analyze member accounts, and scope S3 Storage Lens to the Organization so finance sees which account owns the glacier of incomplete multipart uploads.

Do not “wait for Optimizer” on a greenfield design. Do not buy a three-year EC2 Instance plan on Optimizer's current r5.4xlarge recommendation if you have not yet confirmed the instance is idle.

Spot Instances and interruption handling

A Spot Instance uses spare EC2 capacity at a Spot price that AWS sets from long-term supply and demand—steeply below On-Demand when capacity is plentiful, never a guarantee. AWS can reclaim the instance. Two signals matter:

1. EC2 instance rebalance recommendation — the instance is at elevated risk of interruption. Start draining, checkpointing, or launching a replacement now.
2. Spot interruption notice — a two-minute warning before EC2 terminates, stops, or hibernates the instance (the interruption behavior you configured, and whether the AMI/EBS configuration supports stop/hibernate).

Spot fits batch analytics, CI workers, stateless scale-out, and other work that can checkpoint or die. It does not fit a single-node 24/7 stateful database, a license server, or a user-facing API that cannot tolerate a two-minute drain unless you have an On-Demand (or Reserved/Savings Plans-backed) floor underneath.

A Spot capacity pool is one instance type in one Availability Zone. Diversify types and AZs so one pool's interruption is not your entire service. Persistent Spot requests and Auto Scaling replace capacity; they do not make an individual Spot instance immortal.

Savings Plans do not apply to Spot. Do not size a Compute Savings Plan from a fleet you intend to run as Spot.

Mixed Auto Scaling groups: 24/7 floor, batch burst

EC2 Auto Scaling mixed instances policies are the professional-level pattern for combining purchase options in one group:

• OnDemandBaseCapacity — a count that should stay On-Demand (or be covered by RIs/Savings Plans) even when Spot is cheap.
• OnDemandPercentageAboveBaseCapacity — how much of the additional capacity is On-Demand versus Spot.
• SpotAllocationStrategy — AWS currently recommends price-capacity-optimized, which balances interruption risk and price. capacity-optimized favors the deepest pools when restarting work is expensive. lowest-price is the older, riskier default for interruption-sensitive work.
• Overrides — multiple instance types (and, often, multiple generations) so the group can draw from many pools.
• Capacity rebalancing — when a rebalance recommendation fires, Auto Scaling proactively launches a replacement before the two-minute notice, which is how you keep desired capacity closer to stable for Spot-heavy groups.

A realistic SAP-C02 scenario: a 24/7 customer API that cannot drop below six tasks, plus a nightly Spark job that wants 200 workers. Put the API on On-Demand/Fargate/EC2 with a Savings Plan covering the floor. Put Spark on a mixed group with a small On-Demand base (or none, if job retries are acceptable) and Spot for the rest, with diversified types and capacity rebalancing. Do not place both personalities in a 100 percent Spot group and hope the API survives a capacity crunch.

For containers, the same idea appears as Fargate Spot versus Fargate, or as ECS/EKS node groups with mixed instances. The exam still wants you to name the interruption model and the base-capacity split.

Compute Optimizer: Task 3.5 with metrics

AWS Compute Optimizer analyzes configuration and Amazon CloudWatch utilization to recommend rightsizing, idle cleanup, and (for many resource types) migration to newer generations including AWS Graviton. You must opt in. After opt-in it analyzes roughly the last 14 days of metrics by default. Enhanced infrastructure metrics (a paid preference) extend lookback to 93 days so month-end or weekly batch peaks are less likely to be mistaken for idle. Memory-aware EC2 recommendations need CloudWatch agent memory metrics or supported external metric ingestion; CPU-only views overstate how far you can downsize.

Current supported recommendation families include EC2 instances, Auto Scaling groups, EBS volumes, Lambda, ECS services on Fargate, Aurora/RDS, NAT Gateway, and several other resources. Exact coverage changes; if the stem names a resource, check whether Optimizer actually speaks that language or whether you need Cost Explorer, Trusted Advisor, or a service-native recommendation (RDS Performance Insights, S3 Storage Lens).

Opt in from the management account to see member accounts. That is organizational visibility in support of Task 3.5, not a Task 1.5 showback design by itself.

Never apply an existing-fleet recommendation as the size of a new service. The new service has no 14-day curve. Size it from latency, concurrency, and storage requirements, then let Optimizer refine it after it runs.

Selecting the right size and Graviton for new solutions

Task 2.6 rightsizing is a design activity:

• Prefer current generation families unless a license or binary forces otherwise.
• Match memory-bound versus compute-bound versus burstable (T-family) to the access pattern. A chatty JVM that sits at 60 percent CPU is not a T-instance just because T looks cheap on the calculator.
• Treat AWS Graviton (ARM-based instance families such as the current C/M/R g and similar lines) as a first-class cost lever for Linux, containers, and Lambda when the software stack is compatible. Optimizer can later flag Graviton migrations on existing x86 fleets; for new Linux services, start on Graviton unless you have a measured x86 dependency (Windows AMIs, certain ISV binaries).
• Do not over-AZ-spread chatty, tightly coupled tiers without modeling inter-AZ data transfer (next section). Multi-AZ remains the HA default; the cost lever is reducing needless cross-AZ chatter, not abandoning HA.

Trusted Advisor cost checks still appear in Task 2.6/3.5 knowledge lists: idle load balancers, unassociated Elastic IP addresses, underused instances. They complement Optimizer; they do not replace Storage Lens for object storage.

S3 Storage Lens: existing object storage, org-wide

Amazon S3 Storage Lens is cloud-storage analytics across an account or, with Organizations, across the organization. A default dashboard updates daily and feeds the S3 console account snapshot. You can create additional dashboards scoped by Region, bucket, or account.

Free-tier metrics already support cost conversations: summary usage, whether buckets lack lifecycle rules, incomplete multipart uploads older than a week, versioning and encryption posture. The advanced tier (additional charge) adds prefix aggregation, richer activity metrics, contextual recommendations, and optional CloudWatch publishing.

Typical Task 3.5 findings: terabytes stuck in S3 Standard that should transition; incomplete multipart uploads that never complete yet still bill; noncurrent versions with no expiration; tiny-object prefixes that will never be cheaper until you compact them. Storage Lens tells you where. Lifecycle rules, Intelligent-Tiering, or an architecture change (compaction, S3 Express One Zone for a hot prefix, a different store) is what you do.

Storage Lens does not choose an EC2 family. Optimizer does not abort multipart uploads. Cost Explorer can show the S3 line item growing; Lens tells you which bucket and prefix.