Forem: Benjamin Tetteh

Building My First AWS VPC with Terraform: A Beginner-Friendly Guide for Career Changers

Benjamin Tetteh — Fri, 08 May 2026 20:47:37 +0000

Not long ago, terms like “VPC,” “subnet,” and “Terraform” would have made my eyes glaze over. While my background wasn’t originally rooted in cloud engineering, I’ve always been fascinated by how modern infrastructure is designed, automated, and scaled behind the scenes.

Now, partway through my DevOps journey, I’ve gone from simply reading about cloud infrastructure to actually building it, using Terraform to provision a fully functional AWS network entirely through code.

If you're reading this while sitting at a career crossroads — maybe you're a teacher, an accountant, a customer service rep, or anyone wondering "can I really break into tech?" I want this post to be your proof that yes, you absolutely can.

Before we touch any code...

Let's understand why everything exists. Tools make a lot more sense that way. Think of it like building a neighbourhood. Imagine you're a city planner given a plot of land. Your job is to:

Draw the boundary of the land — this is your VPC (Virtual Private Cloud). It defines your space in AWS. Nothing gets in or out unless you say so.

Divide the land into zones — some areas are public (like a shopping street anyone can visit) and some are private (like a gated estate — no outsiders allowed).

Build a gate to the outside world — this is the Internet Gateway (IGW). The single controlled entrance between your network and the internet.

Set the traffic rules — Route Tables tell your network traffic exactly where to go, like road signs.

💡 Why Terraform instead of clicking around in AWS?
Clicking in the AWS console is slow, hard to repeat, and easy to mess up. Terraform lets you write your infrastructure as code — describe what you want, run one command, and it builds everything consistently every time. This is called Infrastructure as Code (IaC) and employers actively look for this skill.

The project structure

terraform-vpc/
├── main.tf       # The blueprint — everything to build
├── variables.tf  # The settings — values we can change
└── outputs.tf    # The receipt — shows what got created

Think of main.tf as the architect's drawing, variables.tf as the customizable options, and outputs.tf as the summary report after construction is done.

Step 1: Setting up Terraform — the provider block

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

The first block tells Terraform: "We're working with AWS, and we want version 5 of the AWS plugin." That plugin is called a provider — think of it as an adapter that lets Terraform talk to AWS.

The second block specifies which AWS region to build in. A region is a physical location with Amazon data centres — us-east-1 is Northern Virginia, USA.

Notice var.region? That means: "look up the value of region in my variables file."

Step 2: Creating the VPC — your cloud neighbourhood

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "main-vpc"
  }
}

The cidr_block defines the total size of your network. 10.0.0.0/16 gives us room for up to 65,536 addresses — a big plot of land!

tags are just labels to help you find your resources in the AWS console. Always tag. Your future self will thank you.

Step 3: Internet Gateway — the front gate

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}

Without this, your VPC is sealed off — like a neighbourhood with no road to the outside world. Notice vpc_id = aws_vpc.main.id? Terraform links resources like this. It figures out the build order automatically.

Step 4: Subnets — carving the zones

# Public subnet (the shopping street)
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  tags = { Name = "main-public-subnet" }
}

# Private subnet (the gated estate)
resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
  tags = { Name = "main-private-subnet" }
}

We're carving our big VPC into zones. The public subnet (10.0.1.0/24) is for resources that need internet access, like web servers. The private subnet (10.0.2.0/24) is for sensitive things like databases — no direct internet access. The /24 gives each subnet 256 addresses.

Step 5: Route tables — the traffic signs

# Public route table + association + internet route
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-public-rt" }
}
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}
resource "aws_route" "public_igw" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.main.id
}

# Private route table + association (no internet route)
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-private-rt" }
}
resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private.id
}

The key line is destination_cidr_block = "0.0.0.0/0" pointing to the IGW. 0.0.0.0/0 means "any address on the internet" — this is what makes the public subnet actually public.

The private subnet gets its own route table but no internet route — isolated by design. The associations are the connectors that glue each table to its subnet.

