DEV Community: GERALD IZUCHUKWU

What AWS VPC Actually Does Under the Hood (I Rebuilt It on Linux to Find Out)

GERALD IZUCHUKWU — Sat, 08 Aug 2026 11:29:46 +0000

If you've worked with AWS for more than a few weeks, you've created a VPC. You've drawn subnets, attached route tables, written security group rules, maybe even set up peering between two VPCs. It works. You move on.

But underneath the console clicks and Terraform resources, AWS is orchestrating real network primitives: isolating boundaries, packet filtering, routing decisions, and it is doing this at massive scale. Most of us never see that layer. It's abstracted away, and that's the whole point of a managed service.

I wanted to see it anyway. So I built vpcctl, a Python CLI that replicates core AWS VPC networking behavior: subnets, routing, security groups, peering, using nothing but native Linux primitives: network namespaces, veth pairs, Linux bridges, and iptables. This post walks through what AWS VPC actually does, and how rebuilding the equivalent behavior by hand changed how I think about designing and debugging real AWS networks.

The AWS Abstraction

Before diving into the internals, it's worth being precise about what a VPC actually consists of, since these are the pieces the rest of this post maps against:

VPC: an isolated virtual network with its own private IP address range (CIDR block).
Subnet: A subdivision of that CIDR, each tied to an Availability Zone, marked public or private based on its route table configuration.
Route tables: The rules that decide where traffic goes, either to the internet via an Internet Gateway, or to another subnet, or to a peered VPC.
Security group: This is the security mechanism on instances. It is a stateful, instance-level firewall that allows or denies traffic based on rules
VPC peering: A private routing connection between two otherwise isolated VPCs

Every one of these is a logical construct. AWS doesn't have a magic "VPC device" somewhere underneath; it's still doing packet forwarding, filtering, and NAT, just like any other network. The question I set out to answer was: "What does that look like if you build it yourself?"

The Experiment

vpcctl simulates each of these constructs using Linux tools that already exist on any machine:

Network namespaces stand in for isolated subnets; each namespace has its own routing table and interfaces, completely separate from the host.
Linux bridges act as the shared L2 segment a subnet's instances sit on
veth pairs are like physical wires that connect namespaces to bridges, the way an ENI connects an instance to a subnet
iptables rules enforce security-group-style allow/deny behavior
NAT via iptables MASQUERADE provides the "public subnet" internet access pattern

The CLI supports creating VPCs, adding subnets (public or private), attaching security group rules, setting up peering between two VPCs, and persisting that state across runs. This is the same operations you'd do in the AWS console, just executed as real Linux networking commands instead of API calls.

Mapping AWS Concepts to Linux Primitives

AWS Concept	Linux Equivalent	What It's Really Doing
Subnet isolation	Network namespace	Separate routing table and interface stack; the same reason instances in different subnets can't see each other's L2 broadcast domain
Public/private subnet	Route table + NAT (iptables MASQUERADE)	A "public" subnet isn't special; it just has a default route to something with internet access, same as a namespace routed through a MASQUERADE rule
Security groups	iptables rules on the veth/bridge interface	Stateful filtering happens at the interface level, not "on the instance," which is exactly why security group changes take effect without a restart
VPC peering	Routes between namespaces via a shared bridge or veth link	Peering is just a route. No transit, no NAT, which is also why peered VPCs can't have overlapping CIDRs
Route tables	Per-namespace routing tables	Each subnet's "personality" (public vs private) is entirely determined by what's in this table, nothing else

Seeing these side by side made a few AWS behaviors click that I'd previously just memorized as rules:

Why you can't have transitive peering? where A connects to B and B connects to C, and A is expected to communicate to C through B? This is because each peering connection is just a single static route on each side, added directly to each VPC's route table, pointing straight at the peer. There's no protocol exchanging reachability information between B and A, or between B and C. B has a route to A and a route to C, but nothing tells A "hey, go through B to reach C" because there's no routing intelligence running in between, only two independent point-to-point entries.
Why security group changes are immediate but NACL changes can behave differently? Security groups are stateful: they track connections, so if you allow inbound traffic on a port, the return traffic is automatically allowed out, no matching outbound rule needed. NACLs are stateless: they evaluate every packet independently against explicit rules in both directions, with no memory of the connection. That's the same distinction between an iptables conntrack-based rule (which tracks connection state) and a plain stateless packet filter. It's why NACL misconfigurations are a more common source of "one direction works, the other doesn't" bugs than security group misconfigurations.
Why does subnet CIDR planning matter so much upfront? A network namespace doesn't renegotiate its address space once it's created; the range you assign it is fixed unless you tear it down and rebuild it. AWS subnets work the same way: you can't resize a subnet's CIDR block after creation. If you undersize a subnet early on, the fix later is migrating workloads to a new subnet, not adjusting the existing one. This is why real AWS architectures reserve more IP space up front than they think they'll need.
Why a route table, not a checkbox, is what makes a subnet "public."? There's no attribute on a subnet that says public: true. A subnet is public purely because its route table has a route sending 0.0.0.0/0 traffic to an Internet Gateway. Attach that same Internet Gateway route to a different subnet, and it becomes public too, nothing else changes. This maps directly to how vpcctl decides a namespace's behavior: it's entirely a function of what's in that namespace's routing table, not a flag set anywhere else.
Why peered VPCs can't have overlapping CIDR ranges? Peering just adds a route pointing at the peer's CIDR block. If two VPCs share overlapping address space, that route becomes ambiguous; the system can't tell which destination a given IP actually belongs to. This is the same reason you can't route between two Linux namespaces with identical subnet ranges: routing depends on non-overlapping destinations to make an unambiguous decision.
Why an Internet Gateway attached to a VPC doesn't automatically give every subnet internet access? Attaching the gateway just makes it available as a possible next hop for the VPC. Each subnet still needs its own route table entry pointing to it. This two step design (attach the gateway, then explicitly route to it per subnet) is why you can have a VPC with internet connectivity available but individual subnets still fully private, by simply not adding that route.

What Broke, and What It Taught Me

Building this surfaced a handful of real bugs, each of which mapped back to an "aha" about AWS:

