Optimize EC2 Costs with Spot Instances

Launch Spot Instances, create a Spot Fleet, and reserve EC2 capacity on AWS.

Introduction

30 Second Summary

Running servers in the cloud can get expensive fast. AWS offers several ways to pay less for the same computing power, but knowing which option to pick (and when) is one of the most valuable skills you can have as a cloud practitioner.

In this project, you will launch real Spot Instances, create a Spot Fleet that spreads capacity across multiple instance types, and reserve guaranteed compute capacity in a specific Availability Zone. These are the three core EC2 purchasing mechanisms tested on the AWS SAA-C03 exam.

What You'll Build

You will work through the three key hands-on components of EC2 cost optimization using the AWS Management Console, gaining real experience with Spot pricing, fleet allocation strategies, and capacity reservations.

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

A Spot Instance request with custom configuration, launched at up to 90% off On-Demand pricing.
A Spot Fleet spanning multiple instance types across Availability Zones using the price-capacity-optimized allocation strategy.
An On-Demand Capacity Reservation in a specific AZ, with a clear understanding of how it differs from Reserved Instances and Savings Plans.
Secret Mission: Create a mixed-instance Auto Scaling group combining On-Demand and Spot capacity, the current AWS best practice for production workloads.

Are there any prerequisites?

You need an active AWS account with permissions to launch EC2 instances and create Spot Fleet requests. This project is entirely console-based, so no CLI or SDK experience is required.

Navigate to EC2 and Explore Instance Purchasing Options

Before you launch any Spot Instances or create fleet requests, you need to orient yourself in the EC2 console. EC2 has multiple purchasing options hidden across different panels, and knowing where to find them is half the battle.

In this step, you will open the EC2 Dashboard in the correct region, locate the Spot-specific controls, and take a quick tour of how AWS presents its pricing models.

In this step, get ready to:

Open the EC2 Dashboard in the us-east-1 region.
Locate the Spot Requests section in the left navigation panel.
Review EC2 purchasing options in the Launch Instance wizard.

Open the EC2 Dashboard in us-east-1

All the resources in this project will live in the us-east-1 (N. Virginia) region. Setting the region first ensures every instance, fleet, and reservation you create ends up in the same place.

Sign in to the AWS Management Console.
In the top-right corner of the console, click the region dropdown.
Select US East (N. Virginia) us-east-1.
In the search bar at the top of the console, type EC2 and click EC2 from the results.

You should now see the EC2 Dashboard with a summary of your resources (instances, security groups, key pairs) in us-east-1.

Don't see the EC2 Dashboard?

Make sure you are signed in with an IAM user or role that has EC2 permissions. If your account uses SSO, confirm you selected the correct permission set.

Double-check that the region in the top-right corner says N. Virginia. Some browsers cache a different region from a previous session.

Help me access the EC2 Dashboard in us-east-1

Locate the Spot Requests section

The Spot Requests panel is where you will create Spot Instance requests, Spot Fleets, and view pricing history throughout this project.

In the left navigation panel, find the Instances section.
Click Spot Requests (listed under Instances).

You should see the Spot Requests page. It may show an empty table if you have never made a Spot request before. The important thing is that the page loads without a permissions error.

What are Spot Instances?

Spot Instances let you use spare EC2 capacity at up to 90% off the On-Demand price. The tradeoff is that AWS can reclaim (interrupt) your instance with a 2-minute warning when it needs the capacity back.

This makes Spot ideal for fault-tolerant or flexible workloads like batch processing, CI/CD builds, and data analysis. Workloads that cannot tolerate interruption should use On-Demand instead.

Review EC2 purchasing options in the Launch Instance wizard

AWS offers four main purchasing models for EC2. Seeing where they appear in the console helps you understand how they relate to each other.

Navigate back to the EC2 Dashboard by clicking Dashboard in the left panel (or click EC2 Dashboard at the top of the left panel).
Click the orange Launch instance button.
Scroll down to the Advanced details section at the very bottom and expand it.
Find the Purchasing option field. Notice the checkbox labeled Request Spot Instances. This is where you toggle between On-Demand (default) and Spot for a single instance.

Where do the four purchasing models live?

Here is how the four EC2 purchasing models map to the console:

On-Demand is the default when you launch any instance. You pay per second with no commitment.
Spot is toggled on under Advanced details > Purchasing option in the Launch Instance wizard. Up to 90% savings, but AWS can interrupt your instance.
Reserved Instances are purchased separately (left panel > Reserved Instances). They require a 1 or 3 year commitment for a billing discount.
Savings Plans are managed in the AWS Cost Explorer, not the EC2 console. They commit to a $/hr spend in exchange for a discount.

Do not launch an instance yet. Click Cancel at the bottom of the page to exit the wizard without creating anything.

Why does the SAA-C03 exam care about purchasing options?

Domain 4 of the SAA-C03 exam is "Design Cost-Optimized Architectures" and accounts for 20% of scored content. Questions test whether you can pick the right purchasing model for a given workload scenario.

The most common exam trap: a workload that "cannot be interrupted" should use On-Demand, not Spot, even though Spot is cheaper.

You are oriented in the EC2 console and know where each purchasing option lives. Next up, you will dive into Spot pricing history to see exactly how much you can save.

Analyze Spot Instance Pricing History

Before you launch a Spot Instance, you need to understand how Spot pricing works. Spot prices fluctuate based on long-term supply and demand for unused EC2 capacity in each Availability Zone.

In this step, you will explore the Spot pricing history in the AWS Console. You will compare prices across multiple instance types and Availability Zones to understand what a Spot capacity pool is and why it matters for cost optimization.

In this step, get ready to:

View Spot pricing history in the EC2 console.
Compare Spot prices across instance types and Availability Zones.
Identify the lowest-cost Spot capacity pool for t3.micro.

Open the Spot pricing history

The pricing history tool shows you how Spot prices have changed over time. This helps you pick instance types and Availability Zones that offer the most consistent savings.

In the left navigation panel, click Spot Requests under the Instances section.
Click the Pricing history button near the top of the page.

You should see a graph displaying Spot price trends. The default view shows pricing data for a specific instance type over a recent time period.

What is Spot pricing history?

Spot prices are updated every 5 minutes based on long-term supply and demand for unused EC2 capacity. The pricing history graph lets you see how stable or volatile prices have been for a given instance type.

Spot Instances can save you up to 90% compared to On-Demand pricing. For example, a t3.micro costs $0.0104/hr On-Demand in us-east-1. The Spot price is typically a fraction of that.

Compare prices across instance types and Availability Zones

Spot prices vary not just by instance type, but also by Availability Zone. Each combination of instance type and AZ forms a unique Spot capacity pool with its own price.

In the pricing history view, set the Instance type to t3.micro.
Set the date range to 3 months.
Observe the graph. Notice that each colored line represents a different Availability Zone in us-east-1.
Note which AZ shows the lowest price for t3.micro. Write this down for reference.
Change the Instance type to m5.large and observe how the price range differs from t3.micro.
Change the Instance type to c5.xlarge and observe the pricing pattern for this compute-optimized instance.

What is a Spot capacity pool?

A Spot capacity pool is a unique combination of an instance type and an Availability Zone. For example, t3.micro in us-east-1a is one pool, and t3.micro in us-east-1b is a different pool. Each pool has its own supply, demand, and price.

Spreading your workload across multiple capacity pools reduces your risk of interruption. This is exactly what Spot Fleet and allocation strategies handle for you automatically.

Identify the pricing pattern

Now that you have compared three instance types, look at what the graphs tell you about Spot pricing behavior.

Switch back to t3.micro in the pricing history view.
Look at the overall trend line. Notice that Spot prices adjust gradually based on long-term supply and demand, not sudden spikes.
Confirm which AZ consistently shows the lowest price for t3.micro over the 3-month period. This is the capacity pool where you would get the best deal for this instance type.

Why do prices differ between AZs?

Each Availability Zone has different amounts of unused capacity. An AZ with more spare t3.micro capacity will have a lower Spot price for that instance type. This is why diversifying across AZs and instance types is a best practice for Spot workloads.

Exam tip for SAA-C03

The SAA-C03 exam may reference Spot Blocks (defined-duration Spot Instances) as an answer option. Spot Blocks were fully retired in December 2022. The correct current answer for workloads that cannot be interrupted is to use On-Demand Instances.

You now know how to read Spot pricing trends and identify the cheapest capacity pools. Next up, you will launch your own Spot Instance and see it running in the EC2 console.

Launch a Spot Instance Request

You've seen how Spot Instance prices vary across instance types and Availability Zones.

Now it's time to actually launch one. You'll configure an EC2 instance to use Spot pricing and observe how the console reflects its lifecycle differently from a standard On-Demand instance.