Step 6: Variables — the settings file

variable "region" {
  type        = string
  description = "AWS region to deploy resources in"
  default     = "us-east-1"
}

variable "vpc_cidr_block" {
  type        = string
  description = "CIDR block for the VPC"
  default     = "10.0.0.0/16"
}

Instead of hardcoding "us-east-1" everywhere, we define it once here. Want to deploy to a different region? Change it in one place, not everywhere. Clean, reusable, professional.

Step 7: Outputs — the receipt

output "vpc_id" {
  value = aws_vpc.main.id
}
output "public_subnet_id" {
  value = aws_subnet.public.id
}
output "private_subnet_id" {
  value = aws_subnet.private.id
}

After Terraform finishes, outputs are printed in your terminal — like a receipt. Instead of logging into AWS to find your VPC ID, Terraform just hands it to you.

The full architecture

Challenges I Faced
Like every beginner, I made mistakes:

Using quotes incorrectly around variables inside main.tf which broke my configuration
Confusion around route tables and associations
Understanding how IGW actually connects to subnets
Debugging Terraform errors for the first time

But each error helped me understand AWS networking better.

What's next?

This VPC is the foundation. In future posts, I'll be covering launching EC2 instances inside this VPC, adding security groups (the bouncers of the cloud), and exploring remote state management with S3. Follow along!

Enhancing Cybersecurity in Healthcare: A NIST Cybersecurity Framework Assessment

Benjamin Tetteh — Sat, 08 Mar 2025 19:10:57 +0000

Cybersecurity threats are an ever-growing concern, especially in industries handling sensitive data like healthcare. To address these risks, I conducted a NIST Cybersecurity Framework (CSF) Assessment for a fictional mid-sized healthcare provider, MediHealth Solutions Inc., as part of my cybersecurity portfolio.

Project Overview
The goal of this assessment was to evaluate MediHealth’s security posture, identify vulnerabilities, and recommend remediation strategies in alignment with NIST CSF and HIPAA requirements. The assessment covered key cybersecurity domains, including identifying assets, implementing protective measures, detecting threats, responding to incidents, and ensuring recovery.

Key Findings
One of the major findings was the presence of legacy system risks. The organization relied on an outdated Electronic Health Records (EHR) system, increasing its exposure to unpatched vulnerabilities. To mitigate this risk, I recommended system upgrades and the deployment of automated patch management. Another critical issue was human factors in cybersecurity. A phishing simulation revealed that 30% of employees fell for phishing attempts, highlighting the need for increased awareness. I proposed a cybersecurity training program using platforms like KnowBe4 and GoPhish to educate employees on recognizing and avoiding phishing attacks.

Additionally, I identified the absence of an Incident Response Plan (IRP) to handle ransomware and data breaches. Without a structured IRP, the organization risked delayed responses to security incidents. To address this, I developed a comprehensive IRP based on NIST SP 800-61 Rev. 2, outlining clear response procedures and implementing quarterly tabletop exercises to ensure readiness. Weak access controls were another major concern, as critical systems lacked Multi-Factor Authentication (MFA) and Role-Based Access Controls (RBAC). Enforcing MFA for all high-risk accounts and restricting access based on user roles significantly improved the security posture. Furthermore, the lack of centralized monitoring meant that the organization had no Security Information and Event Management (SIEM) system to detect and analyze threats in real-time. To remedy this, I recommended deploying SIEM tools such as Splunk or ELK Stack, along with Intrusion Detection Systems (IDS/IPS) to enhance threat detection and mitigation capabilities.

Relevance to My Cybersecurity Journey
As a self-motivated cybersecurity enthusiast, this project was instrumental in refining my skills in risk assessment, incident response, compliance, and security control implementation. Conducting this assessment independently showcased my ability to analyze real-world cybersecurity threats, design security solutions, and align them with industry standards. This hands-on experience reinforced my understanding of security governance, risk management, and compliance (GRC), which are crucial skills for cybersecurity professionals. It also highlights my capability to work autonomously, proactively learn, and apply best practices in enterprise security.

