EC2 Cost Optimization with Spot and ASGs

Build a cost-optimized ASG mixing On-Demand and Spot Instances.

Introduction

30 Second Summary

Every hour your cloud servers run, you're paying for compute. The difference between a well-optimized AWS bill and a wasteful one often comes down to how you purchase that compute in the first place.

In this project, you will build a cost-optimized Auto Scaling Group that mixes On-Demand Instances with Spot Instances, explore every EC2 purchasing option, and enable AWS Compute Optimizer for continuous right-sizing recommendations.

What You'll Build

A cost-optimized Auto Scaling architecture that combines On-Demand Instances as a stable base with Spot Instances for elastic overflow capacity, using the price-capacity-optimized allocation strategy.

By the end of this project, you'll have:

A Launch Template configured for multiple instance type flexibility, enabling your ASG to pick the cheapest available Spot pool.
A running Auto Scaling Group with a Mixed Instances Policy that keeps one On-Demand instance as a stable base and fills all additional capacity with Spot Instances.
Hands-on experience with every EC2 purchasing option that appears on the SAA-C03 exam, including Reserved Instances, Savings Plans, Dedicated Hosts, and Capacity Reservations.
Secret Mission: Create an On-Demand Capacity Reservation and launch an instance directly into it.

Are there any prerequisites?

You should be comfortable launching EC2 instances, working with instance types, and navigating the AWS Management Console. Familiarity with Launch Templates and basic VPC networking is also expected.

You will need an active AWS account with console access.

Create a Multi-Instance-Type Launch Template

Cost optimization on EC2 starts with flexibility. When your infrastructure can choose from multiple instance types, it can pick whichever option is cheapest or most available at any given moment.

In this step, you'll create a Launch Template that serves as the foundation for this flexibility. Later, your Auto Scaling Group will override the template's single instance type with multiple options to find the best price.

In this step, get ready to:

Create a Launch Template configured for cost optimization flexibility.
Verify the template is ready for use in later steps.
Understand how template design enables Spot Instance diversification.

Create the Launch Template

A Launch Template defines the base configuration for your instances. You'll set the AMI, instance type, and network settings once here, then reuse them across multiple launches.

Open the EC2 console by navigating to https://console.aws.amazon.com/ec2/ in your browser.
In the left navigation pane, choose Launch Templates.
Click Create launch template.

Now configure the template settings:

Enter spot-cost-lab-template in the Launch template name field.
Enter Base template for cost optimization lab in the Template version description field.
Under Application and OS Images (Amazon Machine Image), click Quick Start.
Select Amazon Linux, then choose the Amazon Linux 2023 AMI.
Under Instance type, select t3.micro.
Under Key pair (login), choose Don't include in launch template or select an existing key pair. You won't SSH into instances in this lab.
Under Network settings, do not include a subnet. The Auto Scaling Group will choose subnets later.
For Firewall (security groups), create a new security group or select one that allows no inbound traffic.
Leave the Advanced details section at its defaults.
Click Create launch template.

Why no inbound traffic?

This lab focuses on cost optimization concepts, not connecting to instances. Blocking all inbound traffic keeps your instances secure while you explore pricing models and Auto Scaling configurations.

Seeing an error when creating the template?

Make sure the template name contains only lowercase letters, numbers, and hyphens. Spaces or special characters will cause a validation error.

If you see a permissions error, confirm your IAM user has the ec2:CreateLaunchTemplate permission.

Help me troubleshoot my Launch Template creation error

Verify the Launch Template

After creation, AWS redirects you to a success page. Confirm everything is configured correctly before moving on.

Confirm the success page shows your template with status Success.
Note the Launch Template ID displayed on the page. You will use it in later steps.
Click the template name to open its details page.
Verify the AMI shows Amazon Linux 2023, the instance type shows t3.micro, and your security group is listed.

What is a Launch Template ID?

Every Launch Template gets a unique identifier that starts with lt- followed by a string of characters. Other AWS services reference your template by this ID when they need to launch instances with your saved configuration.

Understand why this template matters for cost optimization