In this step, get ready to:

Launch a Spot Instance named "spot-test" using the EC2 launch wizard.
Configure the Spot purchasing option with no maximum price set.
Verify that the instance lifecycle shows "spot" in the instance details.

Start the instance launch wizard

The EC2 launch wizard lets you configure all the settings for a new instance in one place. You'll start by setting the basics before enabling Spot pricing.

In the left navigation panel, click Instances to return to the main Instances page.
Click Launch instances (the orange button in the top right).
Under Name and tags, enter spot-test in the Name field.
Under Application and OS Images (Amazon Machine Image), confirm that Amazon Linux 2023 AMI is already selected. It should be the default.
Under Instance type, confirm that t3.micro is selected. If not, use the dropdown to search for and select it.

Enable the Spot purchasing option

The Spot purchasing option is tucked inside the Advanced details section at the bottom of the wizard. This is where you tell AWS to bid for spare capacity instead of paying On-Demand rates.

Under Key pair (login), select Proceed without a key pair (Not recommended) from the dropdown. You will not need to SSH into this instance.
Scroll all the way down to the Advanced details section and click it to expand.
Find the Purchasing option field near the top of the Advanced details section.
Check the box that says Spot to request a Spot Instance.
Leave the Maximum price field empty. This means you'll pay the current Spot price (up to the On-Demand price), which is the recommended practice.

Why leave the maximum price empty?

Setting no maximum price means your instance won't be interrupted just because the Spot price rises slightly. You'll pay whatever the current market rate is, up to the On-Demand price.

If you set a low max price, your instance gets terminated the moment Spot pricing exceeds your limit. AWS recommends against setting a max price for most workloads because it increases interruption frequency without meaningful savings.

Click Launch instance at the bottom right of the page.

You should see a green success banner confirming your instance is launching.

Verify your Spot Instance is running

Click View all instances from the success page (or navigate to Instances in the left panel).
Wait for the spot-test instance to show Running in the Instance state column. This may take 30-60 seconds.
Click on the instance ID to open its details page.
In the Details tab, look for the Lifecycle field. It should show spot instead of normal.
Scroll down to find the Spot Instance request field. Note the request ID (it starts with sir-) and confirm the status shows as fulfilled.

What does the Spot lifecycle tell you?

The Lifecycle field is how you confirm an instance is running on Spot capacity. An On-Demand instance shows normal. A Spot Instance shows spot.

This t3.micro Spot Instance costs approximately $0.003/hr compared to the On-Demand rate of $0.0104/hr. That's roughly a 70% discount for the same compute.

Instance not launching or stuck in pending?

If your Spot Instance request shows a status of capacity-not-available, that specific instance type is temporarily unavailable in your selected AZ. Cancel the request and try again. The t3.micro type in us-east-1 almost always has capacity, so this is rare.

If you don't see the Spot checkbox under Advanced details, make sure you scrolled all the way down past Network settings and Storage to reach the Advanced details section and expanded it by clicking on the header.

Help me troubleshoot my Spot Instance request that is not launching in us-east-1.

What about Spot Instance interruptions?

AWS can reclaim your Spot Instance when it needs the capacity back. You get a 2-minute warning before interruption, delivered via instance metadata and an EventBridge event.

For the SAA-C03 exam, remember that workloads which cannot tolerate interruption should use On-Demand, not Spot. Spot is ideal for batch processing, data analysis, CI/CD builds, and other fault-tolerant workloads.

You've launched a single Spot Instance and confirmed it's running at a fraction of the On-Demand cost. Next up, you'll create a Spot Fleet that spreads capacity across multiple instance types for even better availability and savings.

Create a Spot Fleet Request

You just launched a single Spot Instance and saw how it behaves differently from On-Demand. But in production, relying on one instance type in one Availability Zone is risky.

A Spot Fleet solves this by spreading your capacity across multiple instance types and AZs. If one pool gets interrupted, the fleet automatically pulls capacity from another pool. In this step, you will create a Spot Fleet that uses the price-capacity-optimized allocation strategy to balance cost and interruption risk.

In this step, get ready to:

Open the Spot Fleet creation wizard from the EC2 console.
Configure a fleet with 2 target instances using the price-capacity-optimized strategy.
Launch the fleet with multiple instance types and observe instances spread across AZs.

Open the Spot Fleet wizard