This project provided invaluable experience in conducting enterprise-wide cybersecurity assessments, aligning security controls with compliance frameworks, and implementing actionable security improvements. It reinforced the importance of a structured approach to risk management, proactive threat detection, and continuous cybersecurity awareness training. Cybersecurity is a constantly evolving field that requires a mix of technical expertise and risk-based decision-making. This NIST assessment has been a valuable addition to my cybersecurity portfolio, demonstrating my ability to analyze security gaps and implement industry-standard security measures.

📌 Check out the full assessment here.

💬 Let’s discuss! Have you worked with the NIST Cybersecurity Framework before? How do you approach security risk assessments in your projects?

From Data Breach to Insight: Exploring the Intersection of Cybersecurity and Communication

Benjamin Tetteh — Sat, 08 Mar 2025 18:22:00 +0000

I recently received an email notifying me of a data breach at a major public service provider in London that I rely on. Before this, I never truly considered that I could be directly impacted by a breach, even though they’re frequently reported in the media. With incidents like these becoming increasingly common, it was unsettling to think that my personal data may have been compromised. However, the service provider has been proactive, sending follow-up emails in the weeks following the initial notification, outlining the incident and their remediation efforts. As a communications professional, I found their response reassuring.

Data breaches are becoming so frequent that they’re starting to feel like notifications from my telecom provider—constant, annoying, and impossible to ignore.

Coincidentally, I’d been enrolled in the Google Cybersecurity Certificate course. My initial foray into cybersecurity was driven by the assumption that I would be diving into a highly technical world—one filled with firewalls, encryption, and endless lines of code, likely while wearing a hoodie in a dark room. While I certainly encountered that (minus the hoodie), what piqued my interest was discovering how crucial communication is within the cybersecurity landscape.

In today's hyper-connected world, cybersecurity has become one of the most critical aspects of every organization's operational strategy. It’s not just about protecting sensitive data or ensuring business continuity; it’s also about building and maintaining trust with customers. I’ve come to realize that cybersecurity is more than just a technical responsibility; it’s also a communications challenge.

The Intersection
Why? Because no matter how sophisticated an organization's defenses are, human error remains one of the most significant risks. This is where effective communication plays a pivotal role. While studying incident response plans, I realized that when a data breach occurs, it’s not just the IT team scrambling behind the scenes to secure systems and data. The communications team is equally essential in ensuring that stakeholders—whether customers, employees, or partners—are informed and reassured. Organizations are legally obligated to disclose breaches, and the quality, clarity, and timeliness of that communication often determine whether trust is preserved or lost. Cybersecurity professionals may patch vulnerabilities and mitigate future risks, but without clear, strategic communication, even the best technical response can leave people in the dark and cause unnecessary panic.

One of the most critical elements of cybersecurity is awareness. Many threats—from phishing to social engineering—target the weakest link: people. Ensuring that employees and stakeholders understand the risks and how to avoid them requires more than a one-time memo or a check-the-box training module. It requires consistent, clear, and engaging communication. By translating complex technical concepts into easily understandable information, communicators can help create a culture of security. This extends to everything from regular awareness campaigns to engaging content that demystifies topics like password security, device protection, and data privacy.

Gaining Technical Expertise: The Next Frontier
On the flip side, my experience with the technical aspects of cybersecurity has also been eye-opening. Through the Google Cybersecurity Certificate, I’ve gained hands-on experience with tools like Python, Linux, and SQL, and I’ve worked with Security Information and Event Management (SIEM) tools to identify risks and mitigate threats. Understanding these technologies has allowed me to better appreciate the technical side of cybersecurity.

My observations and learnings from the past weeks have made me appreciate the relationship between cybersecurity and communications. Both disciplines require a keen understanding of risk, an ability to anticipate and mitigate problems, and a focus on protecting people—whether through securing data or ensuring that information is clear and accessible. As I continue to explore both fields, I’m excited by the possibilities that lie at this intersection.

On to the next.

PS: I first published this article on my LinkedIn profile on 16/9/24.