DEV Community: Harny Lawrence

Understanding AWS VPC – Building a Custom Virtual Network

Harny Lawrence — Mon, 10 Feb 2025 19:18:33 +0000

Recap: Why VPC Matters?

After launching my first EC2 instance and configuring Jenkins, I realized something critical—AWS by default places instances in a shared public network (default VPC). But in a real-world production setup, you don’t want your resources open to the internet without strict security controls.

This is where AWS Virtual Private Cloud (VPC) comes in.

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you can launch resources like EC2 instances, databases, and load balancers. It allows you to define your own virtual network, including IP address ranges, subnets, route tables, and gateways.

Key Components of a VPC

Here’s a breakdown of the main components and how they work together:

Subnets:

Public Subnet: Resources in this subnet can communicate with the internet (e.g., web servers).

Private Subnet: Resources in this subnet cannot directly access the internet (e.g., databases).

Route Tables:

Define how traffic is routed within the VPC.

Each subnet is associated with a route table.

Internet Gateway (IGW):

Allows communication between resources in the VPC and the internet.

Attached to the VPC and used by public subnets.

NAT Gateway:

Allows resources in private subnets to access the internet (e.g., for updates) without exposing them to inbound traffic.

Located in a public subnet.

Security Groups:

Act as virtual firewalls for instances, controlling inbound and outbound traffic.

Stateful: Allow return traffic automatically.

Network ACLs (NACLs):

Act as a firewall for subnets, controlling inbound and outbound traffic at the subnet level.

Stateless: Require explicit rules for return traffic.

Application Load Balancer (ALB):

Distributes incoming traffic across multiple targets (e.g., EC2 instances) in public or private subnets.

Bastion Host:

A secure server in a public subnet used to access instances in private subnets via SSH.

Route 53:

AWS’s DNS service, used to route traffic to resources (e.g., EC2 instances, load balancers) and register domain names.

How Everything Links Up
Vpc in a lame man theory

Step 1: Entering the City (Route 53 & Load Balancer)
The first stop? Route 53, Cloudville’s GPS system. It takes the user’s request and figures out where to send it—should it go to the North theater or the South theater?

Now that the request has a direction, it moves towards Cloudville’s city gates—the Load Balancer. Think of this as a border control checkpoint. It doesn’t just allow random traffic inside; instead, it checks the health of movie theaters (EC2 instances) and assigns the best one for the request.

But before the request is allowed to continue, it needs a public identity—a Public IP address assigned by the Load Balancer so it can be tracked properly.

Step 2: Navigating Security (NACL, Security Groups, and Routing)
Now, here’s the tricky part: Cloudville doesn’t let just anyone waltz into its private areas. The real action happens inside a private subnet, away from the outside world.

But wait! There’s a NACL (Network Access Control List) standing guard. This acts like a strict security officer at the gate, checking every request and blocking anything suspicious before it gets deeper inside.

If the request passes the NACL, it’s still not free to roam yet. It needs directions! That’s where the Route Table steps in—it’s the city's navigation system, guiding requests to their final destinations.

Step 3: Reaching the Private Server (Bastion Host & NAT Gateway)
Now, we’ve got a small problem. The server (EC2 instance) is inside a private subnet—meaning it doesn’t have direct access to the internet. The Route Table knows where to send the request, but since the server has only a private IP address, it cannot communicate directly with the outside world.

Enter the Bastion Host—Cloudville’s secret identity maker. Instead of exposing the real private server, the Bastion Host acts as a middleman, generating a new public-facing IP address to mask the private server’s real identity.

With this, the request is safely passed through, reaching the EC2 instance. Boom! The movie starts streaming!

Step 4: Servers Talking Back to the Internet (NAT Gateway & IGW)
Now, what if the private server needs to talk to the internet? Maybe it needs to download security updates or fetch an image for the website.

Here’s the thing—private subnets can’t talk directly to the outside world (that’s the whole point of security!). Instead, they need a NAT Gateway—think of it as a secure post office. The private server sends a letter to the NAT Gateway, which then forwards it using a public IP address.

On the other hand, for anything in the public subnet, the Internet Gateway (IGW) handles all communication freely—acting like the main highway to and from Cloudville.

If you’ve worked with VPC, what’s one thing you wish you knew earlier? Do you see anything missing or incorrect in my setup? Let’s discuss in the comments!