You set a single instance type in this template. That might seem limiting, but the template is only the starting point.

How does one template enable multiple instance types?

In Step 3, you'll create a Mixed Instances Policy that overrides this template's instance type with multiple options: t3.micro, t3a.micro, and t2.micro. This gives the Auto Scaling Group flexibility to choose the cheapest available Spot Instance pool at launch time.

Instance type diversification across multiple pools is a key exam concept. It reduces Spot interruption risk because AWS is less likely to reclaim capacity across all pools simultaneously.

SAA-C03 exam connection

Domain 4 (Design Cost-Optimized Architectures) makes up 20% of the SAA-C03 scored content. Understanding how Launch Templates, instance type diversification, and Spot allocation strategies work together is directly testable.

Your Launch Template is ready. Next up, you'll launch a Spot Instance and explore how Spot pricing works in real time.

Launch a Spot Instance and Explore Spot Pricing

Your launch template is ready to go. Now it's time to see the most dramatic cost-saving option on AWS in action.

Spot Instances let you use spare EC2 capacity at up to 90% off the On-Demand price. The trade-off is that AWS can reclaim them with a 2-minute warning when it needs the capacity back. In this step, you will launch a Spot Instance, explore how Spot pricing works, and understand the interruption mechanism that makes Spot essential exam knowledge.

In this step, get ready to:

Launch a Spot Instance and observe its pricing behavior.
Explore the Spot pricing history graph for your region.
Understand the 2-minute interruption warning and when to use Spot.

Launch a Spot Instance via the EC2 console

You are going to launch a standalone Spot Instance to see firsthand how the purchasing option works and what it costs compared to On-Demand.

In the EC2 console navigation pane, choose Instances.
Click Launch instances in the top right.
Under Name and tags, enter spot-test-instance.
Under Application and OS Images, select Amazon Linux 2023 from the Quick Start tab.
Under Instance type, select t3.micro.
Under Key pair (login), choose the same key pair you used in Step 1 or select Proceed without a key pair.
Under Network settings, keep the default VPC selected and ensure Auto-assign public IP is enabled.
Expand the Advanced details section at the bottom of the page.
Under Purchasing option, check the Request Spot Instances checkbox.

What does checking Request Spot Instances do?

This tells AWS you want to use spare capacity at the current Spot price instead of the full On-Demand rate. The instance will launch at whatever the Spot market price is right now, which for t3.micro is typically 60-90% cheaper than On-Demand.

Leave the maximum price as the default (No maximum price). This means you pay the current Spot price and it will never exceed the On-Demand price.
For Request type, keep the default One-time. If the instance is interrupted, the request will not be resubmitted.
Click Launch instance.

Your Spot Instance launches at the current Spot price. You should see a success message confirming the instance is launching.

Why leave the maximum price blank?

AWS recommends not setting a maximum price. If you set one, your instance will be interrupted more frequently because AWS terminates it whenever the Spot price rises above your limit.

With no maximum, you simply pay the current Spot price (which is always below On-Demand). This gives you the lowest interruption rate.

Instance not launching?

If you see a capacity error, try a different Availability Zone in the Network settings section. Spot capacity varies by AZ.

If you see a permissions error, make sure your IAM user has the ec2:RunInstances and ec2:RequestSpotInstances permissions.

help me troubleshoot why my Spot Instance failed to launch

Explore Spot pricing history

Now that your Spot Instance is running, take a look at how Spot prices behave over time. This helps you understand price stability for different instance types and regions.

In the EC2 navigation pane, under Instances, choose Spot Requests.
Click Pricing history.
For Instance type, select t3.micro.
For Platform, select Linux/UNIX.
Keep the default date range and observe the pricing graph.

Hover over the graph to see prices at specific times. The top row shows the price on a specific date, and the second row shows the average over the selected range.

What should I notice in the pricing history?

For small instance types like t3.micro, Spot prices are remarkably stable. They rarely fluctuate because there is abundant spare capacity for these sizes. Larger and more specialized instance types (like GPU instances) show more price variation.