The Spot Fleet wizard lets you define a fleet of instances that AWS manages as a group. You tell it how much capacity you need, and it figures out the best way to fulfill that request across your chosen instance types.

In the left navigation panel, click Spot Requests (under Instances).
Click Request Spot Instances to open the Spot Fleet creation wizard.

Why Spot Fleet instead of EC2 Fleet?

AWS actually recommends EC2 Fleet or Auto Scaling groups over Spot Fleet for new workloads. However, EC2 Fleet does not have console support. It only works through the CLI or API.

Since this project is console-based, Spot Fleet is the practical choice. The SAA-C03 exam still tests Spot Fleet concepts, so this hands-on experience is directly relevant.

Configure the fleet settings

The wizard asks you to define what your workload needs and how the fleet should behave. These settings determine how AWS selects instance types and what happens if capacity is interrupted.

Under Tell us your application or task need, select Flexible workloads.
Set Total target capacity to 2.
Under Fleet request, select Maintain target capacity.
Under Fleet allocation strategy, select Price capacity optimized.

What do these settings mean?

Flexible workloads tells AWS your application can run on multiple instance types. This gives the fleet more options to find cheap, available capacity.
Maintain target capacity means AWS will automatically replace any instances that get interrupted, keeping your fleet at 2 instances.
Price capacity optimized is the AWS-recommended strategy. It picks instances from pools with the highest available capacity AND the lowest price. The lowest-price strategy is explicitly not recommended because it leads to higher interruption rates.

Select instance types and launch the fleet

By choosing multiple instance types, you give AWS more Spot capacity pools to draw from. This dramatically reduces the chance of all your instances being interrupted at once.

Under the instance type requirements section, select Manually select instance types.
Add the following three instance types: t3.micro, t3.small, and t3a.micro.
Review the fleet summary at the bottom. It shows estimated cost and how capacity will distribute across Availability Zones.
Click Launch.

Why these three instance types?

Each instance type in a given AZ forms a separate Spot capacity pool. By selecting t3.micro, t3.small, and t3a.micro, you give the fleet access to multiple pools. The price-capacity-optimized strategy then picks the pool with the best combination of availability and price.

After a few moments, your fleet will show as active. You should see 2 instances launching across your selected instance types and AZs.

Stay on the Spot Requests page and wait for the fleet status to show active.
Click on your fleet request ID to view its details.
Check the Instances tab to see which instance types and Availability Zones the fleet chose.

Fleet stuck in pending or showing errors?

If your fleet request shows an error, check that you selected at least one instance type. Also confirm you are in the us-east-1 region. Some regions have limited Spot capacity for certain instance types.

If instances take more than a minute to appear, refresh the page. The fleet may be waiting for capacity to become available in the pools you selected.

Help me troubleshoot my Spot Fleet request

Spot Fleet is legacy. What should you use instead?

AWS explicitly marks Spot Fleet as a legacy API with no planned investment. For new production workloads, AWS recommends EC2 Auto Scaling groups (for lifecycle management) or EC2 Fleet with the instant type (for one-time launches without auto scaling).

The SAA-C03 exam still tests Spot Fleet concepts. But if a question asks for the "best practice" or "recommended" approach, the answer is Auto Scaling groups with mixed instances. You will try this in the Secret Mission.

Your Spot Fleet is now running two instances across multiple capacity pools. Next up, you will explore On-Demand Capacity Reservations, which guarantee you can always launch an instance in a specific Availability Zone.

Create an On-Demand Capacity Reservation

So far you've explored the cost-saving side of EC2 purchasing with Spot Instances and Spot Fleet. Now it's time to look at the opposite end of the spectrum: guaranteeing that capacity is available when you need it.

An On-Demand Capacity Reservation locks in compute capacity in a specific Availability Zone so you can launch instances there at any time. The catch is that you pay the full On-Demand rate whether you actually use the reservation or not.

In this step, get ready to:

Create an On-Demand Capacity Reservation for a t3.micro instance.
Observe how a reservation works when no instances are using it.
Understand how Capacity Reservations differ from Reserved Instances on the SAA-C03 exam.

Navigate to Capacity Reservations

In the left navigation panel of the EC2 Dashboard, look under Instances.
Click Capacity Reservations.
Click Create Capacity Reservation.

Configure and create the reservation

A Capacity Reservation targets one specific instance type in one specific Availability Zone. You are telling AWS to hold that capacity exclusively for your account.

