Launch and Configure an EC2 Instance

Launch an EC2 web server, explore the instance lifecycle, and create a custom AMI.

Introduction

30 Second Summary

Every website you visit and every app you open runs on a server somewhere. In the cloud, those servers are virtual machines you can launch, configure, and duplicate in minutes.

In this project, you will launch an EC2 instance on AWS, configure it as a web server using a bootstrap script, and create a reusable custom AMI that can spin up identical servers instantly.

What You'll Build

You will configure a fully functional EC2 web server, explore the instance lifecycle, and package your server into a custom AMI for repeatable deployments.

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

  • A running EC2 instance serving a custom web page, configured entirely through a user data bootstrap script that auto-installs Apache on launch.
  • An Elastic IP attached to your instance, giving it a static public address that survives stop/start cycles.
  • A custom AMI created from your configured instance, ready to launch identical pre-configured servers in seconds.
  • Secret Mission: Launch your custom AMI in a different Availability Zone and verify multi-AZ deployment readiness.

Are there any prerequisites?

You need an AWS account to complete this project. A free tier account is recommended, as it covers 750 hours per month of t2.micro instance usage for 12 months.

All work happens in the browser through the AWS Management Console. No local software installation is required.

Launch Your First EC2 Instance with User Data

Every application needs a server to run on. With EC2, you can launch a virtual server in the cloud in minutes, without buying or maintaining physical hardware.

In this step, you will launch your first EC2 instance, configure a security group to control network access, and write a bootstrap script that automatically installs a web server when the instance starts. By the end, you will have a live web page served from your own cloud server.

In this step, get ready to:
  • Launch an EC2 instance running Amazon Linux.
  • Configure a security group to allow SSH and HTTP traffic.
  • Write a user data script that installs and starts a web server automatically.
Navigate to the EC2 Console and launch a new instance

The EC2 launch wizard walks you through all the settings your instance needs. You will name it, pick an operating system image, choose a size, and create login credentials.

  • Open the EC2 Console by navigating to https://console.aws.amazon.com/ec2/ in your browser.
  • Click Launch instance on the EC2 dashboard.
  • Under Name and tags, enter MyWebServer in the Name field.
  • Under Application and OS Images (Amazon Machine Image), click Quick Start.
  • Select Amazon Linux.
  • From the AMI dropdown, pick an AMI marked Free tier eligible.
  • Under Instance type, select t2.micro (also marked Free tier eligible).
  • Under Key pair (login), click Create new key pair.
  • Enter my-ec2-key as the key pair name.
  • Select .pem for the private key file format.
  • Click Create key pair.

What just happened?

Your browser automatically downloaded a file called my-ec2-key.pem. This is your private key for SSH access to the instance.

AWS does not keep a copy of this private key. If you lose it, you cannot recover it. Save it somewhere safe on your computer.

What is an AMI?

An AMI (Amazon Machine Image) is a template that contains the operating system and software your instance launches with. Think of it as a snapshot that defines your server's starting state.

Configure security group and user data

A security group acts as a virtual firewall for your instance. You need to allow SSH so you can connect, and HTTP so the web server is accessible from a browser.

  • Under Network settings, click Edit.
  • In the Security group name field, replace the default name with WebServer-SG.
  • For the first inbound rule, set Type to SSH and Source to My IP.
  • Click Add security group rule.
  • Set the new rule's Type to HTTP, which auto-fills port 80.
  • Set Source to Anywhere (0.0.0.0/0).

Why allow HTTP from anywhere?

You want anyone on the internet to view your web page. SSH is restricted to your IP only because you are the only person who should be able to log into the server's command line.

Now you will add a bootstrap script. User data runs automatically when the instance first launches, so your web server installs itself without any manual SSH commands.

  • Expand Advanced details (scroll down in the launch wizard).
  • Scroll down to the User data text box at the bottom of the section.
  • Paste the following bootstrap script into the User data field:
#!/bin/bash
# Update all installed packages
yum update -y
# Install the Apache web server
yum install -y httpd
# Start the Apache service
systemctl start httpd
# Enable Apache to start on every boot
systemctl enable httpd
# Write a custom homepage that includes the instance hostname
echo "<h1>Hello from EC2 - $(hostname)</h1>" > /var/www/html/index.html

