DEV Community: THARUN REDDY R

Automating a Multi-Tier Web App on AWS with Terraform and Ansible: Triumphs and Challenges

THARUN REDDY R — Tue, 03 Jun 2025 16:22:34 +0000

As part of my journey to master cloud computing and DevOps, I recently tackled an advanced project: deploying a fully automated multi-tier web application on AWS using Terraform for infrastructure provisioning and Ansible for server configuration. This project built on my previous experience with AWS, pushing me to embrace infrastructure as code (IaC) and automation. Despite numerous challenges, including a critical misconfiguration in my Terraform variables, I successfully deployed a secure, monitored web application. In this blog post, I’ll share what I accomplished, the hurdles I faced, how I overcame them, and the lessons that will shape my future projects.

Project Objectives

The goal was to create a scalable, secure multi-tier web application on AWS with the following components:

Terraform: Provision a Virtual Private Cloud (VPC), public and private subnets, EC2 instances, security groups, and IAM roles.
Ansible: Configure a web server with Nginx and PHP, and a database server with MariaDB, deploying a PHP application that connects to the database.
Enhancements:
- Set up AWS CloudWatch to monitor CPU usage.
- Store Terraform state remotely in an S3 bucket for consistency.
- Implement a unit test to verify the web application’s functionality.

The final deliverable was a working web application accessible via the web server’s public IP, with the database securely isolated in a private subnet, all provisioned and configured automatically.

Step-by-Step Accomplishments

Here’s what I achieved, broken down into key phases, along with the challenges I encountered and how I resolved them.

1. Setting Up the Project Environment

I started by organizing my project directory (project4/) with subfolders for Terraform (terraform/), Ansible (ansible/), and scripts (scripts/). I installed Terraform, Ansible, and the AWS CLI on my local machine, ensuring my AWS credentials were configured correctly.

Accomplishment: Established a clean, structured project environment to support IaC and automation workflows.

2. Provisioning Infrastructure with Terraform

Using Terraform, I provisioned a robust AWS infrastructure:

VPC: Created multi-tier-vpc with a CIDR block of 10.0.0.0/16.
Subnets: Set up a public subnet (10.0.1.0/24) for the web server and a private subnet (10.0.2.0/24) for the database server.
Networking: Configured an Internet Gateway for public subnet access, a NAT Gateway for private subnet outbound traffic, and route tables to manage traffic flow.
Security Groups:
- web-sg: Allowed HTTP (port 80) from anywhere and SSH (port 22) from my IP.
- db-sg: Permitted MariaDB (port 3306) and SSH (port 22) from the web server’s security group.
IAM Role: Granted EC2 instances S3 read-only access via an instance profile.
EC2 Instances: Launched a web server in the public subnet and a database server (IP: 10.0.2.219) in the private subnet, both using Amazon Linux 2023.
Outputs: Exposed the web server’s public IP and database server’s private IP for Ansible.

Challenge: When creating the variables.tf file, I mistakenly defined the web_sg_ingress variable with port 80 twice instead of including port 22 for SSH:

web_sg_ingress = [
  { from_port = 80, to_port = 80, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] },
  { from_port = 80, to_port = 80, protocol = "tcp", cidr_blocks = ["MY_IP/32"] }  # Error: Should be port 22
]

This caused SSH connection failures to the web server, as port 22 was blocked. I spent hours troubleshooting, expecting a key pair or network issue, only to realize the security group misconfiguration.

Solution: I updated variables.tf to:

web_sg_ingress = [
  { from_port = 80, to_port = 80, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] },
  { from_port = 22, to_port = 22, protocol = "tcp", cidr_blocks = ["MY_IP/32"] }
]

Reapplied Terraform (terraform apply), and SSH access was restored.

Accomplishment: Successfully provisioned a secure, multi-tier AWS infrastructure using Terraform, learning the importance of double-checking security group configurations.

3. Configuring Servers with Ansible

I used Ansible to automate server setup:

Web Server:
- Installed Nginx, PHP, and PHP-FPM.
- Deployed index.php, a PHP script that connects to the database and displays "Connected successfully to the database!".
- Configured Nginx to serve PHP files.
Database Server:
- Installed MariaDB, created a database (my_database), and set up a user (web_user) with access from the web server.
- Secured MariaDB with a root password.

Challenge: The initial db_playbook.yml failed because mariadb-server wasn’t available on Amazon Linux 2023:

No package mariadb-server available.

