Creating Amazon EC2 Instances

Task 1: Launching an EC2 Instance Using the AWS Management Console

Step 1: Accessing the EC2 Console

1. I opened the AWS Management Console
2. In the Search bar, I entered "EC2"
3. I clicked on the EC2 option to open the Amazon EC2 Management Console
4. From the Launch instance dropdown list, I selected Launch instance to open the Launch an instance menu

Step 2: Naming My Instance

1. In the Name and tags section, I entered "Bastion host" for the Name
2. I learned that when naming an instance, AWS creates a key-value pair where "Name" is the key and my entered value becomes the value
3. This tagging helps categorize AWS resources by purpose, owner, or environment, which is useful when managing many resources

Step 3: Selecting an Amazon Machine Image (AMI)

1. In the Application and OS Images section, I confirmed that Amazon Linux was already selected
2. I kept this selection as it corresponded to Amazon Linux 2 AMI (HVM) according to the description
3. I noted that an AMI includes a template for the root volume, launch permissions, and block device mapping specifications

Step 4: Choosing an Instance Type

1. From the Instance type dropdown list, I searched for and selected t3.micro
2. I learned that this is a small instance type that can burst above baseline performance when busy
3. This instance type is suitable for development, testing, and applications with bursty workloads

Step 5: Setting Up Key Pair

1. In the Key pair (login) section, I clicked on the Key pair name dropdown list
2. I selected "Proceed without key pair (Not recommended)"
3. This was acceptable because I planned to use EC2 Instance Connect to log in instead of SSH keys

Step 6: Configuring Network Settings

1. In the Network settings section, I clicked Edit to modify the network configuration
2. From the VPC - required dropdown list, I selected Lab VPC (created during setup using CloudFormation)
3. I confirmed that Public Subnet was already selected in the Subnet dropdown list
4. I verified that Enable was selected in the Auto-assign public IP dropdown list
5. In the Firewall (security groups) section, I confirmed Create security group was selected
6. For Security group name, I entered "Bastion security group"
7. For Description, I entered "Permit SSH connections"
8. I learned that a security group acts as a virtual firewall controlling traffic for instances

Step 7: Configuring Storage

1. In the Configure storage pane, I reviewed the default settings
2. I kept the default 8 GiB disk volume configuration for my root volume

Step 8: Setting Advanced Details

1. I expanded the Advanced details pane by clicking on it
2. From the IAM instance profile dropdown list, I selected Bastion-Role
3. I learned this role grants permissions to applications on the instance to make requests to the EC2 service
4. I left all other settings at their default values

Step 9: Launching the Instance

1. In the Summary section, I carefully reviewed all my configuration details
2. After confirming everything was correct, I clicked Launch instance
3. Once the launch process began, I clicked View all instances to see my new EC2 instance

Task 2: Logging into the Bastion Host

Step 1: Connecting to My Instance

1. On the EC2 Management Console, I found my bastion host in the list of instances
2. I selected the checkbox next to my bastion host instance
3. I clicked the Connect button above the instance list
4. On the EC2 Instance Connect tab that appeared, I clicked Connect
5. I waited for the connection to establish, which opened a terminal session in my browser
6. I confirmed I was successfully connected to my bastion host and ready to use the AWS CLI

Task 3: Launching an EC2 Instance Using the AWS CLI

Step 1: Retrieving the Latest AMI

1. I entered the following script in my EC2 Instance Connect terminal:

2. I saw the script retrieve the Availability Zone using instance metadata
3. It then extracted the Region from the AZ and exported it as an environment variable
4. Using AWS Systems Manager, it retrieved the latest Amazon Linux 2 AMI ID
5. The AMI ID was stored in the AMI environment variable and displayed on screen
6. I made a note that if my session disconnected, I would need to re-run all these steps

Step 2: Retrieving the Subnet ID

1. I entered the following command to find the subnet ID:

2. This command used the aws ec2 describe-subnets command with a filter to find the public subnet
3. The subnet ID was stored in the SUBNET environment variable and displayed on screen

Step 3: Retrieving the Security Group ID

1. I ran the following command to find the security group ID:

2. This command used the aws ec2 describe-security-groups command with a filter for the WebSecurityGroup
3. The security group ID was stored in the SG environment variable and displayed on screen

Step 4: Downloading the User Data Script

1. I downloaded the user data script with this command:

2. To view the script contents, I ran:

3. I observed that the script would install a web server, download a web application zip file, and install the web application