Interface name length limits. Linux caps network interface names at 15 characters (IFNAMSIZ in the kernel). I hit this when generating veth pair names programmatically from VPC and subnet identifiers, since concatenating a VPC ID with a subnet ID blew past that limit, and the interface creation silently failed or was truncated in unexpected ways. This explains something about AWS I'd never questioned: why AWS enforces its own opaque, fixed-format resource IDs (vpc-0a52d63562a6bb5c6, subnet-xxxx) instead of letting you name resources freely and using those names at the networking layer. AWS isn't just being tidy; it's very likely working around the same low-level constraints, just hidden behind an abstraction layer you never see.
Unguarded top-level function calls executing at import time. This was a Python structural bug: code that should only run when explicitly called was instead executing the moment the module was imported, because it sat at the top level of the file instead of inside a function or behind an if __name__ == "__main__" guard. The practical effect was things happening before their dependencies existed. It forced me to think seriously about initialization order, which is exactly the same category of problem that shows up in Terraform when a route resource gets created before the NAT Gateway it depends on exists. Terraform normally infers this dependency graph from resource references, but when that inference fails (implicit dependencies it can't see, or resources defined in a way that hides the relationship), you get the same "this was built before its prerequisite existed" failure, just at the infrastructure layer instead of the code layer.
Missing -j ACCEPT targets in iptables chains. iptables rules that don't end in an explicit ACCEPT (or another terminating target) don't do anything on their own; they just fall through to the next rule, and eventually to the chain's default policy. I had rules that looked correct on paper but never actually accepted traffic because I'd forgotten the terminating target, so packets were silently dropped with zero error output. That's precisely the debugging experience of a "connection timed out" against a misconfigured AWS security group: there's no rejection, no error message, just silence, because a stateful firewall that doesn't explicitly allow traffic doesn't tell you it denied it either. Rebuilding this by hand made that failure mode intuitive rather than mysterious, since I'd actually watched packets vanish for the exact same structural reason.
delete_vpc name collisions. My state management identified VPCs by name, and I hadn't accounted for two VPCs being given the same name, which meant a delete operation could match and remove the wrong resource, or fail ambiguously. This is a small-scale version of why AWS enforces strict uniqueness constraints on resource identifiers within an account and region: without a uniqueness guarantee, any operation that looks up a resource by a human-readable identifier becomes unreliable the moment there's a collision. AWS solves this by generating unique IDs regardless of what name tag you attach, so the name is cosmetic and the ID is what every underlying operation actually references.
Race conditions between namespace creation and veth attachment. Bringing up a namespace and immediately attaching a veth pair to it sometimes failed if the namespace wasn't fully initialized yet, since these are asynchronous operations at the OS level even though they look sequential in a script. This maps directly onto a very common AWS/Terraform pattern: attaching an ENI, an EBS volume, or a security group to an EC2 instance immediately after the instance is launched, before it's actually in a running state. Both cases are the same underlying lesson: that "created" and "ready to be attached to" are not the same moment, and code that assumes otherwise will fail intermittently rather than consistently, which makes it worse to debug.

Takeaway

None of this changes how you'd actually configure a VPC in the console or in Terraform. But it changes how you debug one. When a security group rule "isn't working," or a peering connection isn't routing traffic, or a private subnet can't reach the internet, knowing that these are, underneath, just routing tables and stateful packet filters makes the failure modes obvious instead of opaque.

If you want to build the same intuition, the fastest path isn't reading more VPC documentation; it's picking one AWS networking concept and asking "what would I have to build, from raw Linux primitives, to reproduce this behavior?" You'll hit the edge cases AWS handles for you, and you'll understand exactly why they exist.

vpcctl is written in Python and available on GitHub.

Nginx from Zero: Config Files to HTTPS

GERALD IZUCHUKWU — Mon, 27 Jul 2026 16:46:30 +0000

This would be a simple write-up explaining Nginx to a complete beginner.

Nginx Folder Structure

An Nginx folder can range from having just a single nginx.conf file to several other directories and files. Let's explore!
Nginx reads the nginx.conf file; while other files can be configured, Nginx readsnginx.conf directly; any other file must be explicitly included or referenced from there. A simple nginx.conf contains the following blocks of configuration

user www-data;
worker_processes auto;

events {
    worker_connections 1024;
}

http {
    include mime.types;
    default_type  application/octet-stream;

    sendfile on;
    keepalive_timeout 65;

    include /etc/nginx/conf.d/*.conf;
}

user www-data tells Nginx what user the worker processes should run as. Nginx master process will always start as root, so it can bind to ports like 80 and 443 on the host machine, but as soon as the master process initializes, the worker processes run but not with root privileges. The user of the worker process can be obtained using the command ps aux | grep nginx, and for most Ubuntu or Debian Systems, the user is typically www-data

Why not "ubuntu"? The "ubuntu" user is your login account. It owns your shell, PM2 processes, and Node.js apps. Nginx should run under a dedicated service account like www-data because it has fewer privileges (better security), it's the standard on Ubuntu, and permissions are easier to manage.

worker_processes auto tells Nginx to create one worker per CPU core of the host machine. A specific number can be defined in this block, but it is safest for Nginx to adapt to the host machine. The worker processes perform the actual work of serving requests, while the master process manages them.

events{} block defines or configures how workers handle connections, and this is defined with worker_connections 1024, which is the maximum number of connections a worker can handle simultaneously. What this means is that if we have 4 workers and 1024 worker connections, then we will have roughly 4096(4*1024) simultaneous connections that the workers can handle.

http{} block is used to define everything related to HTTP and HTTPS configuration. Inside it, we find things like

include mime.types; This tells browsers what type of file they are receiving, e.g., text/html, text/css, etc.
default_type application/octet-stream; A fallback MIME type if Nginx encounters a file type it doesn't understand.
keepalive_timeout 65; Normally, after sending a response, the connection closes, but with this line, Nginx opens the connection for up to 65 seconds, waiting for additional requests before closing it. This reduces the overhead of creating new TCP connections for every resource on a page.
include /etc/nginx/conf.d/*.conf; By default, Nginx won't read other config files, but this tells Nginx to read every file with the .conf extension inside the /etc/nginx/conf.d/ folder as if the contents were written in the nginx.conf file. This file usually contains the server {} block

The typical server block contains the settings for one website or application. Here is a common example with the most important directives

server {
    # Port to listen on
    listen 80;

    # Domain names this server responds to
    server_name example.com www.example.com;

    # Root directory for static files
    root /var/www/html;

    # Default file to serve
    index index.html index.htm;

    # Access and error logs
    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;

    # Handle requests
    location / {
        try_files $uri $uri/ =404;
    }

    # Custom error page
    error_page 404 /404.html;

    location = /404.html {
        internal;
    }
}

listen 80; tells Nginx to accept incoming HTTP requests on port 80. For HTTPS, we will use listen 443 ssl;. Listening can be done on multiple ports.

server_name This specifies which hostnames this server block should respond to. It can be your domain name or, in most development cases, localhost.

server_name _; is used to match any hostname not defined in the server block. It is mostly used with a default server to catch all placeholder. You would use it when you have multiple server_name blocks and want explicit, deliberate control over what happens when none of them match, rather than letting Nginx silently pick the first one it finds.

root /var/www/html; This is the directory where Nginx looks for static files. If a request comes in for GET /about.html, Nginx looks for /var/www/html/about.html

index index.html index.htm; When a user visits www.example.com, Nginx looks for index.html or index.htm and serves whichever it finds first.

access_log and error_log are both directives (keywords) in Nginx, and it is used to specify where the access logs and errors will be saved. It is standard practice to save both logs in the same directory /var/log/nginx/. While access_logs are saved in access.log files, error_logs are saved in error.log files. Access logs record every request, and error logs record every error or warning request.

location {} block is used to specify how Nginx handles requests for a particular file path. It varies, depending on whether you are serving static files or reverse proxying. A simple static file location block might look like this

location / {
    try_files $uri $uri/ =404;
}

This means that if someone requests/images/cat.png, Nginx checks and, if the file exists, serves it; if not, it returns a 404 error. The general syntax is to try the files one after the other until a match is found, and if no match is found, it resolves to the fallback, which is the last argument passed.

The location block can also look like this when it is reverse proxying

location / {
  proxy_pass http://localhost:3000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

proxy_pass http://localhost:3000; Forwards the client's request to the backend application running on localhost (the same machine) on port 3000, then returns the backend's response to the client.
proxy_set_header Host $host; Sends the original Host header (for example, example.com) to the backend so it knows which domain the client requested, rather than seeing localhost:3000
proxy_set_header X-Real-IP $remote_addr; Passes the client's actual IP address to the backend application so it knows who made the request instead of only seeing the Nginx server's IP.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; Sends a list of all client and proxy IP addresses the request has passed through, appending the current client's IP to any existing list, which is useful when multiple reverse proxies are in place.

For example
If the client IP is 203.0.113.10
and the request passes through another proxy of 198.51.100.5
then Nginx forwards X-Forwarded-For: 203.0.113.10, 198.51.100.5

proxy_set_header X-Forwarded-Proto $scheme; Tells the backend whether the client originally connected using HTTP or HTTPS, allowing the application to generate correct URLs, perform HTTPS redirects, or enforce secure cookies.

For example
Client visits https://example.com → X-Forwarded-Proto: https
Client visits http://example.com → X-Forwarded-Proto: http

These proxy_set_header directives ensure your backend application sees information about the original client request, rather than only seeing requests coming from Nginx itself.

error_page 404 /404.html; This is used to customize an error page that Nginx will serve when we hit a 404 error, instead of the default 404.

That's it for the basic configuration on Nginx, and most of the time, this setup will be all you need to set up a simple HTTP static file server or reverse proxy server. Now all of these could be in the nginx.conf file, or you can create another file and call it whatever you like, say proxy_setup.conf, and because our server block most times is our largest block, we can move the server block to the file created and reference that file from our original nginx.conf. This keeps our files separated and easy to read.

HTTPS NGINX

What problem is HTTPS trying to solve?

Imagine you are logging in to a website via HTTP and entering your credentials. Since HTTP is just a hypertext transfer protocol, all the details you entered, including sensitive information, will be sent as plain text, and this information can and will be seen by anyone in between. This can include your ISP, someone on a public WiFi, and even a hacker. HTTP does not provide encryption, authentication, or integrity checks; this is where HTTPS comes in.

The S in HTTPS stands for secure, and this means information sent over HTTPS will be secured in the sense that it will be encrypted, will be authenticated, and will have some checks that look out for tampering. So HTTPS is HTTP running inside an encrypted TLS connection.

SSL vs TLS

SSL means Secure Sockets Layer. It was the original encryption protocol. SSL introduced the concept of a handshake before any data was exchanged. There were several versions of SSL, and version SSL 3.0 was the standard for a long time, but today SSL is obsolete, and TLS replaced it.

TLS means Transport Layer Security. Instead of fixing SSL indefinitely, the standards community developed a new protocol. Think of TLS as the next generation of SSL, and serves the same purpose. People still say 'SSL Certificate' till today, but that's simply because the SSL name stuck. In reality, if you obtain a certificate today from a certificate authority like Let's Encrypt or DigiCert, it's used with TLS, not SSL. So the terms SSL Certificate and TLS Certificate are commonly used interchangeably, but TLS Certificate is technically correct.

Compared with SSL, TLS offers:

Stronger encryption algorithms.
Better key exchange mechanisms.
Better protection against downgrade attacks.
Stronger integrity checks.
Faster handshakes (especially TLS 1.3).
Removal of outdated and insecure cryptographic features

What you need before setting up HTTPS

Setting up HTTPS is not as hard as most people think; you need a few things in place before you can set it up for reverse proxying on your server. First, you need to have a domain name pointing to your server's IP address. This is because HTTPS is secure and it uses a TLS/SSL certificate to prove the server's identity. Picture it this way: when you browse a website, for example, example.com, the browser asks, "Can you prove you are actually example.com?" and the server replies by providing a certificate. The browser verifies that the certificate was issued by a trusted Certificate Authority (CA), that the certificate hasn't expired, and that the hostname you're visiting matches one of the names on the certificate. Now, if you are visiting example.com and the certificate is for example.com, everything is fine. On the other hand, if you are visiting https://203.0.113.10 and the certificate is for example.com, the browser will show a certificate warning because the names don't match.

Let's Encrypt is the CA most people use for free certificates, and it requires a domain name, such as example.com, api.example.com, or myapp.dev. It checks/validates that you control the domain before issuing the certificate. It will not issue a normal certificate for https://203.0.113.10.

Can HTTPS work with an IP address? Yes, but it's uncommon. A Certificate Authority can issue a certificate containing an IP address instead of a domain, but not all CAs offer this; it's less common, and it's generally used in enterprise or internal environments.

Setting Up HTTPS NGINX

Get your domain name Some platforms allow you to own your own domain and subdomain names for free, such as FreeDomain. Let's say our domain name is myspeech.com
Point your domain name to your IP address After getting the domain name, you can use the same platform you got the name from to point your domain name to your IP address, or you can use a cloud provider like AWS Route53. This takes up to 3 minutes, and the command nslookup domain name allows you to confirm if your domain name points to your server IP address
Create the HTTP for your website This step is not compulsory, but it makes it easy to create the HTTPS version
Create a new config file in the sites-available folder sudo nano /etc/nginx/sites-available/myspeech.com.conf
Create the conf file for myspeech.com.conf

server {
    listen 80;
    listen [::]:80;
    server_name myspeech.com www.myspeech.com;

    location / {
      proxy_pass http://localhost:3002;
      proxy_http_version 1.1;
      proxy_set_header Host              $host;
      proxy_set_header X-Real-IP         $remote_addr;
      proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Simple health check — no backend needed, nginx answers directly
    location /health {
        return 200 'OK\n';
        add_header Content-Type text/plain;
    }
}

Enable the site sudo ln -s /etc/nginx/sites-available/myspeech.com.conf /etc/nginx/sites-enabled/ and disable the default nginx page sudo rm -f /etc/nginx/sites-enabled/default
Test config syntax sudo nginx -t and if "syntax is ok" then reload sudo systemctl reload nginx
Test your setup by hitting the health route curl http://myspeech.com/health or the service route curl http://myspeech.com/

If we get our desired response on HTTP, we can then move to HTTPS

Check if certbot exists certbot --version
Then run this single command sudo certbot --nginx -d myspeech.com.

Certbot will:

Detect your existing nginx config

Issue the cert from Let's Encrypt

Auto-modify your nginx config to add SSL

Set up the HTTP → HTTPS redirect automatically

Check the new configuration and reload nginx sudo nginx -t && sudo systemctl reload nginx
Test your setup by hitting the health route curl https://myspeech.com/health or the service route curl https://myspeech.com/

Why is HTTPS already working without you writing the 443 block?

That's certbot's magic. When you run certbot --nginx, it reads your existing config and automatically injects the SSL server block and the HTTP to HTTPS redirect into your conf file. Certbot gives you a working HTTPS setup, but it is bare minimum; you can choose to add other functionalities depending on your requirements

Traditional IT vs Cloud Computing: The Great Shift

GERALD IZUCHUKWU — Thu, 23 Apr 2026 09:46:02 +0000

For decades, organizations relied on Traditional IT as the backbone of their technology operations. This meant owning and managing physical infrastructure—servers, storage devices, and networking equipment—housed in dedicated data centres. While this model gave companies full control, it also came with heavy responsibilities. Businesses had to invest large amounts of capital upfront, maintain hardware, handle failures, and plan capacity far in advance. Scaling was slow and expensive; if demand increased, new hardware had to be purchased and installed, often taking weeks or months.

Then came Cloud Computing, a model that fundamentally changed how technology is delivered. Instead of owning infrastructure, companies can now access computing resources—servers, databases, storage, and more—over the internet. These resources are available on-demand and operate on a pay-as-you-go pricing model. This means businesses only pay for what they use, eliminating the need for massive upfront investments. More importantly, cloud platforms allow near-instant scalability. Whether you're launching a startup or handling millions of users, you can scale resources up or down in minutes.

The “Why” Behind the Shift

So why are modern businesses moving to the cloud? The answer lies in speed, flexibility, and innovation. In today’s fast-paced digital world, companies need to experiment, deploy, and iterate quickly. Traditional IT simply can’t keep up with this demand. Cloud computing removes the bottlenecks associated with hardware procurement and infrastructure setup, enabling teams to focus on building and improving products.

Additionally, the cloud supports global accessibility. Teams can collaborate from anywhere, and applications can be deployed closer to users worldwide. This not only improves performance but also enhances user experience. Ultimately, the cloud empowers businesses to innovate faster, reduce operational overhead, and stay competitive.

The DevOps Connection

This shift to cloud computing is also what makes DevOps possible at scale. DevOps is all about automation, collaboration, and continuous delivery and the cloud provides the perfect environment for these practices. With cloud platforms, teams can automate infrastructure provisioning, deploy applications using CI/CD pipelines, and monitor systems in real time.

In a traditional IT setup, implementing such automation would be complex and slow due to hardware limitations. In contrast, the cloud enables Infrastructure as Code (IaC), containerization, and rapid deployment cycles. This allows development and operations teams to work more closely together, reducing friction and accelerating delivery.

Final Thoughts

The transition from traditional IT to cloud computing is more than just a technological upgrade, it’s a mindset shift. It moves organizations from rigid, hardware-focused operations to flexible, software-driven innovation. For anyone starting a journey in cloud and DevOps, understanding this shift is essential as it’s the foundation for everything that comes next.

Provisioning A Three-Tier Application on AWS using Infrastructure-As-Code (IaC)

GERALD IZUCHUKWU — Sat, 07 Dec 2024 10:33:01 +0000

This is a general architecture of what we will build. In case it isn't clear enough, please click here

IaC stands for Infrastructure as code and for a while I struggled to understand this concept, and when it seemed like I was starting to get it, I started confusing it with some other thing. IaC allows you to build, change, and manage your infrastructure in a safe, consistent, and repeatable way by defining resource configurations that you can version, reuse, and share. Infrastructure as code is basically provisioning or creating your resources through code or configuration files, in other words, automating the process of creating them in one click, instead of creating them singly through GUI or CLI, and Terraform is a tool that helps us to do that. An AWS cloud native used to also achieve IaC is AWS CLoudFormation and you can learn more about it here

Terraform is an open-source tool that efficiently helps us to provision infrastructure. It is owned by Hashicorp and uses its own language HCL (Hashicorp Configuration Language), for the configuration of these infrastructures. Terraform can be used for several things but since it is only an IaC provisioning tool, it also has its limitations.

This article focuses on using Terraform to provision a three-tier application on AWS. There are a lot of three-tier apps out there, maybe more detailed than this but what I intend to do for this is to explain every concept used here, to help me understand further as it takes a while for me to grasp a concept fully and to help people like me.

This writeup will use the following technologies

Network

VPC
Subnet
Route Table
Internet Gateway
Nat Gateway
Security Groups

Compute

launch template
Key pair
Elastic Load Balancer
Target Groups
Auto Scaling Groups

Database

RDS Database
Subnet Groups

Other AWS Resources

IAM Role
S3 Bucket
AWS SNS
AWS CloudWatch

Other Non-AWS Resources

Nginx
Docker
Nodejs

We are going to break this down into steps

STEP 1: Upload your static files and logic code to Amazon S3 Bucket

To do this, we need to create an S3 bucket, create two folders, and name them frontend and backend (can be named otherwise). In the frontend folder, upload all your static files as well as your nginx.conf file. In the backend folder, we upload all our logic code files. A link to the repo can be found here

Dont forget to name your bucket something unique as bucket names are specific per region

STEP 2: Set up IAM (User, Roles and Policies)

You can use various ways to configure AWS authentication, I will walk you through using IAM

An IAM user represents a specific person or application that interacts with resources. This is the "user" that allows Terraform to perform certain tasks in our AWS account. A User's action is defined by the policies attached to that user. An IAM User is quite different from an IAM Role because, a user is mostly configured to perform long-term tasks as it has permanent credentials, whereas an IAM role is for short-term and immediate functions as its credentials are temporary. To create an IAM user for CLI, follow the following steps:

Visit AWS Management Console
Navigate to IAM
Add User, give the user a name
Attach AdminstratorAccess Policy to the user
Review and create user
After creating a user, select the user and navigate to security credentials, scroll down to access keys, and click create access keys
Select a use case, add a description and the Access key and Secret Access key will be created, download the CSV and save it in a secure folder
Now set the environment variables

export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"
export AWS_REGION="your_region

Note: The reason why I gave this user Administrator Access policy privilege is because the user will interact with so many resources. The best practice is to compile all the rules the user will need to one policy and attach that policy to the user

Set up IAM Role We will need an IAM role to perform two basic functions, therefore we create an IAM role and attach two policies to it. The first policy will be for our instances to be able to read our uploaded code files from Amazon S3. The second policy we will need is the SSM managed instance core policy, to be able to connect to our instance instead of opening an SSH port. Both policies already exist in AWS so there will be no need to create them. The following steps are to be followed to create the IAM role with these two policies

Navigate to IAM, on the sidebar, click on roles
Click on AWS Service (since we are using it for EC2)
Choose EC2 for the use case, click next
Add permissions, search for "AmazonS3ReadOnlyAccess" and AmazonSSMManagedInstanceCore, check them, and click next.
Give the role a name and click "create role"

STEP 3: Set up your terraform

I won't assume that you already have Terraform installed, if you do, that's fine, if you don't follow the steps below.

Visit Teraform Download File
Select the download configuration for your operating system
Test if the download was successful using terraform -version
Create a folder for this terraform project, call it whatever you want. I will call mine "three-tier-app-projects" change directory into the folder cd three-tier-app-projects and create a file named main.tf
Add the terraform block and aws provider block into the file and save on the CLI, run the command terraform init This command takes a while, so be patient

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

  required_version = ">= 1.8.0"
}

provider "aws" {
  region  = "us-east-1"
}

Providers are plugins that help manage and create your resources in IaC. providers could include aws, docker, nginx, etc.
N/B For a simple project such as this, we can simply initialize terraform with only the provider block, without the terraform block

STEP 4: Setup VPC Network Aspect

Create a terraform.tfvars file. This file is used to store all our static variables
Create the VPC, which is a network house that houses all our resources. Store the vpc_cidr block in the terraform.tfvars, access it using the variable keyword before calling it in the aws_vpc resource block. Your main.tf and terraform.tfvars files should look like this

provider "aws" {
  region  = "us-east-1"
}

variable "env_prefix" {}
variable "avail_zone" {}
variable "vpc_cidr" {}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "${var.env_prefix}_vpc"
  }
}

In the terraform.tfvars file, we have

env_prefix    = "three-tier-demo"
avail_zone    = ["us-east-1a", "us-east-1b"]
vpc_cidr      = "10.0.0.0/16"

Run the following command -terraform fmt -terraform validate -terraform plan -terraform apply

terraform fmt formats the terraform files in the current directory it was ran, to follow a particular structure,
terraform validate checks if the configuration is syntactically valid and internally consistent,
terraform plan checks and outputs all the resources that will be added by the configuration and
terraform apply goes ahead to apply the configuration after the prompt-"yes" is entered. These are some of the most used terraform commands.

If everything goes well, a VPC named three-tier-demo_vpc will be provisioned in our us-east-1 zone

STEP 5: Let's finish creating our Network resources

Create Subnets for Public and Private resources in two availability zones for redundancy

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone       = var.avail_zone[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.env_prefix}_public_subnet-${count.index + 1}"
  }
}

resource "aws_subnet" "private" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index + 2)
  availability_zone       = var.avail_zone[count.index]
  map_public_ip_on_launch = false

  tags = {
    Name = "${var.env_prefix}_private_subnet-${count.index + 1}"
  }
}

resource "aws_subnet" "db_private" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index + 4)
  availability_zone       = var.avail_zone[count.index]
  map_public_ip_on_launch = false

  tags = {
    Name = "${var.env_prefix}_db_private_subnet-${count.index + 1}"
  }
}

Create Internet Gateway and Nat Gateway

resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "${var.env_prefix}_igw"
  }
}
resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id

  tags = {
    Name = "${var.env_prefix}_nat_gateway"
  }
}

resource "aws_eip" "this" {
  vpc = true
  tags = {
    Name = "${var.env_prefix}_eip_nat"
  }
}

N/B: NatGW and ElasticIP (eip) are paid for, there is no free tier available for this. NatGW costs $0.05/hr and EIP costs $0.005/hr when it is not attached to an ec2 instance

Create a Public and Private RouteTable and associate them to a subnet

resource "aws_route_table" "public_route_table" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.this.id
  }


  tags = {
    Name = "${var.env_prefix}_public_route_table"
  }
}

resource "aws_route_table_association" "public" {
  count          = 2
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public_route_table.id
}

resource "aws_route_table" "private_route_table" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_nat_gateway.nat.id
  }

  tags = {
    Name = "${var.env_prefix}_private_route_table"
  }
}

resource "aws_route_table_association" "private" {
  count          = 2
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private_route_table.id
}

resource "aws_route_table_association" "db_private" {
  count          = 2
  subnet_id      = aws_subnet.db_private[count.index].id
  route_table_id = aws_route_table.private_route_table.id
}

What did we just do?
We created a VPC for all our resources to live in with a CIDR block of 10.0.0.0/16
We created subnets which are like smaller houses in the VPC that house one or more resources.
The public subnets (internet-facing) have an internet gateway route configured in the route table, to allow internet access.
The private subnets (internal facing) have NAT gateway route configured in the route table to allow internet access when needed.
The elastic IP is for Controlled Access, it allows us to use a particularly defined public IP address that doesn't change even if the resource it is attached to goes down. With a NAT Gateway, instances in a private subnet do not have direct public IPs, enhancing security. By using an EIP with the NAT Gateway, you maintain control over how and when outbound internet access is granted without exposing private instances directly to the internet

STEP 6: Security

For security, we can set security on the subnet level(NACL) or instance level(Security groups). For this project, we will be using security groups. We need to create Security Groups for the Elastic Load Balancer, the Instances, and the RDS instance. To make our solution highly secure, we allow the web tier instance to receive traffic only from the external load balancer. We also allow the app tier instances to receive HTTP traffic only from the internal load balancer. Since the web tier and app tier has to communicate, we allow the internal load balancer to allow HTTP traffic only from the web-tier instances.

Create Security Group for external Load Balancer, that allows HTTP traffic on port 80 and HTTPS on port 443

resource "aws_security_group" "externalLoadBalancerSG" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [var.my_ip_address]
  }

  ingress {
    from_port   = 443 // https
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [var.my_ip_address]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "01. External LoadBalancer Security Group"
  }

}

Create SG for Web tier Instance, that allows traffic on Port 80 only from the external load balancer security group. You can add an SSH security group rule too, but it's best to use the SSM manager to access the instance terminal. If you prefer ssh, uncomment the ssh security group rule

resource "aws_security_group" "webserverSG" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.externalLoadBalancerSG.id]

  }
    #ingress {
    #from_port       = 22
    #to_port         = 22
    #protocol        = "tcp"
    #cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "02. Web Server Security Group"
  }
}

Create a security group for the internal load balancer, that allows HTTP traffic on port 80 only from the web-tier security groups

resource "aws_security_group" "internalLoadBalancerSG" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.webserverSG.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "03. Internal Load Balancer Security Group"
  }
}

Create a security group for app-tier instances that allows HTTP traffic on port 9662 (our NodeJS server port) only from the internal load balancer security group. If you will be needing ssh access, you can add the ssh rule like the one we added in the web tier security group

resource "aws_security_group" "appserverSG" {
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 9662
    to_port         = 9662
    protocol        = "tcp"
    security_groups = [aws_security_group.internalLoadBalancerSG.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "04. App Server Security Group"
  }
}

Finally, we will create a security group for our database instances that allow inbound traffic on port 3306 (AURORA/MYSQL) port

resource "aws_security_group" "dbserverSG" {
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.appserverSG.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "04. Database Server Security Group"
  }
}

The created security groups as seen on AWS console

STEP 7: Provision Web Tier Instances

IAM Role

We will be needing the IAM Role we created earlier with two policies - S3ReadOnly and SSManagerProfile. This role will be attached to the instances and it will enable them to read the uploaded files on S3 as well as connect to the instance's terminal through SSMManagedInstanceCore rather than opening port 22 for SSH-ing. We already created this role via the console but it can also be created using Terraform
Launch Template

Since we are trying to automate as much as possible and we want auto-scaling of instances, we use auto-scaling group. Auto-scaling group works with launch templates, so we create a launch template with keypair for SSH, entry-script i.e. a list of commands the instances will run after it is launched, and attach the IAM Profile created earlier. The frontend entry-script is here
Load Balancer

Next, we create a load balancer, we want this load balancer to be able to receive traffic from outside the VPC, so we make it internet-facing. The job of the load balancer is to distribute traffic evenly across all instances in order not to overwhelm a particular instance. For the load balancer to know the instances to distribute traffic evenly, the instances must be added to the load balancer's target group. The load balancer also checks the health of an instance before it routes traffic to it. The part of the ALB responsible for listening for incoming traffic requests, processing them, and routing them to the target group is called the listener. It listens on port 80 or 443 and routes these traffic requests based on the rules specified.
Auto-Scaling Group

The auto-scaling group is used to scale instances up or down based on traffic demand. For this to work, we specify the launch template, the minimum and maximum amount of instances to create, the subnets to launch these instances in, the target group to place these instances in for the ALB, as well as the health check. We also set an autoscaling policy to scale up or down the instances.
The link to the nginx server configuration is here

STEP 8: Provision App Tier Instances

Now for the backend configuration, we do something similar but with little but extremely important changes.

IAM Role

We also attach the same IAM role we created earlier to the backend instances
Launch Template

The launch template configuration is the same as earlier but the entry-script should be different as we want different commands to run in our backend instances. The backend entry-script is here
Load Balancer

This time, we create an internal load balancer(not internet facing) as we don't want internet traffic to hit our instances directly.
This load balancer also listens on port 80
Auto-Scaling Group

The Autoscaling group configuration is also similar to the previous, the only difference is the subnets where the instances should be placed in is the private subnets, and the target group should be that of the internal ALB.
The link to the backend express server configuration is here

We can see our created web-tier and app-tier instances to serve our frontend and backend files respectively

STEP 9: Provision Database Tier Instances

Database Subnet Group

First, we create a subnet group in two of the private instances already created earlier
DB Instance

Then we create our DB instances in those DB subnet groups. We specify the name, the engine, the username and password of the default user, the security group, and the Availability Zone, (do not use Multi-AZ as that will incur costs outside the free-tier. You can deploy the DB instance in one AZ and deploy a read replica in another AZ. Data from the read replica that way, we can still achieve redundancy

Step 10: Run Terraform Commands

We need to run the following command to test our configuration

terraform fmt
terraform validate
terraform plan -output=tf.plan
terraform apply tf.plan

If there are any errors, terraform will update you on these errors so you can correct them.
After successfully provisioning the infrastructure, visit the external load balancer DNS to view the hosted website

Navigate to EC2 page on AWS, and scroll the sidebar down for LoadBalancer.

Select the external load balancer, copy the DNS, and paste this into a browser to see the website and interact with the three-tier application. If you used my frontend code, it should look like this

Up Next:

We configure Amazon CloudWatch and SNS to notify us when there is any change in our project and Amazon Route53 for our DNS
We modularize the terraform configuration, which is a best practice.

The GitHub Repository for this Project

Refs:

IaC Provisioning A Three-Tier Application on AWS

GERALD IZUCHUKWU — Mon, 14 Oct 2024 10:54:53 +0000

IaC Provisioning A Three-Tier Application on AWS

IaC means Infrastructure as code and for a while I struggled to understand this concept, and when it seemed like I was starting to get it, I started confusing it with platform as code. IaC allows you to build, change, and manage your infrastructure in a safe, consistent, and repeatable way by defining resource configurations that you can version, reuse, and share. Infrastructure as code is basically provisioning or creating your resources through code or configuration files, in other words, automating the process of creating them in one click, instead of creating them singly through GUI or CLI, and Terraform is a tool that helps us to do that.

Terraform is an open-source tool that efficiently helps us to provision infrastructure, it is owned by Hashicorp and it also uses its own language HCL (Hashicorp Configuration Language), for the configuration of these infrastructures. Terraform can be used for several things but since it is only an IaC provisioning tool, it also has its limitations.

This write-up focuses on using Terraform to provision a three-tier application on AWS. There are a lot of three-tier apps out there, maybe more detailed than this but what I intend to do for this is to explain every concept used here, to help me understand further as it takes a while for me to grasp a concept fully and to help people like

This writeup will use the following technologies

Network

VPC
Subnet
Route Table
Internet Gateway
Nat Gateway
Security Groups

Compute

launch template
Key pair
Elastic Load Balancer
Target Groups
Auto Scaling Groups

Database

RDS Database
Subnet Groups

Others

IAM Role
S3 Bucket

We are going to break this down into steps

STEP 1: Upload our static files and logic code to Amazon S3 Bucket

To do this, we need to create an S3 bucket, create two folders, and name them frontend and backend. In the frontend folder, upload all our static files as well as our nginx.conf file. In the backend folder, we upload all our logic code files

STEP 2: Configure AWS auth

You can use various ways to configure AWS authentication, I will walk you through using IAM

Visit AWS Management Console
Navigate to IAM
Add User, give the user a name
Attach AdminstratorAccess Policy to the user
Review and create user
After creating a user, select the user and navigate to security credentials, scroll down to access keys, and click create access keys
Select a use case, add a description and the Access key and Secret Access key will be created, download the CSV and save it in a secure folder
Now set the environment variables

export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"
export AWS_REGION="your_region

STEP 3: Set up your terraform

I won't assume that you already have Terraform installed, if you do, that's fine, if you don't follow the steps below.

Visit Teraform Download File
Select the download configuration for your operating system
Test if the download was successful using "terraform -version"
Create a folder for this terraform project, call it whatever you want. I will call mine "three-tier-app-projects" change directory into the folder cd three-tier-app-projects and create a file named main.tf
Add the terraform block and aws provider block into the file and save on the CLI, run the command terraform init This command takes a while, so be patient

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

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-east-1"
}

STEP 4: Setup Network Aspect

Create a terraform.tfvars file. This file is used to store all our static variables
Create the VPC, which is a network house that houses all our resources. Store the vpc_cidr block in the >terraform.tfvars, access it using the variable keyword before calling it in the aws_vpc block. Your main.tf and terraform.tfvars files should look like this

provider "aws" {
  region  = "us-east-1"
}

variable "env_prefix" {}
variable "avail_zone" {}
variable "vpc_cidr" {}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "${var.env_prefix}_vpc"
  }
}

env_prefix    = "three-tier-demo"
avail_zone    = ["us-east-1a", "us-east-1b"]
vpc_cidr      = "10.0.0.0/16"

Run the following command terraform fmt terraform validate terraform plan terraform apply

terraform fmt formats the file, to follow a particular structure
terraform validate checks if the configuration is syntactically valid and internally consistent
terraform plan checks and outputs all the resources that will be added by the configuration
terraform apply goes ahead to apply the configuration after the prompt is entered

If everything goes well, a VPC named three-tier-demo_vpc will be provisioned in our us-east-1 zone

STEP 5: Let's finish creating our Network resources

Create Subnets for Public and Private resources in two availability zones for redundancy

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone       = var.avail_zone[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.env_prefix}_public_subnet-${count.index + 1}"
  }
}

resource "aws_subnet" "private" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index + 2)
  availability_zone       = var.avail_zone[count.index]
  map_public_ip_on_launch = false

  tags = {
    Name = "${var.env_prefix}_private_subnet-${count.index + 1}"
  }
}

resource "aws_subnet" "db_private" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index + 4)
  availability_zone       = var.avail_zone[count.index]
  map_public_ip_on_launch = false

  tags = {
    Name = "${var.env_prefix}_db_private_subnet-${count.index + 1}"
  }
}

Create Internet Gateway and Nat Gateway

resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "${var.env_prefix}_igw"
  }
}
resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id

  tags = {
    Name = "${var.env_prefix}_nat_gateway"
  }
}

resource "aws_eip" "nat" {
  vpc = true
  tags = {
    Name = "${var.env_prefix}_eip_nat"
  }
}

N/B: NatGW and ElasticIP (eip) are paid for, there is no free tier available for this. NatGW costs $0.05/hr and EIP costs $0.005/hr it is not attached to an ec2 instance

Create a Public and Private RouteTable and associate them to a subnet

resource "aws_route_table" "public_route_table" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.this.id
  }


  tags = {
    Name = "${var.env_prefix}_public_route_table"
  }
}

resource "aws_route_table_association" "public" {
  count          = 2
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public_route_table.id
}

resource "aws_route_table" "private_route_table" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_nat_gateway.nat.id
  }

  tags = {
    Name = "${var.env_prefix}_private_route_table"
  }
}

resource "aws_route_table_association" "private" {
  count          = 2
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private_route_table.id
}

resource "aws_route_table_association" "db_private" {
  count          = 2
  subnet_id      = aws_subnet.db_private[count.index].id
  route_table_id = aws_route_table.private_route_table.id
}

What did we just do?
We created a VPC for all our resources to live in with a CIDR block of 10.0.0.0/16
We created subnets which are like smaller houses in the VPC that house one or more resources.
The public subnets (internet-facing) have an internet gateway route configured in the route table.
The private subnets (internal facing) have NAT gateway route configured in the route table.
The elastic IP is for Controlled Access. With a NAT Gateway, instances in a private subnet do not have direct public IPs, enhancing security. By using an EIP with the NAT Gateway, you maintain control over how and when outbound internet access is granted without exposing private instances directly to the internet

STEP 6: Security

Create SG for external Load Balancer, that allows HTTP traffic on port 80 and HTTPS on port 443

resource "aws_security_group" "externalLoadBalancerSG" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [var.my_ip_address]
  }

  ingress {
    from_port   = 443 // https
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [var.my_ip_address]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "01. External LoadBalancer Security Group"
  }

}

Create SG for Web tier Instance, that allows traffic on Port 80 only from the external load balancer security group. You can add ssh security group rule too, but it's best to use the SSM ssh manager to access the instance terminal

resource "aws_security_group" "webserverSG" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.externalLoadBalancerSG.id]

  }
    ingress {
    from_port       = 22
    to_port         = 22
    protocol        = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "02. Web Server Security Group"
  }
}

Create a security group for the internal load balancer, that allows HTTP traffic on port 80 only from the web-tier security groups

resource "aws_security_group" "internalLoadBalancerSG" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.webserverSG.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "03. Internal Load Balancer Security Group"
  }
}

Create a security group for app-tier instances that allows HTTP traffic on port 9662 (our NodeJS server port) only from the internal load balancer security group

resource "aws_security_group" "appserverSG" {
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 9662
    to_port         = 9662
    protocol        = "tcp"
    security_groups = [aws_security_group.internalLoadBalancerSG.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "04. App Server Security Group"
  }
}

Finally, we will create a security group for our database instances that allows inbound traffic on port 3306 (AURORA/MYSQL) port

resource "aws_security_group" "dbserverSG" {
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.appserverSG.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "04. Database Server Security Group"
  }
}

STEP 7: Provision Web Tier Instances

IAM Profile

We will need to create an IAM Profile with two roles - S3ReadOnly and SSManagerProfile. This profile will be attached to the instances and it will enable them to read the uploaded files on S3 as well as connect to the instance's terminal through SSMManagedInstanceCore rather than opening port 22 for ssh-ing
Launch Template

Since we are trying to automate as much as possible and we want auto-scaling of instances, we use auto-scaling group. Auto-scaling group works with launch templates, so we create a launch template with keypair for ssh, entry-script, and attach the IAM Profile created earlier
Load Balancer

Next, we create a load balancer, we want this load balancer to be able to receive traffic from outside the VPC, so we make it internet-facing. The job of the load balancer is to distribute traffic evenly across all instances in order not to overwhelm a particular instance. For the load balancer to know the instances to evenly distribute traffic to, the instances must be added to the load balancer's target group. The load balancer also checks the health of an instance before it routes to it. The part of the ALB that is responsible for listens for incoming traffic requests, processes them, and routes them to the target group is called the listener. It listens on a port, 80 or 443, and routes these traffic requests based on the rules specified.
Auto-Scaling Group

The auto-scaling group is used to scale instances up or down based on traffic demand. For this to work, we specify the launch template, the minimum and maximum amount of instances to create, the subnets to launch these instances in, the target group to place these instances in for the ALB, as well as health check. We also set an autoscaling policy to scale up or down the instances.

STEP 8: Provision App Tier Instances

Now for the backend configuration, we do something similar but with little but extremely important changes.

IAM Profile

We also attach the same IAM profile we created earlier to the backend instances
Launch Template

The launch template configuration is the same as earlier but the entry-script should be different as we want different commands to run in our backend instances
Load Balancer

This time, we create an internal load balancer(not internet facing) as we don't want internet traffic to hit our instances directly.
This load balancer also listens on port 80
Auto-Scaling Group

The Autoscaling group configuration is also similar to the previous, the only difference is the subnets where the instances should be placed in is the private subnets, and the target group should be that of the internal ALB.

STEP 9: Provision Database Tier Instances

Database Subnet Group

First, we create a subnet group in two of the private instances already created earlier
DB Instance

Then we create our DB instances in those DB subnet groups. We specify the name, the engine, the username and password of the default user, the security group, the Availability Zone, (do not use Multi-AZ as that will incur costs outside the free-tier. You can deploy the DB instance in one AZ and deploy a read replica in another AZ. Data from the read replica that way, we can still achieve redundancy

Step 10: Run Terraform Commands

We need to run the following command to test our configuration

terraform fmt
terraform validate
terraform plan -output=tf.plan
terraform apply tf.plan

The GitHub Repository for this Project

Refs:

DEV Community: GERALD IZUCHUKWU

What AWS VPC Actually Does Under the Hood (I Rebuilt It on Linux to Find Out)

The AWS Abstraction

The Experiment

Mapping AWS Concepts to Linux Primitives

What Broke, and What It Taught Me

Takeaway

Nginx from Zero: Config Files to HTTPS

Nginx Folder Structure

HTTPS NGINX

What problem is HTTPS trying to solve?

SSL vs TLS

What you need before setting up HTTPS

Setting Up HTTPS NGINX

Why is HTTPS already working without you writing the 443 block?

Traditional IT vs Cloud Computing: The Great Shift

The “Why” Behind the Shift

The DevOps Connection

Final Thoughts

Provisioning A Three-Tier Application on AWS using Infrastructure-As-Code (IaC)

Network

Compute

Database

Other AWS Resources

Other Non-AWS Resources

STEP 1: Upload your static files and logic code to Amazon S3 Bucket

STEP 2: Set up IAM (User, Roles and Policies)

STEP 3: Set up your terraform

STEP 4: Setup VPC Network Aspect

STEP 5: Let's finish creating our Network resources

STEP 6: Security

STEP 7: Provision Web Tier Instances

IAM Role

Launch Template

Load Balancer

Auto-Scaling Group

STEP 8: Provision App Tier Instances

IAM Role

Launch Template

Load Balancer

Auto-Scaling Group

STEP 9: Provision Database Tier Instances

Database Subnet Group

DB Instance

Step 10: Run Terraform Commands

IaC Provisioning A Three-Tier Application on AWS

Network

Compute

Database

Others

STEP 1: Upload our static files and logic code to Amazon S3 Bucket

STEP 2: Configure AWS auth

STEP 3: Set up your terraform

STEP 4: Setup Network Aspect

STEP 5: Let's finish creating our Network resources

STEP 6: Security

STEP 7: Provision Web Tier Instances

IAM Profile

Launch Template

Load Balancer

Auto-Scaling Group

STEP 8: Provision App Tier Instances

IAM Profile

Launch Template

Load Balancer

Auto-Scaling Group

STEP 9: Provision Database Tier Instances

Database Subnet Group

DB Instance

Step 10: Run Terraform Commands