You can view up to 90 days of pricing history, filtered by instance type, operating system, and Availability Zone. This data helps you decide which instance pools are safest for Spot workloads.

Understand the 2-minute interruption warning

The critical exam concept behind Spot Instances is the interruption mechanism. When AWS needs capacity back, it does not terminate your instance without notice.

AWS sends a 2-minute interruption notice via the instance metadata endpoint at http://169.254.169.254/latest/meta-data/spot/instance-action.
An EventBridge event is also emitted, allowing automated responses (draining from a load balancer, checkpointing state).
After the 2-minute window, the instance is terminated (for one-time requests).

When should you use Spot Instances?

Spot is perfect for workloads that can tolerate interruptions: batch processing, CI/CD pipelines, stateless web workers, data analysis, and HPC simulations.

Never use Spot for databases, stateful session-based applications, or any workload that cannot gracefully handle a 2-minute shutdown notice.

SAA-C03 exam scenario

"A company runs batch processing and wants to reduce costs by 90%. The workload can tolerate interruptions." The answer is Spot Instances. The 2-minute warning, the up to 90% discount, and the fault-tolerant-only requirement are the three key signals.

Now that you have explored Spot pricing and understand the interruption mechanism, terminate the test instance to avoid unnecessary charges.

In the navigation pane, choose Instances.
Select the spot-test-instance checkbox.
Click Instance state, then Terminate (delete) instance.
Click Terminate (delete) to confirm.

The instance state changes to Shutting down and then Terminated. No further charges accrue once termination is complete.

Instance stuck in Shutting down?

This is normal. EC2 instances can take up to a few minutes to fully terminate. Refresh the page after 30 seconds and you should see the Terminated state.

help me understand why my instance is still shutting down

You now have first-hand experience with Spot pricing and the interruption model. Next, you will combine Spot and On-Demand instances in an Auto Scaling Group to build a cost-optimized architecture that balances reliability with savings.

Create an ASG with Mixed Instances Policy

You explored Spot pricing and saw how a single Spot Instance can save up to 90% compared to On-Demand. Now it is time to build something production-worthy.

A single Spot Instance can be interrupted at any time. The solution is to combine a stable On-Demand base with Spot overflow inside an Auto Scaling Group. In this step, you will create an ASG with a Mixed Instances Policy that guarantees one On-Demand instance while filling all additional capacity with Spot.

In this step, get ready to:

Create an Auto Scaling Group with a Mixed Instances Policy combining On-Demand and Spot.
Verify that one On-Demand and one Spot instance are running.
Understand the Spot allocation strategies tested on the SAA-C03 exam.

Create the Auto Scaling Group with mixed instances

A Mixed Instances Policy lets your ASG draw from multiple instance types and purchasing options. This diversifies your capacity across multiple Spot pools, reducing interruption risk.

In the EC2 console navigation pane, scroll down to Auto Scaling Groups.
Click Create Auto Scaling group.
Enter cost-lab-mixed-asg for the Auto Scaling group name.
Under Launch template, select spot-cost-lab-template.
Click Next.

You are now on the instance type requirements page. This is where you tell the ASG to use multiple instance types instead of just the one from your launch template.

Choose Override launch template.
Under Instance type requirements, choose Manually add instance types.
Add these three instance types: t3.micro, t3a.micro, and t2.micro.

Why three instance types?

Each instance type draws from a different Spot capacity pool. If one pool runs low on capacity (triggering interruptions), the ASG can pull from the other two pools instead.

Instance type diversification across multiple pools is a core exam concept for reducing Spot interruption risk.

Now configure how the ASG splits capacity between On-Demand and Spot.

Under Instance purchase options, set On-Demand base capacity to 1.
Set On-Demand percentage above base to 0%.
For Spot allocation strategy, select price-capacity-optimized.
Click Next.

What do these settings mean together?

On-Demand base capacity of 1 means the first instance the ASG launches is always On-Demand. On-Demand percentage above base of 0% means all additional capacity beyond that first instance uses Spot.

The result: 1 stable On-Demand instance as your baseline, and every scale-out instance is a cheap Spot Instance.