Step 5: Launching the Web Server Instance

1. With all parameters gathered, I launched the instance using this command:

2. I saw that the command specified:
   • The AMI ID from Parameter Store
   • The subnet ID for the public subnet
   • The web security group ID allowing HTTP access
   • The user data script path for web server configuration
   • A t3.micro instance type
   • A Name tag with "Web Server" as the value
3. The command returned the new instance ID, which was stored in the INSTANCE environment variable

Step 6: Monitoring the Instance Status

1. To check all instance details, I ran:

2. This displayed comprehensive JSON information about my instance
3. To see just the instance state, I ran:

4. I saw that the status was initially "pending"
5. I continued running this command repeatedly until the status changed to "running"

Step 7: Testing the Web Server

1. To get my web server's public DNS name, I ran:

2. The command returned a DNS name similar to: ec2-35-11-22-33.us-west-2.compute.amazonaws.com
3. I copied this DNS name to my clipboard
4. I opened a new browser tab and pasted the DNS name into the address bar
5. I pressed Enter and waited for the page to load
6. I confirmed that the web page loaded successfully, showing that my web server was operational

Step 8: Verifying in the Console

1. I returned to the AWS Management Console browser tab
2. In the left navigation pane, I clicked on Instances
3. I clicked the refresh button to update the instance list
4. I confirmed that both my Bastion host and Web Server instances were now visible in the list
5. I noted that I had successfully launched instances using both the console and CLI methods

EC2 Instance Troubleshooting Experience

Challenge 1: Connecting to a Misconfigured EC2 Instance

Step 1: Identifying the Connection Problem

1. I attempted to connect to the "Misconfigured Web Server" instance (i-01093543ce5578180) using EC2 Instance Connect
2. The connection failed with an error
3. I checked the instance details to investigate the issue
4. I navigated to the Security tab for the instance
5. I examined the inbound rules for the attached security group (sg-079fcfbc5b88fb328 "Challenge-SG")
6. I discovered that only port 80 (HTTP) was allowed, with no rule permitting SSH connections on port 22

Step 2: Fixing the Security Group

1. I clicked on the security group name "Challenge-SG" to open its configuration
2. I selected the "Edit inbound rules" button
3. I clicked "Add rule" to create a new inbound rule
4. For Type, I selected SSH (TCP port 22)
5. For Source, I entered 0.0.0.0/0 to allow connections from any IP address
6. I clicked "Save rules" to apply the changes
7. I waited for the security group update to complete

Step 3: Verifying the Connection

1. I returned to the EC2 instances list
2. I selected the "Misconfigured Web Server" instance again
3. I clicked the Connect button to try EC2 Instance Connect again
4. This time, the connection established successfully
5. I confirmed I had a working terminal session to the instance

Challenge 2: Fixing the Web Server Installation

Step 1: Diagnosing the Web Server Problem

1. Using the public DNS name of the instance (ec2-34-212-57-170.us-west-2.compute.amazonaws.com), I tried to access the web server in my browser
2. The connection timed out, indicating the web server wasn't responding
3. In my SSH session to the instance, I first checked the operating system:

4. I confirmed the system was running Amazon Linux 2 (VERSION="2", PRETTY_NAME="Amazon Linux 2")
5. I checked if the Apache web server was installed:

6. The command returned an error indicating the service wasn't found
7. I concluded that the web server wasn't installed on the instance

Step 2: Installing and Configuring Apache

1. I updated the package lists first:

2. I installed the Apache web server package:

3. Once the installation completed, I started the web server service:

4. I configured the service to start automatically on boot:

5. I verified the service was running correctly:

6. The command showed the service was active and running

Step 3: Creating a Test Web Page

1. I created a basic HTML file using nano:

2. I added the following HTML content:

3. I saved the file by pressing CTRL+O, then ENTER, then CTRL+X to exit nano
4. I tested the web server locally:

5. The command returned the HTML content I had created, confirming the local web server was working

Step 4: Verifying External Access

1. I returned to my browser and refreshed the page with the instance's public DNS
2. The page loaded successfully, displaying "Web Server is Working!"
3. I confirmed that both the security group allowing HTTP traffic and the web server itself were now properly configured

Step 5: Additional Investigation

1. While troubleshooting, I also examined the Network ACL settings (acl-0b4207457e8c15c4e)
2. I noted its configuration with both allow and deny rules
3. I determined that the Network ACL wasn't causing the issues, as the security group rules were the primary problems that needed addressing