Forem: Prince Dumuhere

"VPC (AWS) vs VNet (AZURE): A Comparative Deep Dive for Multi-Cloud Beginners"

Prince Dumuhere — Fri, 02 Jan 2026 17:28:24 +0000

Introduction

I’ve always believed that to truly master the cloud, one must understand the "why" behind the services, not just the "how" of a single provider.

Currently, I am privileged to be interning with an AWS Partner company, where I’m diving deep into AWS projects and solving real-world challenges weekly. It’s been an incredible journey earning my AWS CCP and SAA, but I’ve decided that 2026 is the year I become a multi-cloud professional.

I’ve officially begun my journey toward the Microsoft AZ-104 (Azure Administrator) certification! 🎓

Why add Azure to my AWS background?

Cloud Agnostic Mindset: Understanding how different providers handle Identity (Entra ID vs. IAM) or Networking (VNets vs. VPCs) sharpens my architectural decision-making.
Best-of-Breed Solutions: Every cloud has its "superpower". By learning Azure, I can better advise on hybrid environments and Microsoft ecosystem integrations.
Continuous Growth: The cloud doesn't stand still, and neither should we.

I’m currently following a modular path through Udemy and Microsoft Learn, mapping my AWS knowledge to Azure services as I go.

To my fellow cloud engineers: What was the biggest "lightbulb moment" you had when learning your second cloud provider? 💡

Follow me on my socials:
LinkedIn:
YouTube:

CloudComputing #AWS #Azure #AZ104 #MultiCloud #ContinuousLearning #TechInternship #AWSCommunity

Building a Highly Available Architecture on AWS

Prince Dumuhere — Fri, 24 Oct 2025 07:19:53 +0000

High availability is a critical aspect of modern cloud infrastructure, ensuring that applications remain accessible even in the event of system or network failures. In this lab, I set up a highly available architecture using AWS services across two Availability Zones (AZs). Below, I’ll walk through the steps I took to achieve this, supported by screenshots from my build.

Creating a New VPC with Multiple Subnets

I started by creating a new VPC named KingsonHA-Lab-SG. To ensure high availability, I configured:

2 Availability Zones (AZs)

4 Subnets in total (2 public and 2 private, one pair per AZ)

1 NAT Gateway for outbound internet access from the private subnets

This setup ensures that workloads can fail over between AZs if one becomes unavailable.

Enabling Auto-Assign Public IPv4 Addresses

For both public subnets, I enabled the Auto-assign Public IPv4 Address option. This guarantees that any instance launched in these subnets will automatically receive a public IP, making them accessible over the internet when needed.

Configuring Security Groups

Next, I created a Security Group dedicated to my architecture. I edited the inbound rules as follows:

HTTP (Port 80): Allowed traffic from all IPs (0.0.0.0/0) to make my web server accessible publicly.

SSH (Port 22): Restricted access to my own IP address for secure remote management.

This ensures controlled but secure access to the environment.

Creating a Launch Template with User Data

I created a Launch Template that defines the configuration for EC2 instances. Within the template:

I attached the Security Group I created earlier.

I added User Data to automatically install and configure the application (such as a simple web server) when instances launch.

This automation ensures consistency across all instances deployed by the Auto Scaling Group (ASG).

Setting Up an Auto Scaling Group (ASG) with an Application Load Balancer (ALB)

Using the Launch Template, I created an Auto Scaling Group (ASG):

I selected both public subnets across the two Availability Zones.

During ASG creation, I also configured an Application Load Balancer (ALB) to distribute incoming traffic evenly across the EC2 instances.

The ASG ensures scalability, while the ALB improves availability by routing traffic intelligently.

Testing the Load Balancer

To validate my setup, I tested the ALB by accessing its DNS name in my browser. With each refresh, I observed the public IP address change—confirming that the ALB was successfully balancing requests across multiple instances in different AZs.

Achieving High Availability

By hosting the same application on two instances spread across two Availability Zones, I ensured redundancy. If one instance or AZ fails, traffic automatically fails over to the healthy instance in the other AZ.

This demonstrates how a well-architected AWS environment can achieve high availability and fault tolerance with minimal downtime.

Final Thoughts

This hands-on lab reinforced my understanding of how to design and implement a highly available architecture on AWS. Leveraging VPCs, subnets, security groups, launch templates, ASGs, and ALBs provides the foundation for resilient, scalable cloud solutions.

With this setup, I successfully built an environment capable of handling failures gracefully, ensuring uninterrupted application availability.

A Beginner’s Guide to RDS Backup and Restore on AWS

Prince Dumuhere — Fri, 29 Aug 2025 09:39:51 +0000

Overview:

In this article, I’ll walk through how to create an Amazon RDS instance, insert sample data, take a backup, and perform a restore. This is a beginner-friendly guide with screenshots, perfect for anyone learning AWS RDS high availability and disaster recovery basics.

Introduction:

Databases are the heart of most applications, and ensuring data safety is critical. Amazon RDS (Relational Database Service) takes away the heavy lifting of database management, including backups and restores. In this guide, I’ll demonstrate how to back up a database instance and restore it to recover lost data.

Core Concepts:

Amazon RDS → This is a managed service for relational databases.

Backup Types in RDS:

  Automated Backups (point-in-time recovery)

  Manual Snapshots (user-initiated, stored until deleted)

Restore Behavior: restores always create a new DB instance, not overwrite the existing one.

Phase A – Create an RDS Instance

Go to AWS Console → RDS → Create database.

Choose:

Engine: PostgreSQL (or MySQL if you prefer).

Deployment option: Single-AZ (we’ll switch to Multi-AZ later).

DB instance class: db.t3.micro (cheap/free tier).

Storage: 20 GiB, gp3.

Credentials: set username/password.

Networking: default VPC, allow public access (for lab only), create a security group allowing inbound 5432 (Postgres) or 3306 (MySQL) from your IP.

Backups: enable automated backups (7 days).

Monitoring: leave defaults.

Click Create database.

Verify endpoint:
aws rds describe-db-instances \ --db-instance-identifier lab-rds \ --query 'DBInstances[0].Endpoint.Address'

Phase B – Connect and Install Sample Data

Connect from CloudShell or your PC:

psql "host=<your-endpoint> dbname=postgres user=labuser password=StrongPassw0rd!"

Insert Sample Data - Create table + data: + Confirm data entered

INSERT INTO users (name, email) VALUES ('prince', prince@example.com), ('Kingson', kingson@example.com),

SELECT * FROM users;

Phase 3: Backup & Restore

Manual Snapshot

**Console: RDS → Databases → Select your DB → Actions → Take snapshot → name it.

CLI:**

aws rds create-db-snapshot \ --db-snapshot-identifier lab-snap1 \ --db-instance-identifier lab-rds

Simulate Data Loss: and confirm if data was deleted
`DELETE FROM orders WHERE id=1;`

SELECT * FROM users;

Phase 4: Restore from Snapshot

Console: RDS → Snapshots → Select → Restore snapshot → new instance.

CLI:
aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier lab-restore1 \ --db-snapshot-identifier lab-snap1

Verify Restored DB: Get endpoint of new DB.

Connect and run:

SELECT * FROM orders;

The deleted row should be back

Observations & Learnings

Multi-AZ is for high availability, not backups.
A restored DB has a different endpoint.
Applications need to be re-pointed to the new DB if you restore.
Point-in-time restores do not overwrite; they create a new DB.

Conclusion:

This lab demonstrated the importance of backups in RDS and how easy AWS makes it to restore a database instance. Backups are crucial for disaster recovery, and practicing these steps ensures that you’ll know how to protect and recover your data when it matters most.

If you’re practicing AWS RDS, I recommend extending this lab by testing a point-in-time recovery. This will give you more confidence in handling real-world scenarios.

AWS #CloudComputing #RDS #Database #DevOps #CloudEngineering

Cross-account deployment using AWS ECR!

Prince Dumuhere — Tue, 29 Jul 2025 03:59:03 +0000

✅ PROJECT COMPLETE

I just finished a cross-account deployment project using AWS ECR & Elastic Beanstalk!

The task? Deploy my partner’s ( Michael Ibeh ) containerized app from their AWS account to mine securely.

I built a Docker image, pushed it to ECR, and used IAM roles to allow cross-account access for deployment on Elastic Beanstalk.

✅ Challenge accepted. ✅ App deployed. ✅ Secret code unlocked: YAML

I ran into real-life challenges like port conflicts and IAM permission issues, but this made the learning even better.

🛠️ Tools: Amazon Web Services (AWS), Docker, Inc, CLI, ECR, IAM, Elastic Beanstalk
Screenshot below 👇

Implementing Auto Scaling in AWS to Handle Web Traffic Spikes

Prince Dumuhere — Mon, 14 Jul 2025 03:34:10 +0000

Introduction

In today’s digital landscape, website downtime can lead to revenue loss and poor customer experience. A company hosting its website on an AWS EC2 instance faced challenges when traffic spikes during promotions overloaded the server, causing downtime. The solution? "Auto Scaling" which automatically adjusts resources based on demand.

This guide walks you through setting up an AWS Auto Scaling solution that dynamically scales up during high traffic and scales down during low traffic, ensuring efficiency and cost optimization.

Project Goal

To configure an auto-scaling architecture that ensures the website remains available during traffic spikes whminimising costs when traffic is low.

Step 1: Set Up the AWS VPC and Subnets

Create a VPC ( with IPv4 CIDR 10.0.0.0/16).

Inside the VPC, create 3 public subnets (for the Load Balancer) and 3 private subnets (for EC2 instances).
Create three private subnets (for EC2 instances).

Create three public subnets (for the Load Balancer).

