DEV Community: Ikoh Sylva

Your Website, Your Domain, Your HTTPS — A Complete AWS Custom Domain Setup

Ikoh Sylva — Sat, 06 Jun 2026 17:58:08 +0000

How to register a domain, wire it to Route 53, secure it with a free SSL certificate from ACM, and serve it over HTTPS through CloudFront start to finish.

In our last article, we deployed a static website to S3 and served it through CloudFront. The site was live, fast, and global but it was loading on a URL that looked like d1abc2xyz.cloudfront.net. Not exactly something you'd print on a business card.

This article fixes that. We're going to take that same site and give it a proper home: a custom domain, a free SSL certificate, and a verified HTTPS padlock that browsers love and employers notice.

By the end, your portfolio will load at yourname.com over HTTPS secured, professional, and running entirely on AWS managed infrastructure.

"A CloudFront URL tells the world you know AWS. A custom HTTPS domain tells them you finished the job."

What We're Building

This setup chains five AWS services together. Here's the full picture before we touch anything:

🌍 Browser (yourname.com)
    → 🗂️  Route 53 (DNS lookup)
        → 🔒  ACM Certificate (attached to CloudFront)
            → ☁️  CloudFront (CDN + HTTPS termination)
                → 🪣  S3 (private origin)

Route 53 translates yourname.com into CloudFront's address. CloudFront terminates the HTTPS connection using an ACM certificate, then fetches content from the private S3 bucket as needed.

The four phases:

Phase	What you're doing
Phase 1	Register your domain (or bring an existing one)
Phase 2	Create a hosted zone and update nameservers
Phase 3	Request a free SSL certificate via ACM with DNS validation
Phase 4	Attach the domain and certificate to CloudFront

Phase 1 — Register Your Domain

You have two paths: register directly through Route 53, or bring a domain you already own from another registrar.

Option A: Register through Route 53

Navigate to Route 53 → Registered domains → Register domain. Search for your name, add it to cart, and complete checkout. AWS automatically creates a hosted zone and configures the nameservers Phase 2 is essentially done for you.

⚠️ Pricing heads-up: Route 53 domain registration starts at $13/year for .com and varies by TLD. Unlike S3 and CloudFront, domain registration has no free tier. Hosted zones also cost $0.50/month.

Option B: Bring a domain from another registrar

If you already own a domain from Namecheap, GoDaddy, or elsewhere great. Skip this phase and go straight to Phase 2. You'll update the nameservers at your existing registrar to point at Route 53.

Phase 2 — Connect Your Domain to Route 53

This is the step that hands DNS authority over to AWS. Once done, Route 53 controls where traffic for your domain goes.

Step 1 — Create a hosted zone

Go to Route 53 → Hosted zones → Create hosted zone.

Enter your domain name (e.g. yourname.com)
Leave type as Public hosted zone
Click Create hosted zone

AWS generates four nameserver (NS) records automatically. They look something like this:

ns-412.awsdns-51.com
ns-1624.awsdns-11.co.uk
ns-879.awsdns-45.net
ns-1383.awsdns-44.org

Copy all four. You'll paste them into your registrar in the next step.

Step 2 — Update nameservers at your registrar

Log into wherever you registered your domain and find the nameserver settings. Replace the existing nameservers with the four AWS values from your hosted zone and save.

⚠️ DNS propagation takes time: Nameserver changes can take anywhere from a few minutes to 48 hours to propagate globally. In practice most registrars update within 15–30 minutes. Check propagation status at dnschecker.org by searching your domain for NS records.

🔍 What's actually happening here: When a browser looks up your domain, it asks the internet "who's authoritative for yourname.com?" The answer comes from your registrar's registry and it points to your nameservers. By switching those nameservers to Route 53, you're telling the entire DNS system: "Ask AWS. They know where this site lives."

Phase 3 — Request a Free SSL Certificate with ACM

AWS Certificate Manager issues free, auto-renewing SSL/TLS certificates. Before you click anything, read this:

⚠️ Region matters — use us-east-1 only: CloudFront only accepts ACM certificates created in the us-east-1 (N. Virginia) region. No exceptions. Before you start, confirm the region selector in the top-right corner of the AWS console says US East (N. Virginia).

Step 1 — Request the certificate

Navigate to ACM → Request a certificate → Request a public certificate.

Under Fully qualified domain names, enter your root domain: yourname.com
Click Add another name and add the www version: www.yourname.com
Select DNS validation — faster and fully automated compared to email validation
Click Request

✅ Always cover both root and www: One certificate can cover both yourname.com and www.yourname.com. Do this it means visitors reach your site regardless of whether they type www or not.

Step 2 — Validate ownership via DNS

ACM puts the certificate in Pending validation state. It needs proof you own the domain before issuing the cert.

Open the certificate in ACM and you'll see a validation section with CNAME records that need to be added to your DNS. Since your domain is already in Route 53, AWS makes this a single click:

Click Create records in Route 53. AWS adds the CNAME records automatically. Within minutes, ACM detects them and flips the certificate status to Issued.

🔍 Why DNS validation works this way: ACM can't issue a certificate for a domain you don't control. DNS validation proves ownership by asking you to add a specific CNAME to your DNS something only the domain owner can do. The record stays in your DNS permanently, which is how ACM silently auto-renews the certificate each year without any action from you.

For reference, the CNAME ACM asks you to create looks like this:

Name:   _a79865eb4cd1a6ab990a45779b4e0b96.yourname.com
Type:   CNAME
Value:  _424c7224e9b0a0d17feb4a6acf5c0c1f.acm-validations.aws

Wait until the certificate status shows Issued before continuing. Using Route 53 for DNS, this typically takes 2–5 minutes.

Phase 4 — Attach Everything to CloudFront

A hosted zone, an issued certificate now let's wire it all together.

Step 1 — Update your CloudFront distribution

Go to CloudFront → Your distribution → Edit (General tab).

Under Alternate domain names (CNAMEs), add both:

yourname.com
www.yourname.com

Under Custom SSL certificate, select the certificate you just issued. It should appear in the dropdown automatically this is why the us-east-1 region requirement exists.

Click Save changes. CloudFront will redeploy globally give it a few minutes.

Step 2 — Create DNS records in Route 53

Final step: tell Route 53 to send traffic for your domain to CloudFront. Go to Route 53 → Hosted zones → yourname.com → Create record.

Create an A record for the root domain:

Record name: leave blank (targets root domain)
Record type: A
Alias: toggle on
Route traffic to: Alias to CloudFront distribution
Select your distribution from the dropdown

Repeat the same steps for www: create another A alias record, enter www in the record name, point it at the same CloudFront distribution.

🔍 Why alias records instead of CNAMEs? Route 53 alias records are an AWS-specific DNS extension. They work at the root domain level regular CNAMEs can't. They also update automatically when CloudFront's underlying IPs change and don't incur an extra DNS query charge.

Confirm Your Site Loads Over HTTPS