🚀Diving into AWS EC2 – My First Hands-On Experience

Harny Lawrence — Mon, 10 Feb 2025 15:18:07 +0000

Earlier, I laid the foundation for my DevOps journey by exploring AWS IAM and understanding the basics of cloud computing. This week, I took the next step: diving into AWS EC2 (Elastic Compute Cloud) and deploying my first application. Here’s a detailed recap of what I learned, the challenges I faced, and how I overcame them.

🔹 What is AWS EC2?
EC2 is one of AWS’s core services, allowing you to launch and manage virtual servers (instances) in the cloud. Here’s what makes EC2 powerful:

Elastic: Instances can be scaled up or down based on demand.

Compute: Provides CPU, RAM, and storage resources.

Cloud: Hosted on AWS’s infrastructure, eliminating the need for physical servers.

Types of EC2 Instances
AWS offers a variety of EC2 instance types optimized for different workloads. Here are the five major types:

General Purpose: Balanced compute, memory, and networking (e.g., t2.micro).

Compute Optimized: Ideal for compute-intensive tasks like batch processing.

Memory Optimized: Designed for memory-intensive applications like databases.

Storage Optimized: Optimized for high-speed storage and low-latency workloads.

Accelerated Computing: Uses hardware accelerators like GPUs for machine learning and graphics processing.

For my first instance, I chose the t2.micro (free tier eligible) because it’s cost-effective and perfect for learning.

Here’s a detailed step-by-step breakdown of how I launched my first EC2 instance and deployed Jenkins:

Step 1: IAM Best Practices
Before launching an EC2 instance, I ensured I followed AWS security best practices:

Created an IAM User: Instead of using the root user, I created a dedicated IAM user with limited permissions.

Enabled Multi-Factor Authentication (MFA): Added an extra layer of security to my account.

Assigned Policies: Granted the IAM user permissions to launch and manage EC2 instances.

Step 2: Launching the EC2 Instance

a. Navigated to the EC2 Dashboard:

Logged into the AWS Management Console and selected EC2 under 
Services.

b. Clicked Launch Instance:

Chose Ubuntu as the operating system (a popular choice for DevOps
workflows).

Selected the t2.micro instance type (free tier eligible).

c. Configured Key Pair:

Created a new key pair (e.g., aws_login.pem) for SSH access.

Downloaded the .pem file and stored it securely.

d. Configured Security Groups:

Created a new security group or used the default one.

Added rules to allow SSH access (port 22) from my IP address.

e. Launched the Instance:

Clicked Launch Instance and waited for it to initialize.

Step 3: Connecting to the Instance via SSH

a. Opened Terminal:

Navigated to the directory where the .pem file was stored.

b. onnected to the Instance:

Used the following command:
ssh -i aws_login.pem ubuntu@

c. Fixed SSH Key Permissions:
Initially, I encountered an error: “Permissions for 'aws_login.pem'
are too open.”

Fixed it by restricting permissions using:

chmod 600 aws_login.pem

What is chmod 600?
This command sets the file permissions so that only the owner can read
and write the file. This is necessary for SSH to work securely.

d. Reconnected Successfully:

Ran the SSH command again and accessed the instance.

Step 4: Installing Jenkins

What is Jenkins?

Jenkins is an open-source automation server used for Continuous
Integration and Continuous Delivery (CI/CD). It helps automate the
building, testing, and deployment of applications.

<u>Why Do We Need Java?</u>
Jenkins is a Java-based application, so it requires Java to run. This 
is why we install Java before Jenkins.

Installation Steps:

Updated the Package List:
sudo apt update
Installed Java:
sudo apt install openjdk-11-jdk
Verified Java Installation:
java -version
Installed Jenkins:
Added the Jenkins repository:

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo
tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc]
https://pkg.jenkins.io/debian-stable binary/ | sudo tee
/etc/apt/sources.list.d/jenkins.list > /dev/null
Updated the package list and installed Jenkins:

sudo apt update
sudo apt install jenkins
Started Jenkins:

sudo systemctl start jenkins
Enabled Jenkins to Start on Boot:

sudo systemctl enable jenkins

Step 5: Accessing Jenkins

a. Tried Accessing Jenkins:

Opened a browser and entered :8000.