What does this script do?

  • yum update -y updates the operating system packages to their latest versions.
  • yum install -y httpd installs Apache, a popular web server.
  • systemctl start httpd and systemctl enable httpd start the web server now and ensure it restarts automatically if the instance reboots.
  • The final echo command writes a simple HTML page that displays the instance's hostname.
  • Still under Advanced details, find the Metadata version dropdown.
  • Confirm it is set to V2 only (token required).

What is IMDSv2?

IMDSv2 (Instance Metadata Service version 2) requires a session token before any metadata request. This prevents a class of attacks called SSRF (Server-Side Request Forgery) where malicious code tricks your instance into leaking metadata. You will explore metadata commands later in this project.

Launch and verify your instance

Your configuration is complete. Time to launch the instance and confirm the web server is live.

  • In the Summary panel on the right side of the wizard, review your settings.
  • Click Launch instance.
  • On the success page, click the instance ID link (it looks like i-0abc123...) to go to the Instances page.
  • Wait for Instance state to show Running and Status check to show 2/2 checks passed.
  • Select your instance and find the Public IPv4 address in the details panel below.
  • Copy the IP address and paste it into a new browser tab.

Status checks take 2-3 minutes

You can click the refresh icon in the Instances table while you wait. Both checks must pass before the web page will respond.

You should see a page that says "Hello from EC2" followed by your instance's hostname.

Not seeing the web page?

  • Make sure you are using http:// (not https://) in your browser. Your server does not have an SSL certificate.
  • Check that your security group has an HTTP rule on port 80 with source 0.0.0.0/0. Select your instance, click the Security tab, and verify the inbound rules.
  • If both status checks have not passed yet, wait another minute and refresh.

Help me debug why my EC2 web page is not loading.

Your instance is live and serving a web page. Next up, you will explore EC2 instance types and practice the full instance lifecycle to understand what happens to your public IP when you stop and start the server.

Explore Instance Types, Lifecycle, and Monitoring

Your web server is live and serving traffic. Now it is time to understand the machine running underneath it.

EC2 instances have a lifecycle: you can stop, start, reboot, and terminate them. Each action has consequences for your public IP address, which is a heavily tested topic on the SAA-C03 exam. In this step, you will practice the full lifecycle and observe exactly what changes at each stage.

In this step, get ready to:
  • Review EC2 instance type families and what workloads they serve.
  • Stop, start, and reboot your instance to observe IP address behavior.
  • View CloudWatch basic monitoring metrics for your instance.
Understand instance types

EC2 offers dozens of instance types grouped into families. Each family is optimized for a specific type of workload. The SAA-C03 exam expects you to know which family fits which scenario.

  • Return to the Instances page in the EC2 Console.
  • Select your MyWebServer instance by clicking its checkbox.
  • Click the Instance type tab in the details panel below.
  • Note the instance type t2.micro. This is a burstable, general purpose instance from the T family.

What are the key instance families for the SAA-C03?

The exam tests your ability to choose the right instance family for a given workload. Here are the ones you need to know:

  • t = burstable general purpose (low baseline CPU with burst credits for spikes).
  • m = general purpose (balanced compute, memory, and networking).
  • c = compute optimized (CPU-heavy workloads like batch processing).
  • r = memory optimized (in-memory databases, caching).
  • i = storage optimized (high IOPS for data-intensive workloads).
  • p/g = accelerated computing (GPU for machine learning and graphics).

Your t2.micro is a T-family instance. It earns CPU credits when idle and spends them during bursts. Perfect for low-traffic web servers and development environments.

Practice the instance lifecycle

When you stop and start an EC2 instance, AWS releases your public IPv4 address back to its pool. When the instance starts again, it gets a brand new public IP. This catches many people off guard in production.

Let's prove this behavior by stopping and restarting your instance, then comparing the IP addresses.

  • Before you stop anything, note your current Public IPv4 address shown in the instance details panel. Write it down or remember it.
  • Select your MyWebServer instance.
  • Click Instance state in the top menu bar.
  • Choose Stop instance, then click Stop to confirm.

The Instance state changes to stopping and then stopped. Look at the Public IPv4 address field. It is now empty. The IP has been released back to AWS.

  • With your instance still selected, click Instance state again.
  • Choose Start instance.
  • Wait for the Instance state to return to running.

Check the Public IPv4 address again. It is a different IP than before. However, your Private IPv4 address has stayed the same throughout.