Open a browser and visit https://yourname.com. You should see:

Your website loading correctly
A padlock icon in the address bar
A valid certificate issued to your domain (click the padlock → Certificate to verify)
http://yourname.com automatically redirecting to HTTPS

🎉 You're fully live — on your own domain, over HTTPS. Your site is now globally distributed through CloudFront, secured with a certificate AWS renews automatically every year, at a URL you actually own.

Troubleshooting Common Issues

Certificate not appearing in the CloudFront dropdown

Almost always a region issue. The certificate was created outside of us-east-1. Re-request it in the correct region it only takes a few minutes.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH or certificate warning

The alternate domain name entered in CloudFront doesn't exactly match what's on the ACM certificate. Double-check for typos they must be identical.

Site loads on the CloudFront URL but not the custom domain

DNS hasn't propagated yet, or the Route 53 alias records are missing or misconfigured. Run nslookup yourname.com in your terminal if it doesn't return a CloudFront address, the A records need attention.

www loads but the root domain doesn't (or vice versa)

One of the two A alias records is missing. Return to Route 53 and confirm you have alias records for both the root and the www subdomain, both pointing at the same CloudFront distribution.

What I Learned From This Project

Before doing this as part of the Cloud Engineering Program, DNS was a black box. You typed a domain, a page appeared, and everything in between was a mystery. Wiring up Route 53, ACM, and CloudFront by hand made it concrete and a few things genuinely clicked:

Nameservers are delegation, not redirection — you're not moving your domain, you're transferring authority over it. The internet now asks AWS, not your registrar, for answers about your domain.
DNS validation is cryptographic proof of ownership — ACM never emails you a link. The CNAME record is the proof. Only the domain owner can add it, so adding it is the trust signal.
Alias records solve a real DNS spec limitation — CNAMEs are forbidden at the root domain level by the DNS protocol itself. Route 53 alias records are AWS's pragmatic workaround, and they're better in every measurable way.
ACM auto-renewal is quietly brilliant — the validation CNAME never gets deleted. It sits in your DNS forever, letting ACM silently re-verify and renew your certificate each year without any action from you.

None of this clicked from reading documentation. It clicked from doing it, watching something break, and figuring out why.

Quick Reference: The Full Chain

# The complete setup, end to end

Domain registrar  →  nameservers updated to Route 53
Route 53          →  hosted zone with A alias records → CloudFront
ACM (us-east-1)   →  SSL cert, DNS-validated via Route 53 CNAME
CloudFront        →  custom domain + ACM cert attached, HTTP→HTTPS redirect
S3 bucket         →  private origin, OAC-restricted to CloudFront only

# End result
https://yourname.com  →  globally distributed · HTTPS · auto-renewing cert

What's Next?

Now that your site lives on a custom domain over HTTPS, the next step is removing the manual deploy process entirely. Hopefully we will cover setting up a GitHub Actions pipeline that auto-deploys on every git push and triggers a CloudFront cache invalidation so your changes go live without you ever opening the AWS console again.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

For those who may not be familiar, Sanjeev Kumar brings over 20 years of hands-on experience across multiple domains and every phase of product delivery. He is known for his strong architectural mindset, with a deep focus on Automation, DevOps, Cloud, and Security.

Sanjeev has extensive expertise in technology assessment, working closely with senior leadership, architects, and diverse software delivery teams to build scalable and secure systems. Beyond industry practice, he is also an active educator, running a YouTube channel dedicated to helping professionals successfully transition into DevOps and Cloud careers.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

Don’t miss out on this opportunity to transform your future and also save while doing it! Let’s grow together in the tech space. Also feel free to reach out if you need assistance or clarity regarding the program.

I’m Ikoh Sylva, a passionate cloud computing enthusiast with hands-on experience in AWS. I’m documenting my cloud journey here from a beginner’s perspective, aiming to inspire others along the way.

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Host Your Personal Website on AWS for (Almost) Free — With S3 and CloudFront

Ikoh Sylva — Sat, 30 May 2026 08:00:19 +0000

A practical walkthrough for deploying a static portfolio, resume, or about-me page the cloud-native way with HTTPS, global delivery, and zero server maintenance.

Every cloud engineer needs a live portfolio. It proves you can ship not just talk theory. This project is deceptively simple on the surface, but underneath it teaches you S3 permissions, CDN architecture, bucket policies, and origin access control all concepts that show up on AWS certifications and real-world cloud jobs.

In this guide, I'll walk you through exactly how I deployed my own static website using Amazon S3 for storage and Amazon CloudFront as the content delivery network no EC2, no server patching, no midnight alerts. Just clean, fast, globally distributed HTML.

"The best infrastructure is the kind you don't have to babysit at 2am."

Why S3 + CloudFront?

Before we touch a single AWS console screen, let's understand the architecture we're building and why it makes sense.


💰 Near-zero cost	S3 storage for a personal site costs pennies. CloudFront's free tier covers 1TB/month of data transfer.
⚡ Global speed	CloudFront caches your content at 400+ edge locations worldwide your site loads fast from Lagos to London.
🔒 HTTPS by default	CloudFront provides a free SSL certificate your visitors get a padlock icon without buying anything extra.
🛠️ Zero servers	No EC2, no patching, no SSH keys. AWS manages all the infrastructure underneath.

How the Architecture Works

Here's the request flow from browser to your HTML file:

🧑‍💻 Visitor  ──HTTPS──▶  ☁️ CloudFront (CDN Edge)  ──cache miss only──▶  🪣 S3 Bucket (private origin)

CloudFront sits in front of your S3 bucket as a CDN. When a visitor hits your URL, CloudFront checks if it has a cached copy at the nearest edge location. On a cache hit, it serves instantly. On a miss, it fetches from S3, caches it, and serves the response.

Your S3 bucket can remain private only CloudFront talks to it directly, which is far more secure than opening the bucket to the entire internet.

Let's Build It Step-by-Step

Step 1 — Create Your S3 Bucket

Log into the AWS Management Console and navigate to S3 → Create bucket.

Choose a globally unique bucket name (e.g. yourname-portfolio-2024)
Select your preferred AWS Region
Leave "Block all public access" checked — we'll handle access through CloudFront, not by making the bucket fully public
Leave versioning off for simplicity; enable it later if you want rollback support

⚠️ Common mistake: Beginners often unblock all public access immediately and make the bucket fully public. This works, but it's not best practice. The cleaner and more secure approach is to keep the bucket private and let CloudFront access it via an Origin Access Control (OAC) policy which is exactly what we'll do.

Step 2 — Upload Your HTML Files

Build or gather your static website files. At minimum, you need an index.html. A basic portfolio structure might look like:

my-portfolio/
├── index.html
├── style.css
├── script.js
└── assets/
    ├── profile-photo.jpg
    └── resume.pdf

In the S3 console, open your bucket and click Upload. Drag your files in, keeping the folder structure intact, then click Upload to confirm.