Set Instance type to t3.micro.
Set Platform to Linux/UNIX.
Under Availability Zone, select any single AZ in us-east-1 (for example, us-east-1a).
Set Quantity to 1.
Under Reservation ends, select Manually. This means the reservation stays active until you explicitly cancel it.
Click Create.

Cost warning

Your Capacity Reservation is now billing at the On-Demand rate of $0.0104/hr for t3.micro in us-east-1. You will cancel it in the next step to stop charges.

Observe the active reservation

Your reservation should now show a status of active with 0 running instances using it.

Confirm the State column shows active.
Check that Available instance count shows 1 and Used instance count shows 0.

This means AWS has reserved one t3.micro slot for you in that AZ. You can launch an instance there at any time, even during high-demand periods when others might get insufficient capacity errors.

Why would I pay for capacity I'm not using?

Capacity Reservations are designed for workloads that must launch in a specific AZ without any risk of "insufficient capacity" errors. Think of disaster recovery instances that need to spin up immediately, or compliance-sensitive workloads tied to a specific data center location.

You can combine a Capacity Reservation with a Regional Reserved Instance or Savings Plan. The reservation guarantees capacity, and the RI or Savings Plan provides the billing discount. This combination gives you both benefits.

What is the difference between Capacity Reservations and Reserved Instances?

This distinction is heavily tested on the SAA-C03 exam. Here is how the three options compare:

On-Demand Capacity Reservation guarantees capacity in a specific AZ. No billing discount. No term commitment.
Zonal Reserved Instance reserves capacity in a specific AZ AND provides a billing discount. Requires a 1 or 3 year term.
Regional Reserved Instance provides a billing discount across all AZs in the region with size flexibility within the instance family. No capacity guarantee.

Don't see the reservation as active?

Make sure you selected an Availability Zone that supports t3.micro instances. If the reservation failed, try a different AZ such as us-east-1a or us-east-1b.

help me troubleshoot my Capacity Reservation

You now have hands-on experience with all three EC2 purchasing mechanisms tested on the SAA-C03 exam. Next up, you will clean up every resource you created to stop all charges.

Clean Up All Resources

You have explored all three EC2 purchasing mechanisms and seen how they work in the console.

Every resource you created is actively billing you right now. The Capacity Reservation is the most urgent one to cancel because it charges the full On-Demand rate ($0.0104/hr for t3.micro) whether you use it or not. In this step, you will tear down everything cleanly.

In this step, get ready to:

Cancel the On-Demand Capacity Reservation.
Cancel the Spot Fleet request and terminate its instances.
Terminate the individual Spot Instance from Step 3.

Cancel the Capacity Reservation

The Capacity Reservation charges you at the On-Demand rate every second it remains active. Since you have confirmed how reservations work, it is time to release it.

In the EC2 left navigation panel, click Capacity Reservations (under Instances).
Select the checkbox next to your active reservation.
Click Actions, then select Cancel Capacity Reservation.
In the confirmation dialog, click Cancel Capacity Reservation to confirm.

The reservation status changes to cancelled. You are no longer being charged for reserved capacity.

Don't see the Cancel option?

Make sure you selected the reservation using the checkbox on the left side of the row. The Actions button stays grayed out until you select a resource.

Help me cancel my Capacity Reservation

Cancel the Spot Fleet request

Canceling a Spot Fleet without terminating its instances leaves them running and billable. You need to choose the option that terminates instances at the same time.

In the EC2 left navigation panel, click Spot Requests (under Instances).
Select the checkbox next to your Spot Fleet request.
Click Actions, then select Cancel Spot request.
When prompted, select Terminate instances so the fleet's running instances are also shut down.
Click Confirm.

The fleet request status changes to cancelled_running briefly, then to cancelled_terminating as instances shut down.

Why select Terminate instances?

If you cancel a Spot Fleet without terminating its instances, the instances keep running and billing you. They become orphaned EC2 instances with no fleet managing them. Always choose Terminate instances during cancellation unless you have a specific reason to keep them.

Fleet still showing as active?

It can take a minute or two for the fleet status to update. Click the refresh icon (circular arrow) in the top-right area of the Spot Requests table to check again.

Help me cancel my Spot Fleet

Terminate the individual Spot Instance

The spot-test instance you launched in Step 3 is separate from the Spot Fleet. You need to terminate it individually.