Why does the public IP change?

AWS manages a pool of public IPv4 addresses. When you stop an instance, your public IP returns to that pool so someone else can use it. When you start again, you get a fresh one from the pool.

Your private IP never changes because it belongs to your VPC subnet and is reserved for your instance as long as it exists. In the next step, you will attach an Elastic IP to solve the disappearing public IP problem.

Now let's test what happens on a reboot.

  • Note your current public IPv4 address.
  • Click Instance state.
  • Choose Reboot instance, then confirm.
  • Wait about 30 seconds, then refresh the Instances page.

The public IPv4 address is still the same. A reboot does not release the IP because the instance never fully stopped.

SAA-C03 exam tip: IP behavior summary

  • Stop/Start: public IP changes. Private IP stays the same.
  • Reboot: public IP stays the same. Private IP stays the same.
  • Terminate: everything is released. The instance is gone.

Instance stuck in stopping state?

It can take a minute or two for an instance to fully stop. Refresh the page by clicking the refresh icon near the top of the Instances table. If it remains stuck for more than 5 minutes, try a force stop via Instance state > Stop instance > check Force stop.

Help me troubleshoot my EC2 instance state

View CloudWatch basic monitoring

Every EC2 instance automatically sends metrics to CloudWatch. Basic monitoring reports data every 5 minutes at no extra cost. Let's see what metrics are available.

  • Select your MyWebServer instance on the Instances page.
  • Click the Monitoring tab in the details panel below.

You should see several graphs with metric data. The main metrics to observe are CPUUtilization, NetworkIn, NetworkOut, DiskReadOps, and StatusCheckFailed.

Basic monitoring vs detailed monitoring

Basic monitoring reports metrics every 5 minutes and is free. Detailed monitoring reports every 1 minute but costs extra.

For the SAA-C03, remember that CloudWatch basic monitoring is enabled by default for all EC2 instances. You only enable detailed monitoring when you need higher-resolution data for auto-scaling decisions or alerting.

Gaps in the graphs are normal

You will see gaps in the monitoring graphs during the time your instance was stopped. CloudWatch cannot collect metrics from a stopped instance, so that period simply has no data points.

You now understand EC2 instance families and have seen firsthand how the lifecycle affects your public IP. Next up, you will solve the disappearing IP problem with an Elastic IP and explore instance metadata using IMDSv2.

Attach an Elastic IP and Explore Instance Metadata

In the last step, you saw a key problem first-hand: every time you stop and start your instance, AWS gives it a brand new public IP address. In the real world, your users, DNS records, and firewall rules all rely on a consistent address.

An Elastic IP solves this by giving you a static public IPv4 address that stays attached through stop/start cycles. You will also connect to your instance and query its metadata using IMDSv2, which lets an instance learn about itself without making external API calls.

In this step, get ready to:
  • Allocate an Elastic IP and associate it with your instance.
  • Connect to your instance and query metadata using IMDSv2 commands.
  • Understand why IMDSv2 is the secure choice for the SAA-C03 exam.
Allocate and associate an Elastic IP

An Elastic IP is a static public IPv4 address that you own until you release it. Unlike the default dynamic IP, it stays the same even when you stop and restart your instance.

  • In the EC2 navigation pane on the left, expand Network and Security and choose Elastic IPs.
  • Click Allocate Elastic IP address.
  • Leave all settings at their defaults and click Allocate.

You should see a green banner confirming the allocation with a new IP address displayed.

What is an Elastic IP?

An Elastic IP (EIP) is a public IPv4 address that AWS reserves for your account. It does not change when you stop and start an instance.

You can associate it with any instance in the same region, or move it to a different instance if one fails. This makes it useful for DNS records and failover scenarios.

  • Select the new Elastic IP address in the list.
  • Choose Actions > Associate Elastic IP address.
  • For Resource type, choose Instance.
  • In the Instance field, select your MyWebServer instance.
  • Click Associate.

A green banner confirms the association. Your instance now has a permanent public address.

Why not just use the default public IP?

The default public IP is drawn from a shared pool and returned when you stop the instance. If your DNS record points at that IP and it changes, your users lose access until you update the record.

An Elastic IP stays with your account until you explicitly release it, giving you control over addressing across stop/start cycles.