✅ Pro tip: If you have the AWS CLI set up, you can sync your local folder with:
aws s3 sync ./my-portfolio s3://your-bucket-name
Much faster for future updates.

Step 3 — Enable Static Website Hosting

In your S3 bucket, go to Properties → Static website hosting → Edit.

Enable static website hosting
Set Index document to index.html
Optionally set Error document to 404.html

Save changes. AWS will give you an S3 website endpoint URL. Don't share this publicly it's HTTP only and bypasses CloudFront. Think of it as a staging preview.

Step 4 — Create a CloudFront Distribution

Navigate to CloudFront → Create distribution. This is where the magic happens.

Origin settings:

Origin domain: Select your S3 bucket from the dropdown (use the REST endpoint, not the website endpoint)
Origin access: Choose Origin access control settings (recommended)
Click Create new OAC give it a name and leave signing behaviour as "Sign requests"

Default cache behaviour:

Viewer protocol policy: Set to Redirect HTTP to HTTPS
Cache policy: Use CachingOptimized (AWS managed)

Settings:

Default root object: Enter index.html
Price class: Use all edge locations for best global performance, or restrict to a region to reduce cost

Click Create distribution. CloudFront will take a few minutes to deploy globally the status changes from "Deploying" to a green "Enabled".

Step 5 — Add the Bucket Policy for CloudFront OAC

After creating the distribution, the console will show a banner prompting you to update your S3 bucket policy. Click Copy policy, then navigate back to your S3 bucket → Permissions → Bucket policy → Edit and paste it in.

The generated policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DIST_ID"
        }
      }
    }
  ]
}

🔍 What this policy does: It grants the CloudFront service principal read access (s3:GetObject) to every object in your bucket but only from your specific CloudFront distribution. Not from anyone else's CloudFront. Not from the public internet. Just yours.

Step 6 — Test Your Live Site

Go back to CloudFront and copy your Distribution domain name it looks like d1abc2defgh3ij.cloudfront.net. Paste it in your browser.

You should see your index.html rendered, served over HTTPS, with a valid SSL certificate for free.

🎉 You're live! Your personal website is now globally distributed across AWS's edge network. Whether someone visits from Lagos, London, or Los Angeles they're getting a fast, secure experience.

Optional But Recommended: Use Your Own Domain

The CloudFront URL works fine, but yourname.com looks far more professional. Here's the short version:

Register a domain via Route 53 (or bring your own from Namecheap, GoDaddy, etc.)
Request a free SSL certificate via AWS Certificate Manager (ACM) in the us-east-1 region (required for CloudFront)
Add your custom domain as an Alternate domain name (CNAME) in your CloudFront distribution settings and attach the ACM certificate
In Route 53, create an A record (alias) pointing to your CloudFront distribution

What I Learned From This Project

When I first completed this as part of the Cloud Engineering Program, I thought it was going to be a simple file-upload exercise. It turned out to be a surprisingly rich lesson in cloud fundamentals:

IAM and resource-based policies — the bucket policy taught me how AWS evaluates permissions at the resource level, not just the user level
The principle of least privilege — keeping the S3 bucket private and exposing it only through CloudFront OAC is a real-world security pattern, not just textbook advice
CDN architecture — understanding cache hits vs. misses, TTLs, and edge locations made CloudFront feel less magical and more engineerable
DNS and SSL — hooking up Route 53 and ACM demystified how HTTPS actually works end-to-end

These aren't just resume bullet points. They're the building blocks of almost every AWS architecture you'll work on professionally.

Quick Reference: Services Used

Service	Role in This Project
Amazon S3	Object storage for your HTML/CSS/JS/assets
S3 Static Hosting	Turns the bucket into a web server (origin)
Bucket Policy	JSON policy granting CloudFront read access
CloudFront	CDN that caches and delivers content globally
OAC	Origin Access Control secure S3↔CloudFront connection
ACM	Free SSL/TLS certificate (optional, custom domain)
Route 53	DNS routing (optional, custom domain)

What's Next?

Once your static site is live, try extending it:

Add a CI/CD pipeline with GitHub Actions to auto-deploy on every push to your repo
Enable CloudFront invalidations (aws cloudfront create-invalidation) to clear the cache when you update your content
Explore S3 access logging to see who's visiting your site
Deploy a React or Next.js build the same S3 + CloudFront pattern scales directly to frontend frameworks

The static web hosting pattern is one of the most reusable skills in your AWS toolkit. Once you have it down, you'll reach for it constantly.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Monitoring Containers on AWS ECS with CloudWatch

Ikoh Sylva — Sat, 23 May 2026 19:46:39 +0000

One of the biggest realizations I had during my cloud engineering journey was this:

Deploying an application is only half the job.

The other half?

Monitoring it.
Understanding how it behaves under load.
Knowing when something is wrong before users complain.

Because in real-world cloud environments, applications are constantly consuming resources, handling requests, and responding to changing traffic patterns. If you’re not monitoring them properly, you’re essentially operating blind.

That’s exactly what this hands-on project aims to help us understand.

In this guide, I’ll walk you through how I monitored containerized workloads running on Amazon ECS, configured task resource settings, and visualized metrics using Amazon CloudWatch dashboards.

What we’ll Be Building

In this project, we will:

Deploy a containerized application on ECS
Configure CPU and memory allocation in the task definition
Monitor resource usage using CloudWatch
Build a dashboard with CPU and memory widgets
Simulate load to observe metric changes in real time

By the end, you’ll understand how to move from simply running containers to actually observing and managing them effectively.

Why Monitoring Matters

Imagine deploying an application that suddenly:

Runs out of memory
Uses excessive CPU
Becomes slow under traffic spikes

Without monitoring:

You won’t know why performance dropped
Troubleshooting becomes difficult
Downtime becomes more likely

With monitoring:

You gain visibility
You can detect issues early
You make informed scaling decisions

This is why observability is such a huge part of modern DevOps and Cloud Engineering.

Architecture Overview

Users
   |
   v
Amazon ECS Cluster
   |
Running ECS Service
   |
Task Definition
(CPU + Memory Allocation)
   |
CloudWatch Metrics & Dashboard

Step 1: ECS Cluster and Running Service

The first step was deploying a containerized application on ECS.

The deployment included:

An ECS Cluster
A Running ECS Service
Active ECS Tasks

This is the foundation where your application runs.

Step 2: Configure Task Definition Resources

One thing beginners often overlook is this:
Containers don’t have unlimited resources.

When creating the ECS task definition, I configured:

CPU allocation
Memory allocation

Example:

CPU: 512
Memory: 1024 MiB

Why This Matters

Resource allocation helps:

Prevent resource exhaustion
Improve application stability
Optimize cloud costs
Define scaling expectations

This is how cloud platforms control workload behavior.

Step 3: Monitoring with CloudWatch

Now comes the exciting part.

Once the ECS service was running, AWS automatically started sending metrics to CloudWatch.