Next, configure the network and group size.

On the Network page, select your default VPC.
Select at least 2 subnets in different Availability Zones.
Click Next.
On the Load balancing page, leave the default (no load balancer). Click Next.
On the Group size page, set Desired capacity to 2.
Set Minimum capacity to 1.
Set Maximum capacity to 4.
Skip the scaling policies section (leave defaults).
Click through the remaining pages and choose Create Auto Scaling group.

Not seeing your launch template in the dropdown?

Make sure you are in the same region where you created spot-cost-lab-template. Check the region selector in the top-right corner of the console.

If the template still does not appear, navigate back to Launch Templates and confirm it shows with status "Success".

Help me troubleshoot why my launch template isn't showing in the Auto Scaling Group creation wizard.

Verify the mixed instances are running

After creation, click on cost-lab-mixed-asg in the Auto Scaling Groups list to open its details.
Click the Instance management tab.

You should see 2 instances launching. One will show as On-Demand and the other as Spot.

Navigate to Instances in the EC2 navigation pane.
If you do not see a Purchasing option column, click the gear icon in the top-right of the instances table to add it.
Confirm one instance shows on-demand and the other shows spot in that column.

What is OnDemandBaseCapacity doing here?

OnDemandBaseCapacity sets the minimum number of instances that must be On-Demand. These launch first as the group scales up.

OnDemandPercentageAboveBaseCapacity controls what percentage of additional capacity (above the base) is On-Demand versus Spot. Setting it to 0 means 100% of additional capacity is Spot.

Together with desired capacity of 2: the first instance is On-Demand (satisfying the base), the second is Spot (0% On-Demand above base).

Both instances showing On-Demand?

Double-check that you set the On-Demand percentage above base to 0, not 100. A value of 100 means all additional capacity is On-Demand.

Also verify the allocation strategy is set to price-capacity-optimized. If you need to fix settings, delete the ASG and recreate it with the correct values.

Help me figure out why my ASG isn't launching Spot instances.

Understand allocation strategies for the exam

The SAA-C03 exam tests your understanding of which Spot allocation strategy to recommend for different scenarios. There are three strategies to know.

price-capacity-optimized (recommended): Selects Spot pools with the lowest interruption risk AND the lowest price. This is the best overall strategy for most workloads.
capacity-optimized: Selects pools with the most available capacity (lowest interruption risk), ignoring price. Good when availability matters more than cost.
lowest-price: Picks the cheapest pools regardless of interruption risk. Not recommended because it leads to high interruption rates.

Exam scenario to remember

"A company wants to minimize Spot interruptions while keeping costs low in their ASG." The answer is the price-capacity-optimized allocation strategy. It balances both goals by looking at price and capacity together.

Why not always use lowest-price?

The cheapest Spot pools are cheap precisely because few people use them. When demand spikes, AWS reclaims that capacity first. You save a few cents per hour but face constant interruptions.

The price-capacity-optimized strategy finds pools that are both affordable and deep in capacity. This gives you stability without overpaying.

Your Mixed Instances ASG is live and running cost-optimized infrastructure. Next, you will explore all the other EC2 purchasing options that appear on the SAA-C03 exam, including Reserved Instances, Savings Plans, and Dedicated Hosts.

Explore All EC2 Purchasing Options

Your Mixed Instances ASG is running with On-Demand and Spot working together. Now it is time to zoom out and understand the full menu of EC2 purchasing options available to you.

Cost optimization on the SAA-C03 exam is not just about Spot. AWS offers seven distinct purchasing models, each designed for a specific workload pattern. Choosing the wrong one can mean overpaying by 90% or losing instances at the worst possible time.

In this step, get ready to:

Explore Reserved Instances and Savings Plans in the console.
Compare Dedicated Hosts vs Dedicated Instances.
Build a complete decision matrix mapping each purchasing option to a workload scenario.

Explore Reserved Instances and Savings Plans

Reserved Instances and Savings Plans both reward long-term commitment with large discounts. Understanding the console interface helps you see how these options are structured and how they differ.