Now let's prove the Elastic IP survives a stop/start cycle.

  • In the navigation pane, choose Instances.
  • Select your MyWebServer instance.
  • Choose Instance state > Stop instance and confirm.
  • Wait for the state to show Stopped.
  • Choose Instance state > Start instance.
  • Once the instance is Running again, check the Public IPv4 address column.

The IP address is the same Elastic IP you associated earlier. Before you had an Elastic IP, stopping and starting gave you a different address every time.

Cost warning

Elastic IPs cost $0.005 per hour whether in-use or idle. The free tier includes 750 hours per month of in-use public IPv4 address usage. You will release this Elastic IP in the Before You Go section to avoid ongoing charges.

IP address still changed after stop/start?

Make sure the Elastic IP is associated with your instance, not just allocated. Go to Elastic IPs and check the Associated instance ID column shows your instance.

If the column is empty, select the Elastic IP, choose Actions > Associate Elastic IP address, and associate it to MyWebServer.

Still stuck? Why is my Elastic IP not staying associated with my instance after a stop/start?

Connect and query instance metadata with IMDSv2

Every EC2 instance can query a special internal endpoint to learn about itself. This is the Instance Metadata Service, and it provides details like instance ID, instance type, and public IP without needing any external API call.

  • In the navigation pane, choose Instances.
  • Select your MyWebServer instance.
  • Click the Connect button at the top of the page.
  • Choose the EC2 Instance Connect tab.
  • Click Connect.

A browser-based terminal opens, giving you SSH access to your instance. No local SSH client or key file is needed.

What is EC2 Instance Connect?

EC2 Instance Connect is a browser-based SSH terminal built into the AWS Console. It handles key generation and distribution automatically, so you can connect without configuring a local SSH client.

Your security group already allows SSH on port 22, which is the only requirement for this to work.

  • Retrieve a metadata session token and query the metadata root by running these commands in the terminal:
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

What does this command do?

The first line requests a session token from the metadata service. The token is valid for 21600 seconds (6 hours).

The second line uses that token to list all available metadata categories. You should see a list of paths like ami-id, instance-id, instance-type, and more.

  • Query specific metadata values by running these commands:
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-type
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id

What should I see?

  • instance-id returns something like i-0abc123def456.
  • instance-type returns t2.micro.
  • public-ipv4 returns your Elastic IP address. Compare it with the Elastic IP shown in the Console. They should match.
  • ami-id returns the Amazon Machine Image ID used to launch your instance.

Seeing a 401 Unauthorized or empty response?

Make sure you ran the TOKEN= line first. The token must be stored in the TOKEN variable before you can use it in subsequent requests.

If you closed and reopened the terminal, the variable is lost. Run the TOKEN= command again to get a fresh token.

Need more help? Why am I getting an error when querying instance metadata with IMDSv2?

Understand why IMDSv2 matters for the exam

The SAA-C03 exam tests your understanding of why IMDSv2 is the recommended approach for querying instance metadata. Here is the key difference between the two versions.

What is the difference between IMDSv1 and IMDSv2?

IMDSv1 lets anyone on the instance query metadata with a simple GET request. No authentication is needed. This means an attacker who tricks your application into making a request to 169.254.169.254 (a Server-Side Request Forgery attack) can steal IAM role credentials from metadata.

IMDSv2 requires a session token obtained via a PUT request before any metadata can be read. SSRF attacks typically cannot issue PUT requests, so the token requirement blocks them. AWS recommends enforcing IMDSv2 only on all instances.

What can the metadata service tell an instance?

  • Instance identity (ID, type, AMI, placement).
  • Network info (public IP, private IP, hostname, security groups).
  • IAM role credentials (temporary credentials for AWS API calls without hardcoding keys).
  • User data (the bootstrap script you wrote in Step 1).

All of this is available locally without external API calls. For the exam, remember that IAM role credentials exposed through metadata are the primary reason to enforce IMDSv2.

Your instance now has a fixed public address and you have seen how it can query its own identity securely. Next up, you will create a custom AMI from this fully configured instance so you can launch identical servers instantly.

Create a Custom AMI

In the last step, you attached an Elastic IP for static addressing and queried instance metadata using IMDSv2. Your instance is now fully configured with Apache, a custom web page, and a stable public IP.

