AWS re/Start Lab · Amazon EC2

Introduction to Amazon EC2

This report covers the full lifecycle of an EC2 instance: launching with a User Data script, monitoring its health, configuring firewall rules for HTTP access, resizing compute and storage resources, and testing termination protection as a safety mechanism.

Lab Summary

An EC2 instance named Web Server was created using Amazon Linux 2023, type t3.micro, with no key pair and a lab VPC. A User Data script automated Apache installation to serve a basic web page.

Initial Provisioning

Configured the instance name, AMI, instance type, network, storage, and User Data script to bootstrap a simple web server.

Operation & Access

Verified status checks, reviewed CloudWatch metrics, took an instance screenshot, and enabled HTTP traffic through an inbound security group rule.

Scaling & Protection

Stopped the instance to upgrade from t3.micro to t3.small, expanded the EBS volume from 8 GiB to 10 GiB, and validated termination protection behavior.

AWS Services Used

Each service played a specific role in the lab workflow.

Amazon EC2

Core service used to create the virtual machine that hosted the web server.

Amazon Machine Image (AMI)

Base OS template selected to launch the instance: Amazon Linux 2023.

Security Groups

Virtual firewall that controlled inbound traffic. The page was unreachable until HTTP on port 80 was allowed.

Amazon EBS

Persistent block storage attached to the instance. Its size was increased from 8 GiB to 10 GiB during the resize task.

Amazon CloudWatch

Source of monitoring metrics visible from the instance's Monitoring tab.

User Data & Termination Protection

User Data automated the web server installation at boot. Termination protection prevented accidental deletion during testing.

Step-by-Step Walkthrough

Detailed record of each task, with screenshots showing exactly what was configured at every step.

01

Launching the EC2 Instance

  • Opened the EC2 service and started creating a new instance. In the Name and tags section, the instance was named Web Server.
Name and tags configuration
Name and tags: Instance named "web server"
  • The default Amazon Linux 2023 AMI was kept as the base operating system, a modern, general-purpose Linux image optimized for AWS.
AMI Selection
AMI: Amazon Linux 2023 selected (Free tier eligible)
  • Selected t3.micro as the instance type (2 vCPU, 1 GiB memory). No key pair was configured since the lab didn't require SSH access.
Instance type and key pair
Instance type (t3.micro) and key pair (none) configuration
  • In Network settings, selected Lab VPC and created a new security group named Web Server security group. The default SSH inbound rule was removed to improve security.
Network settings
Network: Lab VPC, new security group, no inbound rules
  • The default 8 GiB gp3 root volume was kept as the boot disk for the instance.
Storage configuration
Storage: 8 GiB gp3 root volume (default)
  • Under Advanced details, Termination protection was enabled to prevent accidental deletion.
Termination protection enabled
Termination protection: Enabled
  • A User Data bash script was added to automatically install Apache, enable it on boot, and publish a basic HTML page.
User Data script
User Data: Bash script installing httpd and creating index page
  • The instance was launched successfully. AWS confirmed the creation with the instance ID.
Launch success
Launch: Successfully initiated, instance ID assigned
02

Monitoring the Instance

  • Verified the instance reached Running state. The Details tab showed the public IPv4 address, instance type (t3.micro), VPC, and subnet information.
Instance running
Instance running: Details tab with public IP and metadata
  • In the Status checks tab, all system, instance, and EBS checks passed, confirming the instance was fully operational.
Status checks passed
Status checks: System, Instance, and EBS checks all passed
  • The Monitoring tab displayed CloudWatch metrics including CPU utilization, network traffic (in/out), and packet counts.
CloudWatch monitoring
Monitoring: CloudWatch metrics (CPU, network, metadata)
  • Used Actions → Monitor and troubleshoot → Get Instance Screenshot to capture the console output. This is useful for diagnosing boot issues when SSH is unavailable.
Instance console screenshot
Instance Screenshot: Amazon Linux 2023 boot confirmation
Monitoring confirmed that a running instance still requires additional validation (status checks, metrics, console access) before it can be considered truly operational.
03

Updating the Security Group & Accessing the Web Server

  • Copied the Public IPv4 address and attempted to access the web server in a browser. The page failed to load because the security group had no inbound rule for HTTP traffic.
  • Navigated to Security Groups, selected the Web Server security group, and added an inbound rule: Type: HTTP, Source: Anywhere-IPv4 (0.0.0.0/0).
HTTP rule added
Security Group: HTTP inbound rule added (port 80, 0.0.0.0/0)
  • After saving the rule and refreshing the browser, the web page loaded successfully displaying "Hello From Your Web Server!"
Web server accessible
Browser: Web server responding with "Hello From Your Web Server!"
This step clearly demonstrated that deploying software inside an instance does not guarantee external access. Network rules and firewall policies must be explicitly configured. Security groups act as the gatekeeper.
04

Resizing the Instance Type and EBS Volume

  • The instance was stopped first, since resizing requires the instance to be in a stopped state. No charges apply for a stopped EC2 instance, but EBS storage costs remain.
Instance stopping
Instance state: Stopping initiated successfully
  • Via Actions → Instance Settings → Change Instance Type, the instance type was changed from t3.micro to t3.small, doubling the available memory from 1 GiB to 2 GiB.
Change instance type
Instance type: Changed from t3.micro (1 GiB) to t3.small (2 GiB)
  • Under Elastic Block Store → Volumes, the root volume was modified from 8 GiB to 10 GiB while keeping the gp3 type.
Modify EBS volume
EBS Volume: Modified from 8 GiB to 10 GiB (gp3, 3000 IOPS)
  • The instance was restarted with the new configuration, now with more compute power and more storage available.
05

Testing Termination Protection

  • Attempted to terminate the instance while termination protection was still enabled. AWS returned a red error message: "Failed to terminate. The instance may not be terminated."
Termination failed
Termination blocked: Red error banner confirms protection is active
  • Via Actions → Instance Settings → Change Termination Protection, the protection was disabled. The instance was then terminated successfully.
Termination sequence
Full sequence: Stop, failed terminate, protection removed, successful termination
This test highlighted the difference between having permission to perform an action and having the resource actually allow it based on its protection settings.

Key Learnings

What Was Actually Learned

✓
How to launch an EC2 instance with controlled, step-by-step configuration.
✓
How to automate boot tasks using User Data scripts.
✓
How to validate instance health through status checks and CloudWatch metrics.
✓
How Security Groups control real access to a service, not just deployment.
✓
How to scale compute and storage resources based on workload needs.
✓
How termination protection works as an operational safety layer.

Technical Conclusion

This lab covered the fundamental lifecycle of an EC2 instance: creation, configuration, monitoring, access control, resource modification, and secure termination. Beyond the console interface, the key takeaway was connecting each action to its operational impact: availability, security, scalability, and administrative control.

The most valuable lesson was understanding that a "running" instance is not the same as a "production-ready" instance. Proper network rules, monitoring, and protection mechanisms must be in place before an instance can be considered fully operational.