AL2023 doesn’t use amazon-linux-extras (unlike Amazon Linux 2), and the correct package was mariadb105-server. Additionally, I used yum instead of dnf, AL2023’s default package manager.

Solution: Updated the playbook to use dnf and install mariadb105-server:

- name: Install MariaDB server
  dnf:
    name: mariadb105-server
    state: present

Challenge: An earlier playbook run failed on the mysql_user task to set the MariaDB root password, likely due to AL2023’s default unix_socket authentication for the root user.

Solution: Modified the playbook to handle initial root access without a password and ignore errors for fresh installs:

- name: Set MariaDB root password for the first time
  mysql_user:
    name: root
    password: "{{ mysql_root_password }}"
    host: localhost
    state: present
    login_user: root
    login_password: ''
  no_log: true
  ignore_errors: yes

Accomplishment: Automated server configuration with Ansible, overcoming package and authentication issues specific to AL2023.

4. Adding CloudWatch Monitoring

I configured AWS CloudWatch to monitor CPU utilization for both EC2 instances:

Created alarms (web-cpu-alarm and db-cpu-alarm) to trigger if CPU usage exceeds 80% for 4 minutes.
Integrated this into main.tf with Terraform.

Accomplishment: Implemented basic monitoring to ensure infrastructure health, enhancing the project’s production readiness.

5. Configuring S3 Backend for Terraform State

To ensure state consistency, I stored Terraform’s state file in an S3 bucket (terraform-state-bucket):

Created the bucket manually in the AWS Console.
Updated main.tf with:

terraform {
  backend "s3" {
    bucket = "terraform-state-bucket"
    key    = "project4/terraform.tfstate"
    region = "us-east-1"
  }
}

Reinitialized Terraform (terraform init).

Accomplishment: Enabled remote state management, a best practice for collaborative IaC projects.

6. Implementing a Unit Test

I wrote a Bash script (test.sh) to verify the web application:

Fetched the web server’s public IP from Terraform output.
Used curl to check if http://<web_public_ip>/index.php returned "Connected successfully to the database!".
Output "Test passed" or "Test failed" based on the response.

Accomplishment: Added automated testing to validate application functionality, ensuring reliability.

7. Cleaning Up Resources

Learning from my previous project’s $27 bill due to lingering resources, I destroyed all AWS resources after completion:

terraform destroy

This removed the VPC, EC2 instances, NAT Gateway, and other components, avoiding unexpected charges.

Accomplishment: Practiced responsible cloud management, ensuring no cost overruns.

Lessons Learned

This project was a significant step forward in my DevOps journey, but it wasn’t without challenges. Key takeaways include:

Attention to Detail in IaC: The variables.tf error (port 80 instead of 22) taught me to meticulously review configurations, especially for security groups, as small mistakes can cause significant issues.
OS-Specific Considerations: AL2023’s differences (e.g., dnf vs. yum, mariadb105-server vs. mariadb-server) highlighted the importance of understanding the target operating system.
Automation Saves Time: Ansible and Terraform reduced manual setup, but debugging automation scripts requires patience and log analysis.
Cost Awareness: Destroying resources immediately after use is critical to avoid charges, a lesson reinforced by my previous project’s mistake.
Persistence Pays Off: Each challenge, from SSH failures to package errors, was a chance to deepen my understanding of AWS and automation tools.

Next Steps

With this project complete, I’m excited to explore more advanced DevOps concepts, such as:

Implementing auto-scaling groups with Terraform.
Using Ansible roles for more modular playbooks.
Adding CI/CD pipelines to automate deployments.

This project has equipped me with the skills to tackle these challenges with confidence. Stay tuned for my next adventure in cloud computing!

Conclusion

Deploying a fully automated multi-tier web app on AWS with Terraform and Ansible was both challenging and rewarding. From misconfiguring security groups to navigating AL2023’s package quirks, I faced obstacles that tested my problem-solving skills. Yet, the result—a secure, monitored, and tested web application—was worth the effort. This project not only solidified my understanding of IaC and automation but also taught me the importance of precision and cost management in the cloud. If you’re diving into a similar project, embrace the challenges—they’re your best teachers. Happy automating!

Deploying a Multi-Tier Web App on AWS: A Journey Through Challenges and Costly Lesson

THARUN REDDY R — Sat, 24 May 2025 12:22:51 +0000