I created a dashboard showing:

CPU utilization
Memory utilization

These widgets provided real-time visibility into how the container was behaving.

Creating the Dashboard

Go to CloudWatch
Navigate to Dashboards
Create Dashboard
Add Widgets:

ECS CPU Utilization
ECS Memory Utilization

What These Metrics Tell You

CPU Utilization

Shows how much processing power the container is using.

High CPU may indicate:

Heavy traffic
Inefficient code
Need for scaling

Memory Utilization

Shows RAM consumption.

High memory usage may indicate:

Memory leaks
Insufficient allocation
Application instability risks

Simulate Load

This was one of the most interesting parts.

To see real metric changes, I simulated load against the application using repeated browser refreshes or lightweight testing tools.

And suddenly:

CPU usage increased
Memory usage shifted

Watching the graphs move in real time made everything feel much more practical.

Why Simulating Load Is Important

This helps you understand:

How applications behave under pressure
When scaling might be needed
How monitoring tools detect changes

Common Mistakes Beginners Make

Ignoring Resource Limits
Containers can crash if memory is exhausted.
Not Monitoring Applications
You can’t fix what you can’t see.
Misinterpreting Metrics
Temporary spikes are normal patterns matter more.

What This Project Really Teaches

At first glance, this might seem like:

“Just another ECS deployment.”

But it’s actually teaching something deeper:

Operational visibility
Resource management
Observability fundamentals
Performance awareness

One of the most important transitions in cloud engineering is moving from:

“My application is running” to “I understand how my application is performing.”

That’s where monitoring changes everything.

This project helped reinforce that cloud engineering isn’t only about infrastructure it’s also about visibility, reliability, and operational intelligence.

And honestly? That’s where things start getting really interesting.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Deploying Metabase on AWS ECS (Fargate) with PostgreSQL (RDS)

Ikoh Sylva — Sat, 16 May 2026 07:42:54 +0000

At some point in your cloud journey, you stop just deploying applications and start thinking about data, persistence, and real-world architecture.

Because most production applications don’t just run they store, query, and visualize data.

That’s exactly what this project is about.

In this guide, I’ll walk you through how I deployed Metabase (an open-source business intelligence tool) on AWS using ECS with Fargate, and connected it to a PostgreSQL database hosted on RDS.

This is no longer just a “hello world” setup this is a real application backed by a real database.

What We’ll Be Building

In this project, we will:

Deploy Metabase using containers
Run it on Amazon ECS (Fargate)
Create a PostgreSQL database using Amazon RDS
Connect the application to the database
Configure networking and security for communication

By the end, we’ll have a fully functional data application in the cloud.

Why This Matters

This project introduces critical real-world concepts:

Application + Database architecture
Containerized workloads
Managed databases (RDS)
Secure service-to-service communication
Environment variable configuration

This is the kind of setup you’ll see in production systems.

Architecture Overview

User (Browser)
     |
     v
ECS Service (Fargate)
     |
Metabase Container
     |
     v
Amazon RDS (PostgreSQL)

Both ECS and RDS must be in the same VPC for private communication.

Step 1: Create the RDS PostgreSQL Database

Go to RDS → Create Database
Choose:

Engine: PostgreSQL
Template: Free tier (if available)

Configure:

DB instance identifier: metabase-db
Username: postgres
Password: (your choice)

Networking Settings

Place RDS in your VPC
Choose a private subnet (recommended)
Disable public access (best practice)

Security Group for RDS

Add inbound rule:

Port: 5432 (PostgreSQL)
Source: ECS security group

This allows only your container to access the database.

Step 2: Create ECS Cluster (Fargate)

Go to ECS
Create a cluster
Choose Fargate (Networking only)
Name it: metabase-cluster

Step 3: Create Task Definition

Go to Task Definitions → Create
Choose Fargate

Container Configuration

Container name: metabase
Image: metabase/metabase
Port mapping:
Container port: 3000

Environment Variables

Add the following:

MB_DB_TYPE=postgres
MB_DB_DBNAME=metabase
MB_DB_PORT=5432
MB_DB_USER=postgres
MB_DB_PASS=yourpassword
MB_DB_HOST=<RDS-ENDPOINT>

Replace <RDS-ENDPOINT> with your database endpoint.

This is how Metabase connects to PostgreSQL.

Step 4: Create ECS Service

Launch type: Fargate
Task definition: metabase-task
Number of tasks: 1

Networking Setup

Use the same VPC as RDS
Select subnets (public or private depending on access strategy)
Enable public IP (if accessing via browser)
Security Group for ECS

Add inbound rule:

Port: 3000
Source: your IP (recommended)

Step 5: Deploy and Run

Start the service
Wait for task status → RUNNING

Step 6: Access Metabase

Get the public IP of the ECS task
Open: http://<public-ip>:3000

You should see the Metabase setup screen!

Common Mistakes to Avoid

ECS and RDS in different VPCs
They won’t communicate.
Incorrect RDS endpoint
Connection will fail.
Missing security group rule (5432)
Database access will be blocked.
Wrong environment variables
Metabase won’t initialize properly.

What This Project Teaches You

This project is a major step forward.

You learn:

How applications connect to databases
How to configure secure communication
How to run stateful applications in the cloud
How real-world systems are structured

This is no longer just infrastructure it’s application architecture.

Real-World Use Cases

This setup is similar to:

Internal analytics dashboards
Business intelligence platforms
SaaS reporting tools
Monitoring and metrics visualization

Deploying Metabase with ECS and RDS is where things start to feel real.

You’re no longer just launching resources you’re building connected systems.

And that’s the difference between:

“Learning cloud” and “Thinking like a cloud engineer”

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Running Grafana on AWS ECS (Fargate)

Ikoh Sylva — Sat, 09 May 2026 19:48:31 +0000

At some point in your cloud journey, you move beyond just deploying servers…

…and start thinking about observability.

Because building systems is one thing.

Understanding how they behave in real time is another.

That’s where tools like Grafana come in.

In this guide, I’ll walk you through how I deployed Grafana on AWS using ECS with Fargate a fully managed container service without managing any servers.

What We’ll Be Building

In this project, we will:

Deploy Grafana using containers
Use Amazon ECS with Fargate (serverless compute for containers)
Expose the application on port 3000
Configure networking and security
Access Grafana via our browser

By the end, we’ll have a live Grafana dashboard running in the cloud.

Why This Matters

This project introduces you to:

Containerized applications
Serverless container orchestration
Networking in ECS
Security group configuration
Observability tools (Grafana)

These are real-world DevOps and Cloud Engineering skills.

Architecture Overview

Internet
   |
Public Subnet
   |
ECS Service (Fargate)
   |
Grafana Container (Port 3000)

No EC2 instances needed Fargate handles everything.

Step 1: Create an ECS Cluster

Go to ECS in the AWS Console
Click Create Cluster
Choose Fargate (Networking only)
Give it a name (e.g., grafana-cluster)