In the EC2 console navigation pane, choose Reserved Instances.
Observe the interface. You can filter by instance type, term (1 or 3 year), and payment option (All Upfront, Partial Upfront, No Upfront).
Choose Purchase Reserved Instances to see the offering classes.
For Offering class, select Standard to see Standard RIs, then switch to Convertible to see Convertible RIs.
Do NOT purchase anything. You are only exploring the interface.

What are Reserved Instances?

Reserved Instances are billing discounts applied to running On-Demand instances that match the RI specifications. They are not physical instances you launch separately.

Standard RI: Up to 72% discount. Locked to a specific instance type, family, region, and OS. Cannot change attributes during the term.
Convertible RI: Up to 54% discount. Allows changing instance family, OS, and tenancy during the term.
Both require a 1-year or 3-year commitment.

Now navigate to Savings Plans by opening the Billing and Cost Management console. Type Savings Plans in the console search bar at the top.
In the Billing and Cost Management console, find Savings Plans in the navigation pane and choose Overview.
If you have no active Savings Plans, the page shows a summary of how Savings Plans work along with recommendations.

What are Savings Plans?

Savings Plans commit to a dollar-per-hour spend for 1 or 3 years. They automatically apply discounts to eligible usage without locking you to a specific instance type.

Compute Savings Plans: Up to 66% discount. Applies across EC2, Fargate, and Lambda. Most flexible option.
EC2 Instance Savings Plans: Up to 72% discount. Locked to a specific instance family in a region.

Savings Plans are the modern, preferred mechanism over Reserved Instances. You commit to a spend rate, and AWS automatically applies the discount to eligible usage.

Why Savings Plans over Reserved Instances?

Savings Plans offer more flexibility than RIs because they apply across services and instance families (for Compute Plans). On the exam, Savings Plans are the preferred answer for steady-state workloads unless the question specifically mentions needing capacity reservation or a locked instance type.

Explore Dedicated Hosts and Dedicated Instances

Some workloads need physical isolation from other AWS customers. AWS offers two levels of dedicated hardware, and the exam loves to test the difference between them.

Switch back to the EC2 console.
In the navigation pane, choose Dedicated Hosts.
Observe the empty list (you have no Dedicated Hosts allocated). Notice the Allocate Dedicated Host button at the top.
Do NOT allocate a Dedicated Host. They are significantly more expensive than shared tenancy.

What is the difference between Dedicated Hosts and Dedicated Instances?

A Dedicated Host is an entire physical server dedicated to your account. You control socket and core placement. This is required for per-socket or per-core software licenses (BYOL: Oracle, Windows Server with Software Assurance).

A Dedicated Instance runs on hardware not shared with other AWS accounts, but AWS chooses which physical host. You get isolation without socket or core visibility.

Exam trap: "Software licensed per physical CPU socket. Which option?" The answer is Dedicated Host, because you need visibility into physical socket counts. Dedicated Instances do not provide this.

Do not purchase Dedicated Hosts or Reserved Instances

This step is observation only. Dedicated Hosts cost significantly more than shared instances, and Reserved Instances require 1-3 year commitments. You are exploring the console interfaces to understand how they work for the exam.

Review the complete purchasing options decision matrix

Now that you have explored each option in the console, it is time to map them all into a single decision framework. This is the mental model you need for the exam.

On-Demand: No commitment, highest price. Use for unpredictable, short-term, or dev/test workloads.
Standard RI (1-3 year): Up to 72% off. Use for steady-state workloads where you know the exact instance type.
Convertible RI (1-3 year): Up to 54% off. Use for steady-state workloads where the instance type may change.
Compute Savings Plan (1-3 year): Up to 66% off. Most flexible. Use across EC2, Fargate, and Lambda.
EC2 Instance Savings Plan (1-3 year): Up to 72% off. Use for a specific instance family in a region.
Spot: Up to 90% off. Can be interrupted with 2-minute warning. Use only for fault-tolerant workloads.
Dedicated Host: Per-host billing. Use for BYOL compliance and physical isolation with socket control.
Dedicated Instance: Per-instance billing on isolated hardware. Use when you need isolation but not BYOL.
Capacity Reservation: Reserve capacity in a specific AZ. Pay On-Demand rate whether used or not. Use for disaster recovery or critical apps that must launch in a specific AZ.