The page didn’t load because the security group blocked port 8000.

b. Configured Security Group:

Went back to the EC2 dashboard and selected the instance’s security
group.

Added a new inbound rule:

Type: Custom TCP

Port Range: 8000

Source: 0.0.0.0/0 (for testing purposes; restrict this in production).

c. Accessed Jenkins:

Refreshed the browser, and the Jenkins setup page appeared.

Challenges Faced & Fixes

SSH Key Permissions:

Issue: The key pair was too open, causing SSH to reject it.

Fix: Used chmod 600 to restrict permissions.

Jenkins Not Running:

Issue: Jenkins didn’t start after installation.

Fix: Installed the correct version of Java and restarted the Jenkins service.

Port 8000 Blocked:

Issue: Couldn’t access Jenkins via the browser.

Fix: Added an inbound rule to the security group to allow traffic on port 8000.

AWS Foundations: Understanding Cloud Computing and Virtualization

Harny Lawrence — Mon, 10 Feb 2025 13:13:30 +0000

Starting my DevOps journey with AWS, I realized that before jumping into hands-on tasks, I needed a strong grasp of fundamental cloud concepts. This post explores the foundational principles that drive cloud computing, AWS's role in it, and key services like IAM and EC2 that set the stage for real-world deployments.

☁️ Cloud Computing & Virtualization

Before diving into AWS, I needed to understand the basics of cloud computing. Here’s what I learned:

Data Centers: These are physical facilities where servers are stored and managed. Traditionally, companies would host their applications and data on their own servers in these centers.

Virtualization: This is the process of creating virtual versions of physical resources (like servers) to maximize efficiency. Without virtualization, a single server might only use 10-20% of its capacity, wasting resources. Virtualization solves this by allowing multiple virtual machines (VMs) to run on a single physical server.

Public vs. Private Cloud

Private Cloud: This is when a company hosts its own cloud infrastructure, exclusively for its internal use. It’s secure but can be expensive and resource-intensive to maintain.

Public Cloud: Services like AWS, Azure, and Google Cloud are public clouds. They’re available to anyone globally and operate on a pay-as-you-go model. Public clouds are popular because they’re cost-effective, scalable, and require minimal maintenance.

Why Public Cloud?
Public cloud services like AWS have become the backbone of modern infrastructure. Here’s why:

Cost Efficiency: You only pay for what you use, eliminating the need for large upfront investments in hardware.

Maintenance: The cloud provider handles server maintenance, updates, and security, freeing up your team to focus on building and deploying applications.

Scalability: Need more resources? With a few clicks, you can scale up or down based on demand.

Security: Public cloud providers invest heavily in security measures, often far beyond what most companies could afford on their own.

Why AWS?
With so many public cloud providers out there, why did I choose AWS? Here’s why:

First-Mover Advantage: AWS was the first major player in the cloud space, giving it a mature and comprehensive ecosystem.

Market Dominance: AWS holds the largest market share in cloud computing, making it a safe and widely recognized choice.

Trends: While some companies are moving back to private clouds (a process called cloud repatriation), AWS remains the go-to solution for most organizations.

🔐 Identity & Access Management (IAM)

The first practical step in AWS was understanding IAM (Identity and Access Management), which controls authentication and authorization.

Key IAM Components:

Users: Individual accounts with permissions.

Groups: Collections of users with shared policies.

Roles: Temporary access permissions for services or external users.

Policies: JSON documents defining permissions.

My first hands-on task was setting up AWS Identity and Access Management (IAM). Here’s what I did:

Created Users: I set up individual user accounts for different team members.

Created Groups: I organized users into groups based on their roles (e.g., developers, admins).

Assigned Policies: I attached policies to groups to define their permissions (e.g., read-only access, full access).

Configured Password Reset: I enforced a password reset on the first login for added security.

IAM is crucial because it solves two key problems:

Authentication: Ensuring users are who they say they are.

Authorization: Defining what users are allowed to do.

🔗 What's Next?
This week was all about laying the foundation. Next, I’ll dive deeper into AWS services like EC2, VPC, and Route 53. I’ll also start building a production-ready infrastructure with load balancers, auto-scaling, and more. Stay tuned for updates!

For now, let me know—what was the biggest challenge you faced when first learning AWS? 🚀