Step 2: Create a Task Definition

Go to Task Definitions → Create
Select Fargate

Configure:

Task name: grafana-task
CPU: 0.5 vCPU
Memory: 1GB

Add Container

Container name: grafana
Image: grafana/grafana
Port mapping:
Container port: 3000

This tells ECS to expose Grafana’s default port.

Step 3: Create a Service

Go to your cluster
Click Create Service

Configure:

Launch type: Fargate
Task definition: grafana-task
Number of tasks: 1

Networking Setup

This step is critical.

Choose a VPC
Select a public subnet
Enable Auto-assign public IP

Step 4: Configure Security Group

Create or modify a security group:

Inbound Rule

Type: Custom TCP
Port: 3000
Source: 0.0.0.0/0 (or restrict to your IP for better security)

This allows access to Grafana via browser.

Step 5: Deploy and Run

Launch the service
Wait for the task to reach RUNNING state

Step 6: Access Grafana

Once running:

Go to ECS → Tasks
Copy the Public IP

Open in browser:

http://<public-ip>:3000

You should see the Grafana login page!

Default Login

Username: admin
Password: admin

(You’ll be prompted to change it immediately.)

Assignment Deliverable (Proof)

To confirm your setup, capture screenshots showing:

ECS cluster
Running task
Task public IP
Grafana UI in browser

This proves:

✔ Successful deployment
✔ Proper networking
✔ Working containerized application

Common Mistakes to Avoid

Forgetting to open port 3000
You won’t be able to access Grafana.
Not assigning a public IP
Your service won’t be reachable.
Using wrong port mapping
Grafana won’t load properly.

What This Project Teaches You

This isn’t just about Grafana.

It teaches you:

How containers are deployed in the cloud
How ECS and Fargate work
How to expose applications securely
How modern infrastructure avoids managing servers

This is exactly how modern DevOps teams deploy applications.

Real-World Use Cases

Grafana is widely used for:

Monitoring cloud infrastructure
Visualizing metrics (CPU, memory, logs)
Integrating with tools like Prometheus and CloudWatch

Deploying Grafana on ECS Fargate is a powerful step forward in your cloud journey.

It moves you from:

“I can launch servers” to “I can now deploy and run real applications in the cloud”

And that’s where things start to get exciting.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Building a Multi-VPC Architecture on AWS

Ikoh Sylva — Sat, 02 May 2026 07:37:14 +0000

When people begin learning cloud networking, they often start with a single VPC.
And that’s fine… until you realize that real-world cloud environments rarely stop at just one VPC.

Organizations separate workloads for:

Security
Scalability
Team isolation
Environment segmentation (Dev, Staging, Production)

At that point, a new question arises:

How do these isolated networks communicate with each other securely?

That’s exactly what this hands-on project explores.

What We’ll Be Building

In this guide, we will:

Create two separate VPCs
Design public and private subnets in each VPC
Establish a VPC Peering connection
Configure route tables to enable communication

By the end, we’ll have a basic multi-VPC architecture, similar to what is used in real production environments.

Why This Matters

This project introduces core networking concepts every cloud engineer must understand:

Network isolation
CIDR block design
Routing between networks
Private communication without the internet

These are foundational skills for:

Cloud Engineers
DevOps Engineers
Solutions Architects

Architecture Overview

VPC-A (10.10.0.0/16)          VPC-B (10.20.0.0/16)
----------------------        ----------------------
Public Subnet                Public Subnet
Private Subnet               Private Subnet
        |                          |
        -------- VPC Peering -------

No Internet Gateway or NAT Gateway required this is purely internal communication.

Step 1: Create VPC-A

Name: VPC-A
CIDR block: 10.10.0.0/16

Step 2: Create Subnets in VPC-A

Public Subnet: 10.10.1.0/24
Private Subnet: 10.10.2.0/24

Step 3: Create VPC-B

Name: VPC-B
CIDR block: 10.20.0.0/16

Step 4: Create Subnets in VPC-B

Public Subnet: 10.20.1.0/24
Private Subnet: 10.20.2.0/24

Step 5: Create VPC Peering Connection

Go to VPC Dashboard → Peering Connections
Click Create Peering Connection
Select:
Requester: VPC-A
Accepter: VPC-B
Create and accept the request
Once accepted, the VPCs are logically connected but not yet able to communicate.

Step 6: Update Route Tables (Critical Step)

This is where many beginners get stuck.

For VPC-A Route Table:

Destination: 10.20.0.0/16
Target: VPC Peering Connection

For VPC-B Route Table:

Destination: 10.10.0.0/16
Target: VPC Peering Connection

Without this step, traffic will not flow, even though peering exists.

How It Works

Now:

Traffic from VPC-A → VPC-B is routed through the peering connection
Traffic from VPC-B → VPC-A follows the reverse route

This enables private, secure communication between networks.

Testing the Setup

To validate:

Launch EC2 instances in each VPC
Use private IPs to ping between them

If configured correctly:

✔ Instances should communicate successfully

Important Limitations of VPC Peering

Understanding limitations is key:

No transitive routing (A → B → C won’t work automatically)
CIDR blocks must not overlap
Each route must be manually configured

What This Project Teaches You

It teaches you:

How real-world architectures are segmented
How cloud networking differs from traditional networking
How routing enables communication
How to design secure, isolated systems

Real-World Use Cases

This setup is commonly used for:

Connecting Dev and Production environments
Separating application tiers
Multi-team architectures
Microservices communication across VPCs

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Launching a Windows Server on AWS EC2

Ikoh Sylva — Sat, 25 Apr 2026 19:11:05 +0000

When people start learning cloud engineering, they often begin with Linux servers and for good reason.

But in real-world environments, Windows servers are just as important.

From enterprise applications to legacy systems and Active Directory environments, Windows workloads are everywhere. So at some point in your cloud journey, you need to answer this question:

Can you confidently deploy and securely access a Windows server in the cloud?

In this guide, I’ll Walk you through exactly how to do that using AWS EC2 based on a hands-on task I completed during my cloud engineering training.

What We’ll Be Building

In this project, we will:

Launch a Windows Server EC2 instance
Deploy it in a public subnet
Configure secure access using RDP (Remote Desktop Protocol)
Restrict access to your own public IP address
Tag your instance for proper identification

By the end, you’ll have a fully running Windows server in the cloud that you can connect to remotely.

Why This Matters

This task teaches you several core cloud concepts:

Compute provisioning (EC2)
Networking (public subnets)
Security (security groups)
Remote access (RDP)
Resource management (tagging)

These are fundamental skills every cloud engineer must master.

Step 1: Launch a New EC2 Instance

Go to the AWS Management Console
Navigate to EC2 Dashboard
Click Launch Instance

Step 2: Choose Your AMI

Select:

Amazon Windows Server 2019 Base (or newer)

This provides a ready-to-use Windows environment.

Step 3: Choose Instance Type

Select t2.micro (Free Tier eligible)