How do I pick the right option on the exam?

Use this selection heuristic:

Steady-state production with predictable usage = Savings Plans or Reserved Instances.
Spiky or unknown demand = On-Demand.
Batch processing, CI/CD, or fault-tolerant workloads = Spot Instances.
BYOL software licensing compliance = Dedicated Hosts.
Must guarantee launch capacity in a specific AZ = Capacity Reservation.

You now have a complete mental model of every EC2 purchasing option. Next up, you will enable AWS Compute Optimizer to automatically recommend right-sizing opportunities across your account.

Enable AWS Compute Optimizer

You now have a complete picture of every EC2 purchasing option available on the exam. But choosing the right purchasing model is only half the cost story.

The other half is right-sizing. Even with Spot discounts, running an oversized instance wastes money every hour. AWS Compute Optimizer analyzes your actual utilization metrics and recommends optimal instance sizes. In this step, you will enable it and explore how it generates recommendations.

In this step, get ready to:

Opt in to Compute Optimizer for your AWS account.
Explore the dashboard and EC2 right-sizing recommendations.
Understand how Compute Optimizer appears on the SAA-C03 exam.

Opt in to Compute Optimizer

Compute Optimizer is a free service, but it requires an explicit opt-in before it starts collecting and analyzing your metrics.

Open the Compute Optimizer console by navigating to https://console.aws.amazon.com/compute-optimizer/ in a new browser tab.
If this is your first time, you will see a landing page. Click Get started.
On the Account setup page, choose to opt in for your account.
After opting in, you are redirected to the Compute Optimizer dashboard.

What happens when you opt in?

Opting in creates a Service-Linked Role that allows Compute Optimizer to read your CloudWatch metrics. It does not install anything or modify your instances.

Recommendations take up to 24 hours to appear because Compute Optimizer needs to analyze at least 14 days of CloudWatch metrics. If your instances are brand new, you will not see recommendations yet.

Don't see the Get started button?

If you land directly on the dashboard, your account may already be opted in from a previous session. You can continue to the next substep.

If you see a permissions error, make sure you are signed in with a user that has administrator access or the ComputeOptimizerFullAccess policy attached.

Help me troubleshoot my Compute Optimizer opt-in

Explore the dashboard and EC2 recommendations

The Compute Optimizer dashboard gives you a bird's-eye view of savings opportunities across multiple resource types. Let's explore what it surfaces.

In the Compute Optimizer navigation pane, choose Dashboard.
Observe the savings opportunity cards. The dashboard shows opportunities across EC2 instances, Auto Scaling groups, and EBS volumes.
In the navigation pane, choose EC2 instances.

What should I see on the EC2 instances page?

If you have instances that have been running for 14 or more days, you will see finding classifications: Over-provisioned, Under-provisioned, Optimized, or Not optimized.

Each recommendation shows up to 3 alternative instance types with estimated monthly savings and performance risk ratings. If you just launched your instances today, the page will be empty. That is expected.

If any instances appear, click one to see the detailed recommendation page. Note the current instance type, the recommended alternatives, and the projected cost difference.

Why do recommendations need 14 days of data?

Compute Optimizer uses CloudWatch metrics like CPU utilization, network throughput, and disk I/O collected over 14 days to understand your real usage patterns. A single day of data would not capture weekly traffic spikes or off-hours idle periods.

For memory-based recommendations, you need to install the CloudWatch agent on your instances. Memory utilization is not a default EC2 metric.

Understand Compute Optimizer for the exam

Compute Optimizer is a frequent answer on SAA-C03 questions about identifying cost waste. Here are the key facts you need to remember.

Compute Optimizer analyzes: EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, and ECS services.
Compute Optimizer does NOT generate recommendations for Spot Instances. It only right-sizes On-Demand and Reserved capacity.
For memory-based recommendations, you must install the CloudWatch agent. Without it, Compute Optimizer can only analyze CPU, network, and disk.