In the EC2 left navigation panel, click Instances.
Find and select the checkbox next to your spot-test instance.
Click Instance state in the top menu bar.
Select Terminate instance.
Click Terminate in the confirmation dialog.

Verify that all instances in the Instances list now show a status of Terminated or Shutting down. This includes the fleet instances and your spot-test instance.

Still see a running instance?

Check that you terminated instances from both the Spot Fleet cancellation and the individual spot-test instance. If a fleet instance is still running, it likely means you canceled the fleet without selecting Terminate instances. Select the running instance and terminate it manually using Instance state > Terminate instance.

Help me confirm all my instances are terminated

All billable resources are now gone

With the Capacity Reservation canceled, the Spot Fleet terminated, and the individual Spot Instance terminated, you have no remaining billable resources from this project. Terminated instances will disappear from your console within an hour.

Your cleanup is complete. You now have hands-on experience with all three EC2 purchasing mechanisms tested on the SAA-C03 exam.

Secret mission

Create a Mixed Instances Auto Scaling Group

Spot Fleet is legacy. The current AWS best practice for production workloads is an Auto Scaling group with mixed instances. Can you create one that combines On-Demand stability with Spot cost savings?

Clean Up Your Resources

This project uses AWS resources that are billed per second or per hour. If you completed Step 6, your resources are already cleaned up and you have no ongoing costs.

Cost warning

The Capacity Reservation is the highest-cost risk in this project. It charges the full On-Demand rate ($0.0104/hr for t3.micro) whether you use it or not.

If you skipped Step 6, go back and cancel all resources now. Leaving a Capacity Reservation active overnight costs more than the entire rest of this project combined.

Resources you used:

Spot Instance (Step 3): billed per second at the Spot rate (~$0.003/hr for t3.micro). No cost once terminated.
Spot Fleet (Step 4): 2 instances billed at the Spot rate. No cost once the fleet is canceled and instances are terminated.
Capacity Reservation (Step 5): billed at the full On-Demand rate ($0.0104/hr for t3.micro) whether used or not. No cost once canceled.
Auto Scaling Group (Secret Mission): 1 On-Demand + 2 Spot instances billed at their respective rates. No cost once the ASG is deleted.

Keep everything running

Not recommended for a learning exercise. Every resource in this project incurs ongoing charges while active.

Your Spot Instance is billed per second at the Spot rate.
Your Spot Fleet runs 2 instances billed at Spot rates.
Your Capacity Reservation charges the On-Demand rate continuously, even with zero instances using it.
If you completed the Secret Mission, your Auto Scaling group runs 3 instances (1 On-Demand + 2 Spot).

Pause - I'll come back to this later

These resources do not have a pause state. You cannot stop billing without fully deleting them.

Spot Instances cannot be paused. They can only be terminated.
Spot Fleets cannot be paused. You must cancel the request and terminate its instances.
Capacity Reservations cannot be paused. You must cancel them entirely.
If you want to redo this project later, follow the Delete tab instructions now and start fresh next time.

Delete - I don't want to use this again

Remove all project resources to stop all charges. If you already completed Step 6, your core resources are cleaned up.

Cancel the Capacity Reservation: go to EC2 > Capacity Reservations, select your reservation, click Actions, then Cancel Capacity Reservation.
Cancel the Spot Fleet: go to EC2 > Spot Requests, select your fleet request, click Actions, then Cancel Spot request. Choose Terminate instances when prompted.
Terminate the Spot Instance: go to EC2 > Instances, select your spot-test instance, click Instance state, then Terminate instance.
If you completed the Secret Mission: go to EC2 > Auto Scaling Groups, select your mixed-cost-optimization group, and delete it. Then go to Launch Templates and delete mixed-instance-template.
Verify all instances show Terminated or Shutting down status in your Instances list.

That's a Wrap!

Nice work! You just got hands-on with the three most-tested EC2 cost optimization tools on the SAA-C03 exam.

You've learned how to:

Launched a Spot Instance and analyzed real-time Spot pricing dynamics across instance types and Availability Zones.
Created a Spot Fleet with the price-capacity-optimized allocation strategy, distributing capacity across multiple instance types.
Created and canceled an On-Demand Capacity Reservation, understanding how it guarantees capacity without a billing discount compared to Reserved Instances and Savings Plans.
Secret Mission: Created a mixed-instance Auto Scaling group combining On-Demand base capacity with Spot overflow, the current AWS best practice for cost-optimized production workloads.

Ready to quiz yourself?