Good for learning and basic testing.

Step 4: Add Name Tag

Give your instance a clear name, e.g.:

Name: Windows-Server-Lab

Tagging helps with:

Organization
Cost tracking
Resource identification

Step 5: Configure Networking

Make sure:

The instance is in a public subnet
Auto-assign Public IP is enabled

This ensures you can connect to it over the internet.

Step 6: Configure Security Group (Very Important)

Create a new security group with:

Inbound Rule

Type: RDP
Port: 3389
Source: My IP

This ensures:

✔ Only your IP can access the server
✔ The server is not exposed to the world

This is a key real-world security practice.

Step 7: Key Pair

Create or select an existing key pair
Download the .pem file

You’ll need this to decrypt the Windows password later.

Step 8: Launch the Instance

Click Launch Instance and wait for:

Instance state → Running
Status checks → 2/2 passed

Step 9: Connect via RDP

Once the instance is ready:

Select your instance
Click Connect
Choose RDP Client
Download the RDP file
Click Get Password
Upload your .pem key
Decrypt the password

Then connect using:

Username: Administrator
Password: (decrypted password)
You’re now inside your Windows server!

Common Mistakes to Avoid

Opening RDP to the world (0.0.0.0/0)
This is a major security risk.
Forgetting to enable public IP
You won’t be able to connect.
Losing your key pair
You won’t be able to retrieve the password.

What This Project Teaches You

This isn’t just about launching a server.
It teaches you:

How to think about security first
How cloud networking actually works
How to connect to real infrastructure
How to manage compute resources properly

This is the foundation of real-world cloud operations.

Launching a Windows EC2 instance might feel like a simple task but it introduces you to critical cloud concepts that scale into enterprise environments.

If you can do this confidently, you’re already building the skills needed to:

Manage enterprise workloads
Support cloud infrastructure
Work in DevOps or Cloud Engineering roles

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Managing Access the Right Way

Ikoh Sylva — Sat, 18 Apr 2026 17:59:14 +0000

When most people begin their cloud journey, they focus on launching servers, deploying apps, and building projects.

But there’s something just as important if not more:

Who has access to your cloud environment… and what can they do?

This is where AWS Identity Center comes in.

During my cloud engineering training, one of the foundational tasks I completed was setting up Identity Center, creating users, and assigning permissions properly. It may seem like a small step, but in reality, it’s how secure and scalable cloud environments are built.

In this article, I’ll walk you through:

Why it matters
How to configure it
How to create users and assign permissions

Let’s get into it.

Why This Matters

In real-world environments:

Multiple engineers access AWS
Teams have different responsibilities
Security is non-negotiable

Without proper identity management:

❌ Anyone could access sensitive resources
❌ Permissions could be too broad
❌ Auditing becomes difficult

With Identity Center:

✅ Access is controlled
✅ Permissions are clearly defined
✅ Security is enforced

Step 1: Enable AWS Identity Center

Go to the AWS Management Console
Search for “AWS Identity Center”
Click Enable

Once enabled, AWS creates an Identity Center instance for your account.

This is your central identity management system.

Step 2: Create a New User

Next, you’ll create a user that can access AWS resources.

Steps:

Navigate to Users
Click Add user
Enter:
Username
Email address
First and last name
Save the user

This represents a real person (or team member) who needs access.

Step 3: Assign a Permission Set

Permissions define what the user can actually do.

In this task, we use a predefined job function policy:

SecurityAudit

What This Policy Does:

Provides read-only access
Allows users to review configurations
Ideal for auditing and compliance checks

Steps to Assign:

Go to AWS Accounts
Select your account
Click Assign users or groups
Select the user you created
Choose Permission Set → SecurityAudit
Complete the assignment

How It All Comes Together

At this point:

Identity Center is enabled
A user has been created
Permissions have been assigned

This means:

✔ The user can log in
✔ They have controlled access
✔ They cannot make destructive changes

This is real-world security in action.

This also demonstrates:

Proper configuration
Successful user creation
Correct permission assignment

Best Practices (What I Learned Along the Way)

Never Use Root Account for Daily Tasks
Always use Identity Center or IAM users.
Follow Least Privilege Principle
Only grant permissions necessary for the task.
Use Roles Instead of Static Credentials
Temporary access is safer.
Group Users When Scaling
Instead of assigning permissions individually, use groups.

Why This Step Is Bigger Than It Looks

This isn’t just about clicking through AWS.

It teaches you:

How organizations manage access
How security is enforced at scale
How to think like a cloud engineer

Because in the real world:

Security is not optional it’s foundational.
Setting up AWS Identity Center and assigning permissions is one of those foundational skills that separates beginners from professionals.

It’s not flashy but it’s critical and if you understand this, you’re not just learning cloud you’re learning how to build secure systems that people can trust.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

AWS: Setting Up Your Account the Right Way

Ikoh Sylva — Sat, 11 Apr 2026 13:51:14 +0000

When I began my journey into cloud engineering, one of the very first steps I took was simple but incredibly important;

Setting up my AWS account.

It might sound basic, but this step is the gateway into the world of cloud computing. Whether you're aiming to become a Cloud Engineer, DevOps Engineer, or Solutions Architect, your AWS account is where everything begins.

In this guide, I’ll walk you through:

Why setting up an AWS account matters
How to create one properly
What to expect after setup
How to verify your account (as required in real training programs)

Let’s get into it.

Why You Need an AWS Account

Before you can deploy servers, build applications, or experiment with cloud services, you need access to a cloud platform and AWS is one of the most widely used in the world.

With an AWS account, you can:

Launch virtual servers (EC2)
Store data (S3)
Build scalable applications
Experiment with real-world cloud tools
Practice hands-on (which is critical!)

Cloud is not theory you learn it by doing.

Step 1: Create Your AWS Account

If you don’t already have an account, follow these steps:

1. Go to the AWS Website

Visit: https://aws.amazon.com

Click on “Create an AWS Account”

2. Enter Your Details
You’ll need:

A valid email address (preferably personal)
A strong password
An AWS account name (can be your name or brand)

3. Add Payment Information

AWS requires a debit/credit card for verification.

💡 Don’t worry:

You can stay within the Free Tier
You won’t be charged if you use services responsibly

4. Identity Verification
AWS will send a verification code to your phone.

5. Choose a Support Plan
Select the Basic (Free) Plan

Step 2: Log into the AWS Management Console

Once your account is created:

Go to the AWS Console
Sign in using your credentials

You’ll land on the AWS Management Console Dashboard this is your control center for everything in AWS.

Important Tips for Beginners

1. Stay Within Free Tier

AWS Free Tier includes:

EC2 (750 hours/month)
S3 storage
RDS usage

Always monitor usage to avoid charges.

2. Enable Billing Alerts

Set up alerts to avoid surprises:

Go to Billing Dashboard
Enable notifications

3. Use IAM (Don’t Stay on Root Account)
After setup:

Create an IAM user
Avoid using your root account daily

This is a best practice used in real organizations.

What This Step Really Means

Setting up your AWS account might feel like a small step but it’s actually a major milestone.

It means:

You’ve entered the cloud ecosystem
You’re ready to build real-world projects
You’re no longer just learning you’re doing

Every cloud engineer starts somewhere and this is where it begins.

If you’ve completed this step.

You now have access to one of the most powerful cloud platforms in the world.

The next step?

Start building. Break things. Fix them. Learn. Repeat.

That’s how you grow. If you’ve just set up your AWS account:

Drop a comment or share your experience
Let me know what you plan to build first

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

AltSchool Of Engineering Tinyuka’24 Month 12 Week 5

Ikoh Sylva — Sun, 22 Feb 2026 11:06:45 +0000

You shouldn’t be missing the previous session’s but if you did, here it is. I would love to use this medium to say a big Congratulations!!! to everyone who has supported this journey thus far Thank you.

A Heartfelt Thank You & A New Beginning

I would love to take a moment to say a huge congratulations to everyone who has supported this journey in one way or another the cheers, the encouragement, the motivation to keep going even when it wasn’t getting easier, and those subtle pushes at the right moments. Every message, comment, and show of support truly mattered. Thank you.

This marks the official end of my time at AltSchool, where I committed myself to the journey of becoming a world-class cloud engineer.

Over the past one year 52 weeks to be precise, I have shared knowledge consistently every single week, breaking down concepts taught in class and documenting the learning process in real time. If you’ve been following closely throughout this journey, then a huge congratulations to you as well you now have a solid foundation and the tools required to succeed as a cloud engineer.

This wasn’t just about completing a program. It was about building discipline, consistency, and clarity in a field that often feels overwhelming. And together, we showed up.

Next Steps: Moving Forward Together

“This is not the end, it’s a transition.”
As a community, I’d love for us to stick around as I move into the next phase: building real-world cloud engineering projects from basic to advanced. I’ll be sharing everything along the way: the wins, the challenges, the lessons learned, and the decisions made.

You can expect:

Hands-on cloud projects
Real-world scenarios and implementations
Practical insights and “nuggets of wisdom”
Lessons learned from each build
Consistent posts (about 2–3 times a month, depending on project complexity)
I’m also thinking of incorporating AI and AI Agents as it relates to cloud

Over time, my goal is for us to build an archive of meaningful, practical cloud projects something truly valuable and worthy of recognition.

The Bigger Picture

The ultimate goal is simple: to help as many people as possible break into tech and cloud engineering in particular without the confusion that comes from information overload.

If you show up consistently, do the work that needs to be done, and follow the guided path being laid out here, you’ll be well-equipped to thrive in whatever cloud role you find yourself in.

Once again, thank you for being part of this journey. Here’s to growth, clarity, and the exciting road ahead.

I encourage you to dive deeper into the concepts we've discussed over time and continue practicing to refine your skills. A Huge Congratulations! to you as this marks the end of our cloud journey with AltSchool Africa. If you also found this interesting and would love to take the next steps in the application process do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

I would love to hear your feedback and insights. Please leave a comment below to join the conversation!

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.
For those who may not be familiar, Sanjeev Kumar brings over 20 years of hands-on experience across multiple domains and every phase of product delivery. He is known for his strong architectural mindset, with a deep focus on Automation, DevOps, Cloud, and Security.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.
Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

I’m Ikoh Sylva, a passionate cloud computing enthusiast with hands-on experience in AWS. I’m documenting my cloud journey from a beginner’s perspective, aiming to inspire others along the way.

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

AltSchool Of Engineering Tinyuka’24 Month 12 Week 4

Ikoh Sylva — Sat, 14 Feb 2026 15:31:22 +0000

If you missed our previous session, you can always catch up here. This week, we went hands on again. This time more intermediate level with Highly Available Web Application on AWS. Let’s get to it, shall we?

Highly Available Web Application on AWS

Project Overview

In this project, you will design and deploy a highly available, scalable web application architecture on AWS using managed services and Infrastructure-as-Code principles.

You will:

Build a custom VPC
Deploy EC2 instances across multiple Availability Zones
Use an Application Load Balancer
Implement Auto Scaling
Apply security best practices
Monitor the system using CloudWatch

This mirrors how production web applications are deployed in the cloud.

Skills You Will Gain

AWS networking (VPC, subnets, routing)
High availability design
Load balancing and auto scaling
Security groups & IAM roles
Basic monitoring and alerting
Infrastructure design thinking

Architecture Overview

Internet
   |
Application Load Balancer
   |
-----------------------------
|                           |
EC2 (AZ-1)              EC2 (AZ-2)
   |                       |
Auto Scaling Group (ASG)
   |
CloudWatch Monitoring

Prerequisites

AWS account
Basic Linux knowledge
Familiarity with EC2 and VPC concepts
SSH key pair
AWS Free Tier (mostly)

Project Components

Custom VPC
2 public subnets (different AZs)
Internet Gateway
Route Table
Security Groups
Launch Template
Auto Scaling Group
Application Load Balancer
CloudWatch alarms

Step 1: Create a Custom VPC

CIDR block: 10.0.0.0/16
Enable DNS resolution

Why?

Network isolation
Full control over routing

Step 2: Create Subnets

Public Subnet 1: 10.0.1.0/24 (AZ-1)
Public Subnet 2: 10.0.2.0/24 (AZ-2)

These allow traffic from the internet.

Step 3: Internet Gateway & Routing

Attach Internet Gateway to VPC
Route 0.0.0.0/0 → Internet Gateway

This enables public access.

Step 4: Security Groups

Load Balancer SG

Allow HTTP (80) from anywhere
EC2 SG
Allow HTTP (80) from Load Balancer SG only
Allow SSH (22) from your IP

This limits exposure.

Step 5: Launch Template

Amazon Linux 2
Instance type: t2.micro
User data installs and starts Nginx:

#!/bin/bash
yum update -y
yum install nginx -y
systemctl start nginx
systemctl enable nginx
echo "<h1>Server running in $(hostname)</h1>" > /usr/share/nginx/html/index.html

Step 6: Auto Scaling Group

Minimum: 2 instances
Desired: 2
Maximum: 4
Attach to public subnets

This ensures high availability.

Step 7: Application Load Balancer

Internet-facing
Listener on port 80
Forward traffic to ASG

Test by opening the ALB DNS name.

Step 8: CloudWatch Monitoring

Monitor EC2 CPU utilization
Create alarm:
Scale out if CPU > 70%
Scale in if CPU < 30%

This adds automatic scaling logic.

Expected Outcome

Web app accessible via Load Balancer
Instances spread across AZs
Auto scaling responds to load
Fault tolerance if one instance fails

Why This Is an Intermediate-Level Project

✔ Uses multiple AWS services
✔ Implements real architecture patterns
✔ Introduces scaling & monitoring
✔ Teaches cloud design principles
✔ Not overly complex