SAA-C03 exam scenarios

"A company wants to identify over-provisioned EC2 instances to reduce costs." Answer: AWS Compute Optimizer.

"A company needs to right-size instances based on actual utilization." Answer: AWS Compute Optimizer (analyzes 14 days of metrics by default).

Secret mission

Create an On-Demand Capacity Reservation

What if your workload absolutely cannot fail to launch? Capacity Reservations guarantee EC2 capacity in a specific Availability Zone. In this mission, you'll create one, launch an instance into it, and understand when guaranteed capacity matters for the exam.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The Auto Scaling Group is currently running two EC2 instances (one On-Demand, one Spot), which incur per-hour charges.

Cost warning

Your Auto Scaling Group is running 2 EC2 instances that cost money every hour they stay active. The On-Demand instance charges the standard hourly rate, and the Spot instance charges the current Spot price. Delete the ASG to stop all charges immediately.

Resources you used:

Auto Scaling Group cost-lab-mixed-asg with 2 running EC2 instances (1 On-Demand + 1 Spot).
Launch Template spot-cost-lab-template (no ongoing cost, but a resource in your account).
AWS Compute Optimizer (free service, no charges).

Keep everything running

No action needed. Choose this if you are still actively exploring EC2 purchasing options or want to observe your ASG behavior over time.

The ASG will continue running instances. On-Demand charges apply per hour, and Spot charges apply at the current Spot price.
Compute Optimizer will continue analyzing your account for free.
The Launch Template has no cost while stored.

Pause - I'll come back to this later

Stop the running instances to prevent charges, but keep the configuration for later use.

Delete the Auto Scaling Group to terminate all instances and stop charges (see Delete tab for steps). You can recreate it from the Launch Template later.
Keep the Launch Template spot-cost-lab-template in your account. It has no ongoing cost and saves your configuration.
Leave Compute Optimizer enabled. It will continue accumulating recommendations across your account for free.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below to ensure nothing is left running.

Delete the Auto Scaling Group: In the EC2 console, choose Auto Scaling Groups from the navigation pane. Select the checkbox next to cost-lab-mixed-asg. Choose Actions, then Delete. Type delete to confirm, then choose Delete. This terminates all instances in the group and stops all charges.
Terminate spot-test-instance (if still running): In the EC2 console, choose Instances. Look for spot-test-instance. If it exists, select it, choose Instance state, then Terminate instance. Confirm the termination.
Cancel any active Capacity Reservations: In the EC2 console, choose Capacity Reservations from the navigation pane. If any reservations show an active status, select them and choose Cancel Capacity Reservation. You are billed at the On-Demand rate for any active reservation.
Delete the Launch Template: In the EC2 console, choose Launch Templates from the navigation pane. Select spot-cost-lab-template. Choose Actions, then Delete template. Type Delete to confirm, then choose Delete.
Compute Optimizer: This is a free service. You can leave it enabled to continue generating right-sizing recommendations across your account at no cost.

That's a Wrap!

Nice work! You just built a cost-optimized Auto Scaling architecture on AWS that combines the reliability of On-Demand Instances with the savings of Spot Instances.

You now have hands-on experience with every EC2 purchasing model that appears on the SAA-C03 exam, plus a running Compute Optimizer setup that identifies savings opportunities across your account.

You've learned how to:

Create an Auto Scaling Group with a Mixed Instances Policy that uses On-Demand base capacity for stability and Spot overflow with the price-capacity-optimized allocation strategy for cost savings.
Launch a Spot Instance, explore real-time Spot pricing history, and understand the 2-minute interruption warning mechanism that makes Spot suitable only for fault-tolerant workloads.
Enable AWS Compute Optimizer to continuously analyze CloudWatch metrics and generate right-sizing recommendations for EC2 instances, Auto Scaling groups, and EBS volumes.
Secret Mission: Created an On-Demand Capacity Reservation, launched an instance into it, and understood when guaranteed capacity in a specific Availability Zone matters.

Ready to quiz yourself?