As part of my journey to master cloud computing and DevOps, I recently completed an intermediate-level project: deploying a multi-tier web application on AWS. The goal was to build a secure, scalable architecture with a web server in a public subnet and a database server in a private subnet, using AWS services like EC2, VPC, and security groups. While the project was a success, it came with significant hurdles—both technical and financial. In this blog post, I’ll walk you through the project’s objectives, the numerous issues I faced, how I resolved them, and a costly lesson about AWS resource cleanup that left me with a $27 bill.

Project Objectives

The project had clear goals to test my AWS and Linux skills:

Launch EC2 Instances: Set up one web server and one database server using Amazon EC2.
Configure Nginx: Use Nginx as a reverse proxy on the web server to serve a PHP-based web application.
Automate with Ansible: Provision both servers using Ansible playbooks for consistency (though I ended up skipping this due to challenges).
Enhance Security: Create a Virtual Private Cloud (VPC) with public and private subnets, placing the database in the private subnet to protect it from direct internet access.

The final deliverable was a working web application accessible via the web server’s public IP, with the backend database securely tucked away in a private subnet.

Step-by-Step Implementation

Here’s how I built the project, broken down into key phases, along with the issues I faced and how I tackled them.

Setting Up the VPC and Networking

To create a secure architecture, I started by configuring a custom VPC (multi-tier-vpc) with:
Public Subnet (10.0.1.0/24) for the web server.
Private Subnet (10.0.2.0/24) for the database server.
An Internet Gateway to allow the public subnet to access the internet.
Route Tables to manage traffic, with the public subnet routing to the Internet Gateway.

Issue: The database server, in the private subnet, couldn’t access the internet to fetch package updates, causing errors like:

Could not retrieve mirrorlist https://amazonlinux-2-repos-eu-north-1.s3.dualstack.eu-north-1.amazonaws.com/... Timeout was reached

Solution: I added a NAT Gateway in the public subnet and updated the private subnet’s route table to route 0.0.0.0/0 traffic through it. This allowed the database server to download packages while remaining isolated from inbound traffic.

Launching EC2 Instances I launched two EC2 instances using the Amazon Linux 2 AMI:

Web Server: Placed in the public subnet (10.0.1.37, public IP: 51.20.138.105), with a security group (web-sg) allowing HTTP (port 80) and SSH (port 22).
Database Server: Placed in the private subnet (10.0.2.129), with a security group (db-sg) allowing MariaDB (port 3306) and SSH (port 22) from the web server’s security group.
Both used the same SSH key pair (multi-tier-key) for access.

Issue: I couldn’t SSH into the database server from the web server, getting:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Solution: The web server didn’t have the private key. I used scp to copy multi-tier-key.pem to the web server’s ~/.ssh/ directory and set permissions (chmod 400). I also verified the database server’s ~/.ssh/authorized_keys file contained the correct public key, using AWS Systems Manager Session Manager to access it initially.

Configuring the Database Server I intended to install MySQL on the database server, but ran into an issue. Issue: The command sudo yum install mysql-server -y failed with:

No package mysql-server available.

Solution: Amazon Linux 2 uses MariaDB as a drop-in replacement for MySQL. I installed mariadb-server instead:

sudo yum install mariadb-server -y
sudo systemctl start mariadb
sudo systemctl enable mariadb

I secured MariaDB with mysql_secure_installation, setting a root password and restricting root access to localhost for security.

Issue: The web server couldn’t connect to the database, with telnet 10.0.2.129 3306 showing:

Host '10.0.1.37' is not allowed to connect to this MariaDB server.

Solution: MariaDB’s user permissions didn’t allow connections from the web server’s IP. I created a user (web_user) with access from 10.0.1.37:

CREATE USER 'web_user'@'10.0.1.37' IDENTIFIED BY 'your_password';
GRANT ALL PRIVILEGES ON my_database.* TO 'web_user'@'10.0.1.37';
FLUSH PRIVILEGES;

Setting Up the Web Server I installed Nginx and PHP on the web server to serve a simple PHP script (index.php) that connected to the database.

Issue: Running telnet 10.0.2.129 3306 initially failed with:

-bash: telnet: command not found

Solution: I installed the telnet package:

Solution: I installed the telnet package:

Issue: Accessing http://51.20.138.105/index.php resulted in a 502 Bad Gateway error. Solution: This was a multi-faceted issue:

PHP-FPM Not Installed: The php-fpm service was missing, causing Nginx to fail when processing PHP files. I installed it:

sudo yum install php-fpm -y
sudo systemctl start php-fpm
sudo systemctl enable php-fpm

Nginx Configuration Error: The /etc/nginx/conf.d/php.conf file had a syntax error (10.0.2.129 localhost;) and a misplaced location block. I corrected it to:

server {
    listen 80;
    server_name _;
    root /usr/share/nginx/html;
    index index.php index.html index.htm;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Socket Mismatch: Nginx was configured for /var/run/php-fpm/php-fpm.sock, but PHP-FPM used /run/php-fpm/www.sock. I updated fastcgi_pass to match after checking /etc/php-fpm.d/www.conf.

Issue: The index.php file wasn’t initially on the web server. Solution: I used scp to upload it from my local machine to /usr/share/nginx/html/ and set permissions:

sudo chown nginx:nginx /usr/share/nginx/html/index.php
sudo chmod 644 /usr/share/nginx/html/index.php

Final Testing After resolving these issues, I tested the application:

Visited http://51.20.138.105/index.php and saw: "Connected successfully to the database!"
Verified SSH access to the database server via the web server:

ssh -i ~/.ssh/multi-tier-key.pem ec2-user@10.0.2.129

The Costly Mistake: Leaving Resources Running

After completing the project, I stopped my EC2 instances and left them idle for over two weeks, assuming that since I was using the AWS Free Tier, I wouldn’t incur charges. To my shock, I received a pending AWS bill for $27! It turned out that while the EC2 instances were stopped, other resources like the VPC, NAT Gateway, and associated components (e.g., Elastic IPs) were still active and accruing costs. NAT Gateways, in particular, are not covered by the Free Tier and can be surprisingly expensive.

Solution: I immediately terminated all resources:

EC2 Instances: Deleted both the web and database servers via the EC2 Console.
VPC: Removed the multi-tier-vpc, along with subnets, route tables, NAT Gateway, and Internet Gateway.
Security Groups and Key Pairs: Ensured no lingering resources remained.

This experience taught me the critical importance of fully cleaning up all AWS services after a project is complete, not just stopping instances. I learned this lesson the hard way, but it’s one I won’t forget.

What I Missed

The original plan included using Ansible to automate server provisioning. However, due to the numerous issues (network timeouts, package errors, configuration mismatches), I opted for manual setup. While this meant more hands-on troubleshooting, it deepened my understanding of AWS and Linux. I plan to incorporate Ansible in my next project to streamline automation.

Lessons Learned

This project was a rollercoaster, but it taught me invaluable lessons:

AWS Networking is Critical: Understanding VPCs, subnets, NAT Gateways, and security groups is essential for secure cloud architectures.
Debugging is a Skill: Logs (/var/log/nginx/error.log, /var/log/php-fpm/error.log) were my best friends for diagnosing issues like socket mismatches.
Security Matters: Placing the database in a private subnet and restricting MariaDB access to specific IPs significantly enhanced security.
Clean Up Resources: Always terminate all AWS resources (not just EC2 instances) to avoid unexpected charges. My $27 bill was a painful but crucial lesson in cloud cost management.
Persistence Pays Off: Each issue felt daunting, but breaking them down and tackling them systematically led to success.

Next Steps

I’m now diving into an Advanced Project: Fully Automated AWS Infrastructure with Terraform & Ansible. This will involve:

Using Terraform to provision AWS resources (VPC, EC2, IAM roles).
Configuring servers with Ansible for a scalable web app.
Adding CloudWatch monitoring, S3 state storage, and unit tests.

The struggles from this project, especially the cost oversight, have prepared me to appreciate automation tools like Terraform and Ansible, which should reduce manual errors and streamline setup. I’ll also be vigilant about cleaning up resources to avoid another surprise bill!

Conclusion

Deploying a multi-tier web app on AWS was challenging but rewarding. From network timeouts to Nginx configuration woes and an unexpected $27 bill, I faced a steep learning curve but emerged with a functional application and a deeper understanding of cloud infrastructure. The financial lesson about resource cleanup was a hard one, but it underscored the importance of diligence in cloud management. If you’re embarking on a similar project, don’t be discouraged by setbacks—each issue is a chance to learn, and always double-check your AWS resources before walking away. Happy cloud computing!

Automating My EC2 with Ansible: A Tale of WSL Woes and Nginx Triumphs

THARUN REDDY R — Mon, 31 Mar 2025 11:07:04 +0000

Introduction

For Project 3 in my DevOps journey, I set out to automate an EC2 instance setup with Ansible—installing Nginx and securing it by disabling root SSH login. What seemed like a straightforward task turned into a learning adventure, especially since I’m on Windows and had to wrestle with WSL quirks. Here’s how I pulled it off, stumbles and all.

The Plan

My goal was clear: use Ansible to configure an EC2 instance efficiently. The steps were:

Install Ansible on my local machine.
Launch a fresh Amazon Linux 2 EC2 instance with SSH access.
Set up an Ansible inventory file to connect to the instance.
Write a playbook to install Nginx and disable root SSH login.
Run the playbook and verify the automation worked — Nginx running, root access blocked.

How It Went

Here’s what I did to make it happen:

Installing Ansible: Since I’m on Windows, I installed WSL (Windows Subsystem for Linux) and Ubuntu. Then, I ran:

  sudo apt update
  sudo apt-get install ansible

Ansible was ready after confirming with ansible --version.

New EC2 Instance: I created an Amazon Linux 2 instance in AWS with a t3.micro, a security group for SSH (port 22, my IP), and a key pair (my-ansible-key.pem). SSH worked fine:

ssh -i my-ansible-key.pem ec2-user@13.60.41.232

Inventory Setup: I created inventory.ini with my instance’s IP and key path, but testing the connection hit a snag (more on that later).
Playbook Creation: I wrote setup.yml to install Nginx and disable root SSH, but running it revealed more hurdles.
Verification: After tweaks, I confirmed Nginx at http://<ec2-public-ip> and tested SSH—root was denied, ec2-user worked.

Challenges & Solutions

Challenge 1: WSL and Inventory File Permissions

When I ran ansible -m ping -i inventory.ini ec2, I got errors about parsing inventory.ini and an "unprotected private key" warning. The issue? My .pem file was in /mnt/c/... (Windows file system), and WSL couldn’t enforce proper permissions (0555 was too open).

Solution: I copied the key to /root/my-ansible-key.pem in WSL:

cp /mnt/c/Users/deepa/downloads/devops/project2/my-ansible-key.pem /root/my-ansible-key.pem
chmod 0600 /root/my-ansible-key.pem

Updated inventory.ini:

[ec2]
13.60.41.232 ansible_user=ec2-user ansible_ssh_private_key_file=/root/my-ansible-key.pem

The ping worked: pong!

Challenge 2: Nginx Not Found in Playbook

Running ansible-playbook -i inventory.ini setup.yml failed with "No package matching 'nginx' found." Amazon Linux 2 doesn’t include Nginx in its default repos—I needed amazon-linux-extras.

Solution: I tweaked setup.yml to enable Nginx first.

- name: Enable Nginx in amazon-linux-extras
  command: amazon-linux-extras enable nginx1
  args:
    creates: /var/lib/amazon-linux-extras/nginx1

Reran the playbook, and Nginx installed successfully.

Challenge 3: No HTTP Access

After Nginx installed, http://<ec2-public-ip> didn’t load—my security group only allowed SSH (port 22), not HTTP (port 80).

Solution: Added an inbound rule in AWS:
Type: HTTP
Port: 80
Source: 0.0.0.0/0 (for testing) The Nginx welcome page appeared!

Takeaways

WSL Workarounds: Moving files to WSL’s file system avoids permission headaches with Windows paths.
Package Dependencies: Automation needs to account for OS-specific repos — amazon-linux-extras was my savior.
Security Groups Are Key: Forgetting HTTP access reminded me to align network rules with app needs.
Automation Wins: Seeing Nginx pop up and root SSH get blocked with one command felt like magic.

This project was a grind, but it taught me how Ansible simplifies server setup—and how to troubleshoot when things go sideways. What’s your go-to fix for Ansible hiccups?

Securing My AWS EC2: A Journey Through IAM and SSH Struggles

THARUN REDDY R — Mon, 31 Mar 2025 08:46:35 +0000

Introduction

After getting my first EC2 instance up with Nginx, I dove into Project 2 of my DevOps roadmap: setting up IAM users and roles, and securing an EC2 instance with a security group. My goal? Create a user with limited access, attach a role for S3 permissions, and test it all out. What started as a straightforward task turned into a rollercoaster of SSH woes—but I came out stronger. Here’s how it unfolded.

The Plan

The project had clear steps:

Create an IAM User: Set up devops-user1 with AmazonEC2ReadOnlyAccess for console and programmatic access.
Create an IAM Role: Build ec2-s3-role with AmazonS3ReadOnlyAccess for my EC2 instance.
Configure Security: Define a security group with SSH (port 22) restricted to my IP and generate a key pair (my-new-key).
Launch an Instance: Spin up an Amazon Linux 2 instance with the security group and attach the role.
Test It: Log in as devops-user1 to check EC2 read-only access, and SSH into the instance to run aws s3 ls using the role.

Simple, right? Well, not quite.

How It Went

I kicked off in the AWS Console:

IAM User: Created devops-user1, downloaded the access keys, and logged in to confirm read-only EC2 access worked.
IAM Role: Set up ec2-s3-role, attached it to my instance via EC2 > Actions > Modify IAM role.
Security Group: Added SSH (port 22, my IP) and launched the instance with Amazon Linux 2 AMI and my new key pair.

The instance launched fine, and I could connect via the AWS Console’s EC2 Instance Connect. But when I tried SSH from my local system:

ssh -i my-new-key.pem ec2-user@<public-ip>

It timed out. I was stumped—I’d followed all the steps!

Challenges & Solutions

Challenge 1: SSH Port 22 Timeout

After launching the instance, I couldn’t SSH from my local machine—it just kept timing out with:

ssh: connect to host <public-ip> port 22: Connection timed out

The security group was set to allow port 22 from anywhere, and the instance was running. I even tested as devops-user1 with the access keys via AWS CLI, but SSH refused to budge.

Challenge 2: Switching to Port 2222 Didn’t Help

Thinking my network might be blocking port 22, I edited /etc/ssh/sshd_config on the instance (via Console access) to use port 2222, restarted sshd, and updated the security group. Tried again:

ssh -i my-new-key.pem -p 2222 ec2-user@<public-ip>

Still no luck—now it said "Connection refused." Telnet (telnet <public-ip> 2222) confirmed the connection failed too.

Solution: Fresh Start with a New Instance

Frustrated, I decided to wipe the slate clean:

Terminated the instance, deleted the security group, and trashed the old key pair.
Launched a new instance from scratch:
Amazon Linux 2 AMI, t3.micro.
New security group with SSH (port 22, anywhere).
Fresh key pair (my-new-key).

This time, SSH worked like a charm:

ssh -i my-new-key.pem ec2-user@<public-ip>

Opened Git bash & ran aws s3 ls —it listed my buckets, proving the ec2-s3-role worked.

Takeaways

Double-Check Everything: My first instance’s woes might’ve stemmed from a misconfigured subnet or lingering settings—starting fresh ruled those out.
Network Matters: Port 22 might’ve been blocked locally; testing from another network could’ve confirmed it, but the reset worked too.
IAM Power: Roles are a game-changer—no credentials on the instance, just seamless S3 access.
Persistence Pays: Troubleshooting taught me more than a smooth run would’ve.

Now that SSH and IAM are in my toolkit, I’m ready for the next challenge. How do you debug SSH woes—any tricks up your sleeve?

My First AWS EC2 Instance: From Stumbles to a Running Nginx Server

THARUN REDDY R — Sun, 23 Mar 2025 13:29:52 +0000

Introduction

Starting my DevOps journey, I set out to launch an EC2 instance and host a web server. It wasn’t all smooth sailing, but I learned a ton along the way.

The Plan

Launch an EC2 instance with AWS Console and CLI.
Connect via SSH.
Set up an Nginx web server.

How It Went

I kicked off by launching an instance via the AWS Console—easy enough with Amazon Linux 2 and a t3.micro. I added SSH (port 22) and HTTP (port 80) to the security group, grabbed my key pair, and SSH’d in with:

ssh -i my-key.pem ec2-user@<public-ip>

Next, I ran:

sudo yum update -y
sudo amazon-linux-extras install nginx1 -y
sudo systemctl start nginx

But then, I hit a snag.

Challenge 1: Wrong AMI, Wrong Tools

My first attempt flopped—I couldn’t install Nginx because amazon-linux-extras wasn’t recognized. Turns out, I’d picked the wrong AMI (not Amazon Linux 2). After a quick cat /etc/os-release check, I relaunched with the right AMI and the install worked like a charm.

Challenge 2: Port Problems

I couldn’t load http://<public-ip>. The culprit? My inbound rules in security group had port 443 (HTTPS) open instead of port 80 (HTTP). I had to remove port 443 & add inbound rules for port 80, then refreshed the page & Nginx was running, the welcome page popped up perfectly.

Takeaways

AMI Matters: Picking the right image saves headaches with package managers.
Ports Are Key: Security groups need to match your app’s needs—port 80 for HTTP, not 443 unless you’re ready for HTTPS.
Persistence Pays: Troubleshooting is half the fun of DevOps.

What’s your favorite beginner AWS tip?