Clean-Up (Important!)

After testing:

Delete Auto Scaling Group
Delete Load Balancer
Terminate EC2 instances
Delete VPC

Avoid unnecessary costs.

Optional Enhancements (If You Want More)

Add HTTPS (ACM)
Add private subnets + NAT Gateway
Use Terraform instead of Console
Store logs in CloudWatch Logs
Add S3 for static assets

I encourage you to dive deeper into the concepts we've discussed over time and continue practicing to refine your skills. If you have read all the way to this point thank you So much! And a Huge Congratulations! to you as this marks the end of our cloud journey with AltSchool Africa. I appreciate the effort. If you also found this interesting and would love to take the next steps in the application process do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

I would love to hear your feedback and insights. Please leave a comment below to join the conversation!

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

DevOps & Cloud Job Placement / Mentorship Program.

I’m Ikoh Sylva, a passionate cloud computing enthusiast with hands-on experience in AWS. I’m documenting my cloud journey from a beginner’s perspective, aiming to inspire others along the way.

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

AltSchool Of Engineering Tinyuka’24 Month 12 Week 3

Ikoh Sylva — Sun, 08 Feb 2026 12:10:18 +0000

If you missed our previous session, you can always catch up here. This week, we are going hands on with Automated Web Server Setup with Security Hardening. Let’s get to it, shall we?

Automated Web Server Setup with Security Hardening

Project Overview

In this project, you will use Ansible to automatically:

Provision and configure multiple web servers
Use roles for clean project structure
Install and configure Nginx
Deploy a dynamic HTML page using Jinja2
Secure the server with UFW
Enable HTTPS (TLS/SSL) using Certbot
Restart services automatically using handlers
Make the setup cloud-ready (AWS EC2 compatible)

This mirrors how DevOps teams actually automate servers in production.

What You Will Learn

By completing this project, you will understand:

Ansible inventory management
Playbooks and tasks
Modules (apt, user, copy, service, ufw)
Idempotency
Basic security automation
Running Ansible against multiple hosts

This introduces;

Ansible Roles
Handlers
Jinja2 Templates
HTTPS with Certbot (Let’s Encrypt)
Cloud-ready structure (AWS EC2 compatible)

Project Architecture

Control Node (Ansible)
        |
        |--- SSH
        |
-------------------------
|       |       |       |
Web1   Web2   (Optional) Web3

Prerequisites

1 Ansible control node (Linux)
2 Linux servers (Ubuntu recommended)
SSH access between control node and servers
Basic Linux knowledge

Project Structure (Industry Standard)

ansible-web-project/
├── inventory
├── playbook.yml
├── group_vars/
│   └── webservers.yml
└── roles/
    └── webserver/
        ├── tasks/
        │   └── main.yml
        ├── handlers/
        │   └── main.yml
        ├── templates/
        │   └── index.html.j2
        └── files/

Step 1: Inventory (Cloud-Ready)

[webservers]
web1 ansible_host=18.210.12.10
web2 ansible_host=3.92.55.23

[all:vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/aws-key.pem

Works locally
Works on AWS EC2
No changes needed later

Step 2: Variables (group_vars)

Create group_vars/webservers.yml:

app_user: appuser
http_port: 80
domain_name: example.com
email: admin@example.com
Variables make the project flexible and reusable.

Step 3: Main Playbook

playbook.yml:

- name: Configure Production Web Servers
  hosts: webservers
  become: yes

  roles:
    - webserver

Clean. Simple. Scalable.

Step 4: Role Tasks

roles/webserver/tasks/main.yml

- name: Update system packages
  apt:
    update_cache: yes

- name: Install required packages
  apt:
    name:
      - nginx
      - ufw
      - certbot
      - python3-certbot-nginx
    state: present

- name: Create application user
  user:
    name: "{{ app_user }}"
    shell: /bin/bash

- name: Allow HTTP and HTTPS
  ufw:
    rule: allow
    port: "{{ item }}"
  loop:
    - "80"
    - "443"

- name: Enable firewall
  ufw:
    state: enabled

- name: Deploy website template
  template:
    src: index.html.j2
    dest: /var/www/html/index.html
  notify: Restart Nginx

- name: Ensure Nginx is running
  service:
    name: nginx
    state: started
    enabled: yes

Step 5: Handlers (Automatic Restarts)

roles/webserver/handlers/main.yml

- name: Restart Nginx
  service:
    name: nginx
    state: restarted

Handlers only run when changes occur → efficient & safe.

Step 6: Jinja2 Template (Dynamic Website)

roles/webserver/templates/index.html.j2

<!DOCTYPE html>
<html>
<head>
  <title>{{ inventory_hostname }}</title>
</head>
<body>
  <h1>🚀 Deployed with Ansible</h1>
  <p>Server: {{ inventory_hostname }}</p>
  <p>Managed by Ansible automation</p>
</body>
</html>

Each server now shows its own hostname (proof of automation).

Step 7: Enable HTTPS (Certbot)

Add to tasks/main.yml (after Nginx setup):

- name: Obtain SSL certificate
  command: >
    certbot --nginx
    -d {{ domain_name }}
    --non-interactive
    --agree-tos
    -m {{ email }}
  notify: Restart Nginx

This:

Secures your site
Enables HTTPS automatically
Matches production setups

⚠️ Requires a real domain pointing to the server IP.

Step 8: Run the Project

ansible-playbook -i inventory playbook.yml

Final Outcome

✔ Web servers configured consistently
✔ Nginx installed and secured
✔ Firewall enabled
✔ HTTPS enabled
✔ Dynamic content deployed
✔ Fully automated
✔ Cloud-ready

You now have a real DevOps-grade automation project.

AWS EC2 Compatibility (Important)

This project works unchanged on AWS EC2 if:

Instances allow ports 80 & 443
Security groups are configured
SSH key is set in inventory

This makes it perfect for:

AWS labs
Portfolio projects
Interview demos

Why This Project Is Portfolio-Worthy

This demonstrates:

Configuration management
Security automation
Infrastructure as Code principles
Production thinking
Clean Ansible design

Many junior DevOps roles expect exactly this level.

Next Possible Upgrades (Optional)

If you want to go even further later:

Integrate Terraform + Ansible
Add monitoring with CloudWatch/Prometheus
Add CI/CD pipeline
Add Ansible Vault
Add Load Balancer (ALB/Nginx)

I encourage you to dive deeper into the concepts we've discussed and continue practicing to refine your skills. If you have read all the way to this point thank you So much! I appreciate the effort. If you also found this interesting and would love to take the next steps in the application process do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

I would love to hear your feedback and insights. Please leave a comment below to join the conversation!

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

DevOps & Cloud Job Placement / Mentorship Program.

I’m Ikoh Sylva, a passionate cloud computing enthusiast with hands-on experience in AWS. I’m documenting my cloud journey from a beginner’s perspective, aiming to inspire others along the way.

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X