What if you need a second server with the exact same setup? Manually repeating every installation step is slow and error-prone. In this step, you will create a custom AMI that packages your entire server configuration into a reusable template.

In this step, get ready to:
  • Create an AMI from your running MyWebServer instance.
  • Monitor the AMI creation process and understand how it stores your configuration.
  • Launch a brand new instance from your AMI to prove it works without any manual setup.
Create the AMI from your running instance

An AMI is a snapshot of your entire server. It captures the operating system, installed software, configuration files, and data. Once created, you can launch identical copies of your server from that single template.

  • In the EC2 navigation pane, choose Instances.
  • Select the checkbox next to your MyWebServer instance.
  • Choose Actions, then Image and templates, then Create image.
  • For Image name, enter MyWebServer-AMI.
  • For Image description, enter Amazon Linux with Apache pre-installed.
  • Leave the Reboot instance checkbox selected (this is the default).
  • Click Create image.

Why does the instance reboot?

When the Reboot instance checkbox is selected, EC2 reboots your instance before taking snapshots of the attached volumes. This ensures all buffered data in memory is written to disk first, giving you a consistent filesystem image.

If you uncheck this option, you get a crash-consistent snapshot instead. That means only data already written to disk at that exact moment is captured. For production workloads, always leave reboot enabled.

Don't see the Create image option?

Make sure your MyWebServer instance is selected (checkbox is checked). The Actions menu options change based on whether an instance is selected.

help me find the Create image option in the EC2 console

Monitor AMI creation and understand what happened

Creating an AMI takes a few minutes because EC2 is taking an EBS snapshot of each volume attached to your instance. Let's check the progress.

  • In the EC2 navigation pane, choose Images, then AMIs.
  • Find your MyWebServer-AMI in the list.
  • Observe the Status column. It will initially show pending, then change to available after a few minutes.
  • Wait until the status shows available before proceeding.

What happened behind the scenes?

Creating an AMI triggers an EBS snapshot of each attached volume. The AMI itself is a template that points to those snapshots. When you launch a new instance from this AMI, EC2 creates fresh EBS volumes from the snapshots and attaches them to the new instance.

AMIs are region-specific. Your MyWebServer-AMI only exists in the region where you created it. To use it in another region, you would need to copy it using Actions then Copy AMI. This is a common SAA-C03 exam topic.

Launch a new instance from your custom AMI to verify it works

The real test of an AMI is whether a fresh instance comes up fully configured with zero manual work. Let's prove it.

  • In the AMIs page, select your MyWebServer-AMI (status must be available).
  • Click Launch instance from AMI.
  • Under Name and tags, enter MyWebServer-FromAMI.
  • Under Instance type, keep t2.micro selected.
  • Under Key pair (login), select your existing key pair my-ec2-key.
  • Under Network settings, click Edit.
  • For Firewall (security groups), choose Select existing security group and pick WebServer-SG.
  • Do NOT add any user data. The AMI already has everything installed.
  • Click Launch instance.

Why no user data this time?

User data scripts run only on the first boot of an instance (via cloud-init). Your original MyWebServer already ran its bootstrap script, which installed Apache and created the web page. The AMI captured that fully configured state. A new instance launched from this AMI already has Apache installed and running with your custom index.html in place.

  • Click the instance ID link to go to the Instances page.
  • Wait for Instance state to show running and Status check to show 2/2 checks passed.
  • Copy the Public IPv4 address of your new MyWebServer-FromAMI instance.
  • Paste it into a new browser tab.

You should see the same web page showing "Hello from EC2" followed by the hostname. The hostname will be different from your original instance, but the page content proves the AMI captured your full configuration.

This is immutable infrastructure in action

You just proved that your AMI is a complete, reusable server template. In production, teams use this pattern to create "golden images" that can spin up pre-configured servers in seconds. This is the foundation for Auto Scaling groups, blue-green deployments, and disaster recovery. All heavily tested on the SAA-C03.

Web page not loading from the new instance?

Make sure you selected the WebServer-SG security group when launching. Without the HTTP inbound rule on port 80, browser requests will be blocked.

Also confirm the instance state shows running and both status checks have passed. If it still shows initializing, wait another minute.

help me troubleshoot why my instance launched from a custom AMI is not serving the web page

Secret mission

Multi-AZ Launch from Your Custom AMI