Ensure subnets are spread across multiple Availability Zones for high availability.

Step 2: Launch an EC2 Instance with a User Data Script

a. Choose Amazon Linux AMI.

b. Launch an EC2 instance in a private subnet.

EC2 Instance won't be accessible yet via EC2 Connect

Create an internet gateway

Attach IGW to your VPC

Attach your VPC in use

Edit route tables

Create public & private route tables

Associate all 3 public subnets to the public route table and all 3 private subnets to the private route table.

Edit the route in the public route table to send traffic to the IGW created

Connect to EC2 instance again via EC2 connect and it should connect now

Use a User Data script to configure the web server:

!/bin/bash

sudo yum update -y

sudo yum install -y httpd

sudo systemctl start httpd

sudo systemctl enable httpd

echo "

Welcome to Auto-Scaling Web Server

" | sudo tee /var/www/html/index.html

Assign a Security Group that allows HTTP traffic only from the Load Balancer.

Step 3: Configure the Auto Scaling Group

Create a Launch Template specifying the AMI, instance type, security group, and User Data script.

**2. Create an Auto Scaling Group: **

Attach it to private subnets.

Set minimum = 1, desired capacity = 2, and maximum = 5 instances.

Step 4: Set Up an Application Load Balancer (ALB)

Create an Application Load Balancer in the public subnets.
Create a Target Group for the EC2 instances.
Attach the Auto Scaling Group to the Target Group.

⚠️ Note: Due to the teardown of infrastructure after project completion, real-time screenshots for this step are unavailable. However, the configuration steps below accurately reflect what was implemented.

Configuration Summary:

Created an Application Load Balancer (ALB) in three public subnets (across different Availability Zones).
Configured the Listener to forward HTTP (port 80) traffic to the Target Group.
Created a Target Group (type: instance) and registered EC2 instances launched via the Auto Scaling Group.
Attached the Auto Scaling Group to the Target Group to distribute traffic evenly among healthy instances.

Step 5: Implement Auto Scaling Policies

Target Tracking Scaling

Set a policy to maintain average CPU utilization at 30%.

AWS automatically adjusts the number of instances as needed.

⚠️ Note: Auto Scaling configurations were tested and deleted afterward. The following summary describes the actual implementation.

✅** Option Used: Target Tracking Policy**

Configured an Auto Scaling Policy to maintain average CPU utilization at 30%.
AWS automatically scaled the number of EC2 instances up or down based on real-time load.
Cooldown periods and instance warm-up were set to defaults.

Step 6: Security Best Practices

Keep EC2 instances in private subnets.

Use a bastion host or VPN for secure access.

Assign IAM roles with the least privilege access.

Step 7: Cost Optimization
1. Elimination of Over-Provisioning

Before Auto Scaling: You may need to run more instances than necessary just to prepare for spikes.
With Auto Scaling: Only the exact number of resources needed at any moment are provisioned.

✅ Cost Benefit: You avoid paying for idle or underutilized instances during off-peak periods.

2. Reduced Human Intervention

Auto Scaling automates instance provisioning and termination.

✅*** Cost Benefit***: Saves time and money on manual monitoring and scaling tasks.

3. Minimized Downtime Costs

By handling traffic spikes automatically, Auto Scaling helps maintain performance during surges.

✅*** Cost Benefit:*** Reduces the risk of lost revenue from slow page loads or outages.

4.*** Optimized Resource Utilization***

When demand drops, unnecessary instances are terminated.

✅*** Cost Benefit***: Avoids unnecessary billing by releasing unneeded resources.

5. Scalability without Financial Risk

You can scale for unpredictable growth or seasonal traffic without a large upfront investment.

✅*** Cost Benefit:*** Supports business growth while keeping infrastructure costs flexible.

Using CloudWatch ensures there are no cost surprises

Challenges and Fixes

Configuring the web server data script with ("
Welcome to Auto-Scaling Web Server
" > /var/www/html/index.html) didn't work, so i had to use (echo "
Welcome to Auto-Scaling Web Server
" | sudo tee /var/www/html/index.html)

⚠️ Note: The later command gave me an elivated privilege because i was running the command from an IAM user that might not have enough privileges

While on the project, i encountered challenges setting up the "Application Load Balancer" as a result, i couldn't take screenshots when it finally worked, so i did a summary in the place of the screenshots giving the fact that i had already clleaned up the VPC i used and terminated/deleted the resources.

Conclusion
Implementing Auto Scaling on AWS ensures your website remains available during high traffic while keeping costs minimal. This approach provides flexibility, security (by putting the web server in a private subnet rather than a public subnet), and cost savings, making it a smart choice for businesses handling fluctuating traffic.

By leveraging AWS Auto Scaling, your website is always responsive, even during unexpected traffic surges. Ready to scale your web applications efficiently? Try this setup today!

Have thoughts on this implementation? Share them in the comments! Follow for more AWS cloud tips