Can you prove your custom AMI works across Availability Zones? Launch a third instance in a different AZ and use IMDSv2 to verify its placement. This is the foundation of multi-AZ resilience that the SAA-C03 tests heavily.

Clean Up Your Resources

Clean Up Your Resources

This project uses AWS resources that may incur small charges if left running. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Your Elastic IP costs $0.005 per hour whether in-use or idle. If you are outside the AWS Free Tier's 750 hours per month of public IPv4 usage, this charge applies immediately.

EC2 instances (t2.micro) and EBS volumes (up to 30 GB) are covered by the Free Tier for 12 months. If you are outside this window, stop or terminate your instances to avoid compute charges.

Resources you used:

  • 3 EC2 instances (MyWebServer, MyWebServer-FromAMI, MyWebServer-MultiAZ).
  • 1 Elastic IP address associated with MyWebServer.
  • 3 EBS volumes (8 GB gp3 each, one per instance).
  • 1 custom AMI (MyWebServer-AMI) and its backing EBS snapshot.
  • 1 security group (WebServer-SG) and 1 key pair (my-ec2-key).

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with your instances.

  • Your t2.micro instances are covered by the Free Tier (750 hours per month total across all instances) if your account is within 12 months.
  • Your Elastic IP will continue charging $0.005 per hour beyond the Free Tier's 750 hours per month of in-use public IPv4 usage.
  • Your EBS volumes are covered by the Free Tier (30 GB total) if your account is within 12 months.
  • The AMI and snapshot incur minimal storage costs (approximately $0.05 per GB per month).

Pause - I'll come back to this later

Stop your instances to avoid compute charges while keeping your files and configuration intact. Release the Elastic IP if you plan to pause for more than a day.

  • In the EC2 Console, go to Instances.
  • Select all three instances (MyWebServer, MyWebServer-FromAMI, MyWebServer-MultiAZ).
  • Choose Instance state > Stop instance and confirm.
  • EBS volumes remain attached and continue to count toward the Free Tier's 30 GB limit while instances are stopped.
  • If pausing long-term, release the Elastic IP to avoid its hourly charge. Navigate to Network and Security > Elastic IPs, select your IP, choose Actions > Release Elastic IP addresses.

Delete - I don't want to use this again

Remove all project resources completely. Follow these steps in order.

Terminate all EC2 instances
  • In the EC2 Console, go to Instances.
  • Select all three instances (MyWebServer, MyWebServer-FromAMI, MyWebServer-MultiAZ).
  • Choose Instance state > Terminate (delete) instance and confirm.
  • The attached EBS volumes will be deleted automatically (Delete on Termination is enabled by default).
Release the Elastic IP
  • In the left navigation pane, choose Network and Security > Elastic IPs.
  • Select your Elastic IP address.
  • Choose Actions > Release Elastic IP addresses and confirm.
Deregister the AMI
  • In the left navigation pane, choose Images > AMIs.
  • Select MyWebServer-AMI.
  • Choose Actions > Deregister AMI and confirm.
Delete the EBS snapshot
  • In the left navigation pane, choose Elastic Block Store > Snapshots.
  • Select the snapshot created by your AMI.
  • Choose Actions > Delete snapshot and confirm.
Delete the security group and key pair
  • In the left navigation pane, choose Network and Security > Security Groups.
  • Select WebServer-SG, choose Actions > Delete security groups and confirm.
  • In the left navigation pane, choose Network and Security > Key Pairs.
  • Select my-ec2-key, choose Actions > Delete and confirm.
  • Delete the my-ec2-key.pem file from your local Downloads folder.

Nice Work!

Nice Work!

You just launched, configured, and cloned an EC2 instance from scratch. You now have hands-on experience with the full EC2 lifecycle and a custom AMI that can spin up pre-configured web servers in seconds.

Here's what you accomplished:

  • Launched an EC2 instance with a user data bootstrap script that automatically installed and configured Apache as a web server on first boot.
  • Practiced the full instance lifecycle (launch, stop, start, reboot, terminate), attached an Elastic IP for static addressing, and queried instance metadata securely using IMDSv2.
  • Created a custom AMI from your configured instance and launched a new server from it, proving you can build reproducible, reusable server templates.
  • Secret Mission: Deployed your AMI across multiple Availability Zones, proving multi-AZ deployment readiness for high availability.

Ready to quiz yourself?