DEV Community: Glory Ugochukwu

Building a Serverless, Event Countdown Website with AWS — A Deep Dive into neocloudapp.site (A Real-World Cloud Project)

Glory Ugochukwu — Tue, 06 May 2025 23:49:44 +0000

How I deployed a fully serverless, secure, and globally available event site using AWS, Terraform, and best cloud practices.

Intro: Why I Built This Project
As part of my Cloud Solutions Architect training, I wanted to build a real-world project that:

Showcases my understanding of AWS architecture
Solves a practical problem (promoting a product/event)
Demonstrates serverless, secure, and scalable solutions
Uses Infrastructure as Code (IaC) with Terraform.

The result? A production-ready landing page hosted at https://neocloudapp.site — for the launch of the NeoApp Study Portal.

Let’s break it all down.

What Is the Project About?
The NeoCloud Event Countdown Website is a serverless landing page built to:

Display a live countdown to the launch of a cloud learning portal (NeoApp).
Collect registration data from interested users.
Demonstrate AWS service integration in a clean, production-ready format.
Showcase best practices in infrastructure-as-code (IaC), security, and scalability.

More than just a form and countdown timer, this project mirrors real startup infrastructure needs—without overengineering, without high cost, and without a single server.

The Vision Behind the Project
"Tech is evolving — and NeoCloud is preparing you to lead the future."

I imagined a scenario where NeoCloud was launching a tech education product — NeoApp. We needed a simple yet professional landing page to:

Announce the upcoming launch
Collect waitlist emails
Be accessible, secure, and modern

Architecture

[User] ---> [Route 53 + CloudFront] ---> [S3 Static Website Hosting]
|
[ACM SSL for HTTPS]
|
[API Gateway] ---> [Lambda (Python)] ---> [DynamoDB]
|
[SNS Notification]

Cloud Services Used and Why

1. Amazon S3 + CloudFront
Why S3?
Amazon S3 is cost-effective, reliable, and provides static
web hosting capabilities out of the box. It's ideal for
HTML/CSS/JS sites and integrates with CloudFront.

Public access control: Carefully configured bucket policies
ensured the website is publicly accessible without exposing
the whole AWS account.

CloudFront adds:

Global CDN performance
HTTPS with ACM SSL certificates

Why CloudFront?
As a global CDN, CloudFront caches content close to users,
reducing latency and improving performance. It also adds an
extra layer of security.

2. Amazon Route 53 + ACM
Custom domain setup with DNS routing and SSL.

Why Route 53?
AWS Route 53 offers scalable and highly available DNS
services. It integrates seamlessly with other AWS resources,
especially S3, CloudFront, and ACM.

ACM provides free SSL certificates for secure, encrypted access (https://neocloudapp.site).

Why ACM? AWS Certificate Manager lets us provision and
attach an SSL certificate (HTTPS) for free, crucial for
securing user data and gaining trust.

3. API Gateway

Why: It acts as a front door to Lambda, providing HTTP endpoints for the form to interact with. It handles authorization, rate limiting, and CORS configuration.

Benefits:

Built-in throttling and caching
Seamless integration with Lambda

4. AWS Lambda (Python)

Why: AWS Lambda runs backend code without managing servers. For the waitlist registration, a Python Lambda function processes the form and triggers database storage and email notifications…i.e

Handles backend logic:
Parses form submissions
Saves to DynamoDB
Triggers SNS notifications

Serverless means:

No infrastructure management
Only pays when the function runs

5. Amazon DynamoDB

Why DynamoDB?
DynamoDB is AWS’s NoSQL database, perfect for quick, low-latency access. It’s serverless, auto-scales, and requires zero maintenance.
Benefits:
Scales automatically
Integrated seamlessly with Lambda
Alternatives: RDS (for relational data) or S3 (for flat file storage—but less queryable).

6. SNS (Simple Notification Service)

Why: Sends real-time alerts when someone submits the form (e.g., email notifications).
Benefits:
Decouples backend logic
Supports multiple subscribers (email, SMS, Lambda triggers)
Alternatives: SES (Simple Email Service) for customized email content, or Slack/API integrations for internal alerts.

7. Terraform

Why: Infrastructure as Code (IaC) ensures consistency, repeatability, and automation.
Alternatives: AWS CloudFormation (native), Pulumi (for coding IaC in languages like TypeScript/Python).

Why Serverless?
I chose serverless architecture for several reasons:

Scalability: Serverless apps scale automatically with demand.
Reduced cost: You only pay for what you use—no idle servers.
Less maintenance: No server or OS management.
Speed of deployment: Easier to launch and iterate.

Scalability, Availability, and Security

Scalability:
Every layer is serverless, meaning auto-scaling is native. it scales seamlessly without manual intervention.

High Availability:
Hosted in multiple AWS regions with S3, CRR, and CloudFront’s distributed nature. Even if one region fails, users can still access content.

Security:

IAM roles define strict access for each component.
HTTPS via CloudFront & ACM secures transmission.
Lambda has least-privilege permissions.
No exposed servers means a smaller attack surface.

Step-by-Step: How I Built neocloudapp.site (A Serverless Landing Page)
This project involved designing, developing, and deploying a serverless event landing page on AWS, fully automated with Terraform and secured using HTTPS. Here’s how I built it from scratch

Step 1: Purchased and Registered a Domain

Action: Bought the domain neocloud.site from a domain registrar Why: To use a custom, professional URL for branding and recognition.

Step 2: Set Up Hosted Zone in Route 53

Action:
- Created a Hosted Zone for neocloud.site in Route 53.
- Updated my registrar’s name servers to use Route 53 DNS.

Why: Route 53 acts as my DNS manager, letting me control how traffic is routed to AWS services.

Step 3: Requested an SSL Certificate via AWS Certificate Manager (ACM)

Action:
- Requested a free public SSL certificate for neocloud.site in us-east-1 (required by CloudFront).
- Used DNS validation to verify domain ownership automatically through Route 53.
- This certificate was later attached to the CloudFront distribution
Why: To enable HTTPS and protect all user interactions with encryption.

Step 4: Wrote the Frontend Code

Action:
- Created an HTML/CSS landing page with:
- A hero section
- Benefits/features section
- Waitlist registration form
- Footer with attribution
- Ensured full mobile responsiveness and visual appeal.
Why: This is the core user interface and the first thing users see. It needs to be fast, lightweight, and modern.

Step 5: Deployed the Frontend with S3 (Static Hosting)

Action:
- Created an S3 bucket named neocloud.site.
- Enabled static website hosting.
- Uploaded the frontend files using Terraform.
- Set a bucket policy to allow public read access to website content.
Why: S3 is perfect for hosting static sites — no server management, just upload and go.

Step 6: Configured CloudFront as CDN + SSL Layer

Action:
- Created a CloudFront distribution:
- Origin: S3 bucket
- Alternate domain name (CNAME): neocloud.site
- Attached the SSL certificate from ACM
- Set default root object to index.html
- Forced HTTPS redirect for all requests
- Used Terraform to automate all of this.
Why: CloudFront acts as a global CDN, improves performance, and adds an HTTPS layer for security

Step 7: Connected Domain to CloudFront with Route 53 (A Record)

Action:
- I created an Alias A Record in Route 53 that points the neocloud site to the CloudFront distribution.
- At this point, I could visit https://neocloudapp.site and see my landing page live!
Why: This links the domain name to the website content hosted through CloudFront.

Step 8: Created Backend Infrastructure for Form Submission.

8a. API Gateway

Action:
- Set up a REST API with a POST /register endpoint.
- Integrated it with Lambda
- Enabled CORS to allow browser-based requests from the frontend.
Why: API Gateway is a fully managed service for building serverless APIs.

8b. Lambda Function

Action:
- Wrote a Python-based Lambda function that:
- Receives name and email from the frontend
- Saves them into a DynamoDB table
- Sends a notification to an SNS topic
Why: Lambda lets me run backend logic without provisioning servers.

8c. DynamoDB Table

Action:
- Created a table NeoAppWaitlist with:
- Primary Key: email
- Other fields: name, timestamp
Why: NoSQL database with fast performance, perfect for storing simple form submissions.

8d. SNS Topic

Action:
- Created an SNS topic and added my admin email as a subscriber.
- Lambda publishes a message when a new registration is submitted.
Why: To receive real-time notifications of new registrations.

Step 9: Integrated Frontend with Backend

Action:
- Used JavaScript fetch() in the frontend to send form data to the API Gateway endpoint.
- Handled success and error messages dynamically in the UI.
Why: Makes the form interactive and provides feedback to users.

Step 10: Wrote and Applied Terraform Scripts for Full Infrastructure

Wrote Terraform configurations to:

Create the S3 bucket, CloudFront distribution, and Route 53 records
Provision the API Gateway, Lambda function, and IAM roles
Set up DynamoDB, SNS, and ACM

Ran:

`terraform init
terraform plan
terraform apply`

Why: Terraform ensures consistency, repeatability, and version control across environments.

Step 11: Final Testing and Debugging

Action:

Visited https://neocloudapp.site to ensure:

HTTPS works
DNS resolves correctly
Page loads globally via CloudFront
Form submits correctly
Data is saved in DynamoDB
Email notification is triggered

Why: Testing is crucial to validate that everything works seamlessly before sharing publicly.

Conclusion:
This project gave me hands-on experience in building a production-grade, secure, and globally accessible event site — all without a single EC2 instance.

If you're learning AWS or preparing for real-world cloud architect roles, I highly recommend building something like this.

Thanks for reading!

Wrote this article to document my process, to help others, showcase my skills, and solidify what I’ve learned

Seeing Cloud Differently: My Experience with the AWS Well-Architected Framework

Glory Ugochukwu — Thu, 24 Apr 2025 12:40:26 +0000

Introduction
A few days ago, I took a class on the AWS Well-Architected Framework, and let me just say—it was one of the most insightful sessions I’ve had in my cloud journey so far. And it wasn’t just a theory-heavy lecture. We role-played real-world scenarios, walked through the pillars, and answered tough architecture questions in real time.

As someone learning to become a Cloud Solutions Architect, I often get stuck asking:

“Am I building this the right way?”
“What am I missing?”
“How do I know this solution will scale, stay secure, or not break the bank?”

Turns out, AWS asked those exact questions—and built an entire framework to help answer them. Let’s talk about what it is, why it matters, and why I’ve grown to love it.

What is the AWS Well-Architected Framework?

The Well-Architected Framework (WAF) is a set of guiding principles and best practices that help architects build secure, high-performing, resilient, and efficient infrastructure in the cloud.
It’s structured around six pillars that each represent a core area of cloud architecture:

Operational Excellence – Run and monitor systems to deliver business value and continuously improve processes.
Security– Protect information and systems.
Reliability – Recover quickly from failure and meet customer demands.
Performance Efficiency – Use computing resources efficiently.
Cost Optimization – Avoid unnecessary costs.
Sustainability (the newest addition)– Minimize environmental impact (newest pillar).

You evaluate your workloads against these pillars through Well-Architected Reviews—structured assessments that point out weaknesses and suggest improvements.

Why It Matters in the Real World

Here’s what really stood out to me: this isn’t just a checklist—it’s a mindset.
Instead of designing reactively or building systems that only work for "today," the Well-Architected Framework forces you to think long-term.

It encourages questions like:

How will this app behave under load?
What happens if a server fails?
Are we logging enough to troubleshoot later?
Are we paying for unused capacity? You start to think like an architect, not just a builder.

Let me explain this with a real-world vibe:
Imagine your team just launched a big application on AWS. Everything works. Cool.
But a month later:

You get hit with a $5,000 AWS bill
A security group was accidentally left open to the world
An EC2 instance crashes, and the app goes offline for hours.

That’s when you realize: “We built it. But we didn’t build it well.”

The Well-Architected Framework is AWS’s way of saying:
“We’ve seen thousands of architectures. Here’s how to avoid common pitfalls.”

Real-Life Use Cases We Explored
During our class role-play, we applied the WAF to various systems, including:

A university admission portal — What if students flood the system after results are released?
A healthcare platform — How do you secure patient data while maintaining uptime?
A government job portal — How can we build for unpredictable traffic surges without overspending?

Each of these systems benefited from different pillars of the framework:

Meet the 6 Pillars (Quick Look)
Let’s quickly break down what each pillar is really about—and how I relate to it as a learner:
1. Operational Excellence
Focuses on running and monitoring systems, and continually improving.
Real-world: Set up CloudWatch to monitor app health. Automate failover and patching.

2. Security
Protect data, systems, and assets. Think least privilege and encryption everywhere.
Real-world: Limit IAM permissions, encrypt S3 buckets, enable GuardDuty.

3. Reliability
Make sure systems can recover from failure and scale to meet demand.
Real-world: Use Auto Scaling Groups, multi-AZ deployments, RDS backups.

4. Performance Efficiency
Use the right resources for the job and adapt to change.
Real-world: Move from t2.micro to Graviton2 instances or Lambda where possible.

5. Cost Optimization
Avoid unnecessary spending and understand where your money goes.
Real-world: Use Trusted Advisor, delete unused volumes, set up budgets, and alerts.

6. Sustainability
Reduce environmental impact by using efficient resources and scaling wisely.
Real-world: Choose managed services and autoscaling to reduce energy waste.

Why I Love This Framework as a Solution-Driven Person
What made me truly connect with the WAF is how solution-oriented it is.
It doesn't just say, “Here's how you build something.”
It asks, “What problem are you solving, and how can we solve it better?”
That resonates with me. I’m someone who enjoys identifying pain points and designing clean, scalable, practical solutions. This framework gave me a structured lens to evaluate not just cloud architecture, but any tech solution.

In real consulting roles, AWS Solutions Architects run Well-Architected Reviews for clients. They:

Ask questions about the framework
Identify “high-risk” areas
Recommend changes (sometimes tied to AWS credits for remediation!) So even as a learner, understanding these pillars helps me think architecturally and ask better questions before I build.

What I Took From the Class

It’s not about perfection—just continuous improvement.
There are tools (like the Well-Architected Tool in AWS) that walk you through reviews.
Real-life architecture isn’t about knowing all the services— It’s about asking the right questions.

Best Ways to Use the AWS Well-Architected Framework

Design Reviews: Use it as a checklist before launching a new system.
Improvement Plans: Apply it to existing architectures to identify gaps.
Decision-Making Tool: Compare trade-offs when designing for performance vs. cost vs. security.
Team Alignment: Use the pillars to ensure everyone’s on the same page—DevOps, security, product, and business.

Conclusion
In 2025 and beyond, building “working” systems isn’t enough. We need scalable, secure, resilient, and cost-effective solutions. The AWS Well-Architected Framework isn’t just for AWS-specific projects—it’s a philosophy that applies to every cloud decision we make.

If you’re learning to design cloud solutions like I am, the Well-Architected Framework is like having AWS whisper best practices in your ear. It doesn’t just make you a better builder—it helps you think like an architect.

Because cloud isn’t just about spinning up servers.
It’s about solving problems—the right way.

What’s Next?
In Part 2, we’ll dig into the Operational Excellence pillar:

What it looks like in real cloud environments
Key services (CloudWatch, Config, Systems Manager)
Hands-on tips to improve observability and automation

Networking in the Cloud: Building the Highways for Modern Applications.

Glory Ugochukwu — Thu, 24 Apr 2025 11:38:08 +0000

Documenting My Cloud Journey – Understanding the Backbone of Cloud Infrastructure

Introduction
When I started learning about cloud computing, networking felt like the part I was most tempted to skip. “Just give me Lambda, S3, and etc,” I thought. It was like a complex world of IPs, subnets, and protocols. But as I’ve progressed in my journey as a Cloud Solutions Architect trainee, I’ve come to see cloud networking for what it really is: the invisible highway that connects users to applications, services to each other, and data across the globe.

Everything in the cloud is talking to something else—and networking is the language.

Without understanding how services talk to each other, how they’re secured, and how traffic flows in and out of your environment, you're flying blind. So here’s a guide—an honest, example-driven introduction to networking in the cloud and why it’s essential for resilient, secure, and scalable solutions.

What is Cloud Networking?
Cloud networking is how resources (like EC2, S3, RDS, Lambda, etc.) connect and communicate with each other inside the cloud, and how they connect to the outside world (users, on-prem infrastructure, apps, other systems). securely and efficiently.

In traditional IT, this meant routers, switches, and cables. In the cloud? It’s all virtual—built using software-defined networking (SDN). You control your networking through dashboards, APIs, or Infrastructure as Code (like Terraform).

It includes:

IP addressing
Subnets
Gateways
Routing
Firewalls (security groups/NACLs)
DNS
Load balancing
Connectivity options (VPN, Direct Connect, VPC Peering, et c.)

Just like in the physical world, networks in the cloud are designed to manage traffic flow, security, speed, and availability.

Core Concepts
Here are the key AWS networking components I’ve learned to work with:

Virtual Private Cloud (VPC) Your own private network space in the cloud. You control IP ranges, subnets, route tables, and more. Think of a VPC as your private space in the AWS cloud—a walled garden where you launch your resources.

You define:

IP range (e.g., 10.0.0.0/16)
Public and private subnets
Internet access rules
Security policies

Use Case: You launch a web server (EC2) in a public subnet so users can access it, and a database in a private subnet so only your app can talk to it. This keeps your DB secure and unreachable from the internet.

2. Subnets (Public vs Private)
Think of these as dividing your VPC into smaller neighborhoods. You usually have:

Public Subnet: Resources like web servers that need internet access. Connected to the internet via an Internet Gateway.
Private Subnet: Databases or backend services that should stay isolated. No direct internet access—great for sensitive data or internal services.

Public subnets are like storefronts on a busy street. Private subnets are like offices behind locked doors.

3. Route Tables
These are like traffic maps. They tell network packets where to go next. For example, “send internet-bound traffic to the IGW

A public subnet's route table might say: 0.0.0.0/0 → Internet Gateway (send all internet traffic outside)
A private subnet might route through a NAT Gateway instead.

Use Case: You need your app server in a private subnet to download updates from the internet, but you don’t want it exposed. Route it through a NAT Gateway.

4. Security Groups & NACLs
These act like firewalls. They control who can talk to whom.
Your cloud firewalls. Security Groups act like virtual firewalls for EC2, controlling inbound/outbound traffic. NACLs control traffic at the subnet level

Security Groups: Attached to instances. Stateful (they remember connections).
NACLs (Network ACLs): Attached to subnets. Stateless (rules must be explicitly set for both inbound and outbound traffic). Example: You allow inbound HTTP (port 80) only from the internet to your web server, and only allow traffic to your database from the app server’s IP.

5. Internet Gateway & NAT Gateway

Internet Gateway: Attaches to your VPC to allow public
traffic (like users accessing your web app) and enables resources in public subnets to talk directly to the internet.

NAT Gateway: Let private subnets initiate connections to the
internet without being exposed. Is that private instances access
the internet for updates (like apt install), but prevent them
from being accessed from the outside.

Use Case: Your Lambda functions or EC2 servers in private
Subnets need to fetch data from an external API securely—NAT
Gateway makes it happen.

6. VPC Peering & Transit Gateway
What if you have multiple VPCs and they need to talk to each other?

VPC Peering: One-to-one connection between two VPCs.
Transit Gateway: A scalable hub-and-spoke model to connect many VPCs. Real-World Example: Your company has a dev environment in one VPC and prod in another. VPC peering lets them share logs or data securely.

7. DNS with Route 53
Route 53 is AWS’s Domain Name System (DNS). It translates friendly names like api.myapp.com into IP addresses.
It also supports:

Health checks
Load balancing
Geo-routing

Use Case: You want your customers in Europe to be routed to your European servers and US users to US servers—Route 53 handles that.

Why Networking in the Cloud Matters
Imagine building a brilliant web app that:

Times out every few minutes
Gets hacked due to an open port
Can’t scale because backend services are stuck in one AZ
Costs a fortune because traffic is routed inefficiently

These are not app problems — they’re networking problems.

Real-World Scenarios That Help It All Click

Streaming App Architecture
Imagine you're building a streaming platform like Netflix. You need:

Public subnets: to host your APIs, load balancers
Private subnets: to run your transcoding services and databases
NAT Gateway: to let private services fetch updates from the internet
Route 53: to map video.myflix.com to your backend services. Your networking design directly impacts performance, security, and costs.

Multi-Department VPC Setup
Your company has different departments: HR, Finance, and Engineering, each with its own VPC.

Finance can’t access HR’s data.
HR can share limited access with Engineering for reports.
Use Transit Gateway to manage all connections from a single place. Now you’ve created network isolation with optional interconnectivity. That's cloud networking done right.

Hosting a Scalable Web App

EC2 in a public subnet
Database in a private subnet
Load Balancer to distribute traffic
Security groups to restrict access to only port 80/443

Hybrid Cloud: Connecting AWS to On-Prem
Use VPN or AWS Direct Connect to link your on-prem servers to your VPC securely

Cross-Region Replication
S3 buckets in different regions communicating via VPC Peering, CRR, and Route 53

Isolated Environments for Dev/Test/Prod
Separate VPCs with peering or a Transit Gateway for controlled communication

Networking & Security Go Hand-in-Hand
Many security issues start as networking misconfigurations:

Open ports
Overly permissive CIDR ranges
Unrestricted SSH access

Best Practices I’ve Learned:

Principle of least privilege (0.0.0.0/0 only where necessary)
Use CloudFront to reduce direct exposure of S3/static content
Don’t just “accept defaults” when setting up a VPC. Understand why something is public or private.
Security Groups can stack plan rules carefully to avoid unintended access.
Use AWS VPC Flow Logs to monitor traffic for debugging.
Practice! Build a VPC with public and private subnets, deploy EC2s, and try connecting them—it clicks faster when you do it yourself.

Automation + Networking
I’ve also started using Terraform to automate network setups:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  map_public_ip_on_launch = true
}

Automating networking makes environments reproducible, auditable, and easy to tear down when needed.

Cloud Networking is Evolving
With modern tools like:

AWS Transit Gateway
PrivateLink
Global Accelerator
App Mesh

Doing it hands-on—setting up VPCs, subnets, and gateways—helped me truly understand what cloud networking is about. It’s not just IPs and rules; it’s the architecture of user experience.

Conclusion
Networking is the unsung hero of cloud architecture.
It’s not glamorous like AI, but nothing works without it.

Learning it changed how I design systems:
I now see flows, boundaries, and security layers instead of just “servers.”

If you're on a similar journey—don’t skip the basics. Get hands-on. Ask why. Test everything.
This is the foundation of everything you’ll build.

Understanding Listener Rules in AWS: A Beginner-Friendly Guide with Jumia & Temu Examples

Glory Ugochukwu — Mon, 21 Apr 2025 08:21:40 +0000

When you visit an e-commerce website like Jumia or Temu, have you ever wondered how your request is processed and directed to the right page? Behind the scenes, services like AWS Load Balancers **use Listener Rules** to determine how to handle user traffic based on conditions such as URL paths, query strings, and host headers.

In this article, we'll break down listener rules in AWS, explain how query strings work, and use Jumia and Temu as real-world examples to make the concept easier to understand.

1. What is a Load Balancer?
In the last Article, I explained that a **Load Balancer **is a service that distributes incoming traffic across multiple servers to ensure:

High availability (prevents server overload)
Scalability (handles increasing traffic)
Fault tolerance (reroutes requests if a server fails)

However, to efficiently route traffic, a **Load Balancer uses Listener Rules **to determine how requests should be processed.

2. What Are Listener Rules?
A** listener** is a component of a load balancer that checks for connection requests using rules. These rules define conditions that determine how traffic should be forwarded.

Types of Listener Rule Conditions in AWS:
Condition Type Example from Jumia/Temu Use Case
Path-Based Routing: jumia.com.ng/cards or temu.com/fashion Routes based on specific URL paths
Host Header: app.jumia.com.ng vs deals.temu.com Routes based on subdomains
Query String: jumia.com.ng?category=electronics Routes based on key-value pairs in the URL
Source IP: Only allow users from 192.168.x.x Restricts access based on IP addresses
HTTP Header: User-Agent: Mobile Directs mobile users differently
Request Method: GET, POST, PUT, DELETE Routes requests based on HTTP methods

3.Practical Examples with Jumia & Temu
Let’s take two real-world scenarios to illustrate how listener rules work:

Example 1: Path-Based Routing on Jumia
Jumia has different sections for users. If you visit:

jumia.com.ng/cards **→ The request is forwarded to **Jumia’s shopping cart service.
jumia.com.ng/electronics → The request is forwarded to Jumia’s electronics page.

How AWS Listener Rules Handle This:

The load balancer detects the path (/cards) in the request.
If the rule states "Forward to Target Group A", AWS routes the request to a specific set of servers handling the cart system.
If the rule states "Redirect to another URL", AWS may send users to another page.

Why This Matters?

Jumia can manage different sections of its site more efficiently.
Users get a faster and more optimized experience.

Example 2: Query String Routing on Temu
Some websites personalize content based on Query Strings. If you visit:

temu.com?region=US → You see US-specific deals.
temu.com?region=UK → You see UK-based deals.

How AWS Listener Rules Handle This:

The Query String (?region=US) is detected in the request.
The rule checks the value (US or UK).
The system routes the user to the appropriate localized content.

Why This Matters?

Temu can personalize experiences for users based on their region.
Helps in localized marketing and promotions.

4.Hands-On Guide: Setting Up Listener Rules in AWS
Now, let’s create listener rules in AWS using the AWS Console.

Step 1: Create a Load Balancer

Go to AWS Console → EC2 → Load Balancers.
Click Create Load Balancer → Choose Application Load Balancer.
Configure the listener on port 80 (HTTP).
Add at least two EC2 instances **as **target groups.

Step 2: Add Listener Rules

Navigate to** Listener Rules** → Click Add Rule.
Click Add Condition → Choose one:
- Path-Based Routing → /cards → Forward to Target Group A.
- ** Query String-Based Routing** → ?region=US → Forward to Target Group B.
Click** Save**.

Step 3: Test Your Rules

Copy the Load Balancer DNS Name.
Open a browser and test:
- http://your-load-balancer-DNS/cards → Should redirect as per your rule.
- http://your-load-balancer-DNS?region=US → Should forward as expected.

5.Best Practices for Listener Rules

Use Priorities – Rules execute in order, so set priority levels carefully.
*Avoid Overlapping Rules *– Ensure each rule has unique conditions.
Use Redirects Wisely – Avoid unnecessary redirections that slow down performance.
Optimize Security **– Restrict access using **Source IP rules where necessary.

Advanced Hands-On Scenarios for Listener Rules in AWS
Now that we’ve covered the basics of listener rules, path-based routing, and query strings, let’s explore more advanced hands-on scenarios to deepen your understanding.

Using HTTPS Listeners for Secure Traffic By default, most websites use HTTPS (port 443) to encrypt traffic. AWS Load Balancers allow us to set up an HTTPS listener to handle secure requests.

Steps to Configure an HTTPS Listener

Navigate to the AWS Console → Load Balancers.
Click on your Application Load Balancer (ALB).
Under** Listeners*, **click Add Listener* → Choose HTTPS (443).
Attach an SSL/TLS certificate (use AWS Certificate Manager if you don’t have one).
Click Create and save your listener.

How This Works

When a user visits https://yourwebsite.com, traffic is encrypted.
The ALB terminates SSL and forwards the request securely.
You can create rules to allow only HTTPS traffic and redirect HTTP to HTTPS.

Bonus: Redirect HTTP to HTTPS
Add a rule under Listener Rules:

Condition: If a request comes through HTTP (80)
Action: Redirect to HTTPS (443) - Status Code: 301 (Permanent Redirect) Now all traffic will be securely redirected to HTTPS!

2.** Implementing Custom Error Responses & Redirects**
Instead of displaying a generic "404 Not Found" error when a page doesn’t exist, you can customize error responses using listener rules.

Example: Redirecting Users When a Page is Not Found
Let’s say a user visits jumia.com.ng/deals but the page is down. Instead of showing an error, we can redirect them to another page.

Steps to Configure a Custom Redirect in AWS ALB

Go to Load Balancer Rules → Click Add Rule.
Add a Condition → Choose a Path-based condition (e.g., /deals).
Set the Action **→ **Choose Redirect.
Enter the new URL (e.g., https://jumia.com.ng/promotions).
Save the rule. Now, when users visit /deals, they are automatically redirected to the promotions page instead of seeing an error!

Example: Returning a Custom Error Response
Sometimes, you may want to return a fixed response instead of redirecting users.

Condition: Path /deals do not exist.
Action: Return Fixed Response → "Sorry, this page is temporarily unavailable. Check back later!"
HTTP Status Code: 503 (Service Unavailable). Now, instead of a default 404 error, users will see a custom message!

3. Configuring API Gateway & Lambda with Load Balancers
AWS API Gateway and Lambda can be integrated with ALB to create serverless applications that process user requests dynamically.

Scenario: Using API Gateway to Route Requests via Load Balancer
Imagine Jumia wants to handle customer orders using an API. Instead of directing users to different EC2 instances, we can use API Gateway and Lambda with the Load Balancer.

Step-by-Step Guide

Create an API in API Gateway
Go to API Gateway → Click Create API **→ Choose **HTTP API.
Set the Endpoint as your** Load Balancer’s DNS name**.
Define the paths (e.g., /orders).
Create a Lambda Function for Handling Orders

Go to AWS Lambda → Click Create Function.
Write a function that processes orders:

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": "Order received successfully!"
    }

Deploy the function and integrate it with API Gateway.

3. Set Up a Listener Rule in ALB
Condition: If the path is /orders.
Action: Forward the request to API Gateway instead of EC2.
Now, when users visit https://jumia.com.ng/orders, the API Gateway will invoke the Lambda function, process the request, and return a response!

Using Priority to Manage Multiple Rules In AWS Load Balancers, rules are evaluated based on priority, meaning:
Lower priority numbers execute first.
If multiple rules match, the one with the lowest number is applied.

Example Scenario: Handling Multiple Conditions
Let's say:

Users visiting jumia.com.ng/orders should be routed to API Gateway.
Users visiting jumia.com.ng/deals should be redirected to /promotions.
Users visiting jumia.com.ng?region=US should be sent to US servers.

Rule Setup in AWS:

Priority Condition Action
1 /orders Forward to API Gateway
2 /deals Redirect to /promotions
3 ?region=US Forward to US-based EC2 servers

The Load Balancer will process the rules in order, ensuring correct traffic routing!

Final Thoughts
We’ve now explored multiple hands-on scenarios for AWS Listener Rules, including:

Using HTTPS listeners for secure traffic.
Implementing custom redirects & error responses.
Integrating API Gateway & Lambda for dynamic routing.
Managing priority for multiple listener rules.

Using real-world concepts used in companies like Jumia, Temu, and Amazon to optimize traffic flow and improve user experience.

Difference Between the Beginner and Advanced Hands-On Scenarios for Listener Rules in this article

The beginner-level explanation of listener rules covered the basic concepts and simple configurations using practical examples like Jumia and Temu. The focus was on:

What listener rules are and why they are important in a Load Balancer.
Basic conditions like Path-based routing and Query Strings (e.g., /cart → directs traffic to a specific target group).
Simple actions such as forwarding traffic, redirecting users, and returning error responses.
Understanding **query strings **and how they affect URL-based routing (?region=US). This level is good for understanding how requests are processed and routed in a load balancer using basic rule-based conditions.

The advanced hands-on scenarios take it further by introducing:

Security Enhancements – Implementing HTTPS listeners instead of just HTTP for secure traffic encryption
Custom Error Responses & Redirects – Handling 404 errors dynamically with custom messages or redirects (e.g., if /deals is unavailable, redirect to /promotions).
Integrating API Gateway & Lambda – Instead of routing traffic only to EC2 instances, we invoke serverless APIs dynamically. 4.** Priority-Based Rule Evaluation** – Learning how **AWS processes multiple listener rules **based on priority values.

This level simulates real-world scenarios used in cloud architectures at companies like Jumia, Amazon, and Temu, where security, automation, and flexibility are essential.

6. Conclusion
AWS Listener Rules are powerful tools for controlling traffic flow in a Load Balancer. By using Path-Based Routing, Query Strings, and Host Headers, businesses like Jumia and Temu can efficiently route users to the right pages.

If you're practicing with AWS Console, try setting up **custom listener rules **and experiment with different conditions. The more hands-on experience you get, the better you'll understand how AWS Load Balancers work!

Connecting to an EC2 Instance: A Deep Dive into Session Manager

Glory Ugochukwu — Mon, 21 Apr 2025 08:09:52 +0000

Introduction

When working with Amazon EC2 instances, one of the first things you'll need to do is connect to your instance to manage and configure it. There are several different ways to establish a connection. AWS provides multiple ways to achieve this, each with its own advantages and considerations. One commonly used method is Secure Shell (SSH), which requires key pairs. While many are familiar with SSH via PuTTY or the browser-based EC2 Instance Connect, a more secure and centralized option exists: AWS Systems Manager Session Manager.

In this article, I'll break down the different ways to connect to an EC2 instance, why Session Manager is a game-changer, and how to use it effectively. This is based on my hands-on learning, and I'll make sure to explain the reasoning behind each choice so that both beginners and those interested in cloud deployment can see the depth of understanding involved.

Different Ways to Connect to an EC2 Instance

AWS provides multiple methods to connect to an EC2 instance, and choosing the right one depends on security, ease of use, and the level of management you want. Here are the three primary ways:

EC2 Instance Connect (Browser-Based Access)
- This is the easiest and most direct method.
- Simply click Connect from the AWS Console, and a browser- based terminal opens.
- No need for SSH keys or additional configurations.
- However, it's only available for Amazon Linux and Ubuntu instances.
SSH via PuTTY (User-Managed Access)
- Requires downloading PuTTY and configuring it with a .ppk private key.
- The key file is generated from the.pem key provided when launching the instance.
- Requires opening inbound SSH (port 22) in the security group, which can expose the instance to attacks if not managed properly.
- AWS does not manage PuTTY access—you handle the configurations and security yourself.
AWS Systems Manager Session Manager (AWS-Managed Access)
- A fully AWS-managed solution.
- No need to open inbound SSH ports, making it more secure.
- Centralized access control using IAM policies.
- Does not require you to manage key pairs.
- Works with instances that have the SSM Agent installed and an IAM role with necessary permissions.

What is AWS Session Manager?
AWS Session Manager is a feature of AWS Systems Manager (SSM) that enables secure shell access to EC2 instances without requiring an SSH key or opening ports. It leverages IAM roles to grant access and manage permissions.

Why Choose Session Manager?
Unlike PuTTY, where AWS does not manage the access or security settings, Session Manager offers a hassle-free and secure way to connect to EC2 instances:

No need for inbound ports: Eliminates the risk of unauthorized access through SSH.
IAM-based access control: You can define who has permission to access which instances. -** Centralized logging**: Session logs can be sent to Amazon S3 or CloudWatch for auditing.
Bastion host replacement: Traditionally, to access private EC2 instances, you’d need a Bastion Host (a publicly accessible instance acting as a gateway). Session Manager removes this requirement.
Access from anywhere: You don’t need to install additional software like PuTTY—just use the AWS Console or AWS CLI.

What is a Bastion Host?
A Bastion Host is an EC2 instance used as a secure gateway to access other private instances inside a VPC. While effective, it requires proper security configurations and maintenance, unlike Session Manager, which eliminates the need for it entirely.

Steps to Set Up Session Manager for EC2

Create an IAM Role for EC2 Since Session Manager relies on IAM roles, we must create a role that grants EC2 the necessary permissions.

Navigate to AWS IAM Console.
Select Roles > Create Role.For Session Manager to work, the instance needs an IAM role with SSM permissions. Create a role with the following managed policy attached: AmazonSSMManagedInstanceCore
Under Trusted entity type, choose AWS service.
Under Use case, select** EC2** and click Next.
Attach the policy: AmazonSSMManagedInstanceCore.
Click Next, name the role (e.g., SSM_EC2_Access), and create the role.

Attach the IAM Role to Your EC2 Instance
If you are launching a new instance:
- In the EC2 launch wizard, under Advanced Details, locate IAM Instance Profile.
- Select the IAM role (SSM_EC2_Access) created earlier.
- If the instance is already running:
- Navigate to EC2 Console > Instances.
- Select your instance and go to Actions > Security > Modify IAM Role.
- Select the SSM_EC2_Access role and save changes.
Ensure SSM Agent is Installed
Amazon Linux and Ubuntu AMIs come with SSM Agent pre-installed. If using another OS, install the agent manually:

sudo yum install -y amazon-ssm-agent  # Amazon Linux
sudo snap install amazon-ssm-agent  # Ubuntu

For Windows:

Start-Service AmazonSSMAgent

Connect to the Instance Using Session Manager Once the instance is properly configured:

AWS Console → EC2 → Select Instance → Click on "Connect" Select Session Manager → Click "Start session" Or
Navigate to AWS Systems Manager > Session Manager.
Click Start session.
Select the instance and click Start session.
You now have shell access to the EC2 instance. Alternatively, use the AWS CLI:aws ssm start-session --target <instance-id>

Troubleshooting
If you cannot connect using Session Manager, check the following:

Ensure IAM role is attached to the instance.
Confirm AmazonSSMManagedInstanceCore policy is included.
Verify SSM Agent is installed and running. ( Ensure the EC2 Instance Has SSM Agent Installed Most Amazon Machine Images (AMIs), including Amazon Linux 2 and Ubuntu, come with the SSM Agent pre-installed. To verify, run:sudo systemctl status amazon-ssm-agent
Make sure the instance has internet access or a VPC endpoint for SSM.

Conclusion

Among the different methods of connecting to an EC2 instance, Session Manager stands out as the most secure and managed approach. Unlike PuTTY, where you must handle key configurations and security yourself, AWS manages the entire access process for you. No inbound ports need to be opened, and access is controlled centrally via IAM. If you're looking for a robust and secure way to manage your EC2 instances, Session Manager is the way to go.

This is part of my hands-on cloud learning journey, and I hope it helps anyone navigating the different ways to connect to an EC2 instance. Let me know if you have any questions or if there's anything you'd like me to explore further!

Infrastructure as Code: Building a Custom Network & EC2 with user data script with Terraform.

Glory Ugochukwu — Wed, 16 Apr 2025 00:28:18 +0000

As a Cloud Solution Architect trainee, learning Infrastructure as Code (IaC) became a key priority for scaling and automating cloud environments. This week, I built and deployed a custom AWS network using Terraform—all from my local machine with VS Code. In this post, I’ll walk you through how I created a VPC, public subnet, internet gateway, route table, and launched an EC2 instance that served a static website using a user data script.

Whether you're just starting with Terraform or need a clear beginner use case, this is a friendly walkthrough of using Terraform and VS Code to launch infrastructure on AWS. Let’s dive in!

Project Summary
I used Terraform to automate:

Building a custom VPC
Creating a public subnet
Launching an EC2 instance with a user data script
Hosting a static website with Apache

Prerequisites
Before diving into this project, you should have:
Basic knowledge of AWS services (EC2, VPC, Subnets, Security Groups)

Terraform installed and configured
AWS CLI installed and configured with IAM credentials
A code editor like VS Code(with Terraform extension)
Familiarity with Linux commands
AWS account

The main components are:

A VPC with public and private subnets
A Security Group to allow HTTP/SSH access
An EC2 Instance with Apache and a custom HTML page deployed using user_data

Architecture Overview

Folder Structure

terraform-project/
├── main.tf
├── provider.tf
├── user_data.sh
├── terraform.tfstate
├── terraform.lock.hcl

Configure AWS provider in provider.tf
Build resources in main.tf: VPC, subnet, IGW, route table, EC2 instance
Use the user data script in user_data.sh to automate Apache installation.

Deploy with:

terraform init
terraform plan
terraform apply

Components

VPC: A custom Virtual Private Cloud to logically isolate my resources.
Public Subnet: One subnet within the VPC, configured to host public-facing resources.
- Internet Gateway (IGW): To allow internet access into the VPC.
- Route Table: Associated with the subnet to enable traffic routing through the Internet Gateway.
- EC2 Instance: A virtual machine launched into the subnet, configured via a user data script to automatically install Apache and serve a static website.

How It All Connects

The VPC is the main network boundary.
Inside it, I created a public subnet.
An Internet Gateway is attached to the VPC.
A Route Table is created with a default route (0.0.0.0/0) pointing to the Internet Gateway and associated with the subnet.
An EC2 instance is launched in the public subnet.
A user data script runs on the instance at launch, installing Apache and copying my static website files.
The instance is reachable via its **public IP **because:
- It’s in a public subnet.
- It has a public IP association enabled.
- The Security Group allows HTTP access on port 80.

Troubleshooting Errors:

I got so many errors from my scripts, but I didn't give up, I kept trying

I checked the console, and my instance was running. did the same when I built a custom network.

And here's the result

Cleaning Up
If you want to avoid AWS charges:
terraform destroy

What I Learned

How to set up infrastructure using code
How to work with user data scripts for automation
How to break a project into modular files
How powerful and addictive Infrastructure as Code can be.

What’s Next?
I'll expand this by:

Creating a private subnet.
Launching EC2 in a private network.
Creating and associating a NAT Gateway.
Using Elastic IP for NAT.
Automating more with modules.

Conclusion
This was my first hands-on Terraform project, and it gave me real insight into the power of infrastructure as code (IaC). Being able to provision a complete environment with a few files and commands felt like magic and was less intimidating. Every challenge helped me grow, and I can’t wait to complete the rest of the architecture.
If you're just starting, try building a similar setup and share your experience. Feel free to drop questions or thoughts in the comments!"

Let's Connect
I'm learning Cloud Solutions Architecture and sharing every step.
Follow me here and on https://www.linkedin.com/in/glory-ugochukwu-customer-support-speacialist/ for more beginner-friendly content!

Automating Cross-Region Replication in AWS S3 Using Lambda Triggers

Glory Ugochukwu — Mon, 14 Apr 2025 00:09:21 +0000

When you're storing critical or sensitive data in Amazon S3, relying on a single region isn't always safe. That's where Cross-Region Replication (CRR) comes in—it helps protect your data by automatically copying objects from one region to another. While Amazon S3 offers built-in Cross-Region Replication (CRR), sometimes your use case demands more than just copying data—you may need custom logic, logging, security validation, or notifications. When I was introduced to Cross-Region Replication (CRR) in S3, I thought AWS handled everything internally.

But then came the question: “What if I want to control that replication manually?” Maybe I want to inject logic, like logging, filtering, integrating with other AWS services, or sending a notification when a file is replicated. That’s where AWS Lambda comes in as a trigger to enable event-based CRR tailored to your needs.

In this article, I’ll walk you through how to use AWS Lambda as a trigger for cross-region replication of S3 objects. This gives you fine-grained control over what happens when files land in your bucket.

Why Use Lambda with CRR?
S3 CRR is powerful, but it’s also rigid. It works great for general replication. Sometimes you want more control over what gets replicated, when, and how—and Lambda gives you that power. So, if you want to:

Replicate only certain file types?
Filter by tags or extension?
Perform actions before or after replication?
Log replication activity or send email alerts?
Encrypt files or trigger backup workflows?
Notify admins when CRR happens

That’s where Lambda + S3 event notifications shine. You can customize your logic with Python or Node.js and scale it on-demand.

Real-World Use Cases

Disaster Recovery: Say; A bank or any company replicates transaction logs from s3://transactions-east to s3://transactions-west using Lambda. This ensures data availability and operational continuity even if a region goes down.
Compliance &Compliance-Driven Redundancy: Government regulations or Healthcare data may require data to be stored in specific regions. With Lambda, every upload can be monitored and replicated with logs saved in CloudWatch or DynamoDB.
Media/Content Workflows A media company stores videos in us-east-1 for editing, but automatically pushes final edits to an archival bucket in `us-west-2 ' triggered by uploads.
Data Segmentation & Backup An e-commerce platform might replicate invoices, but skip raw logs—Lambda filters based on filename or tags before replication.

Architecture Overview

Here’s what we’ll use:

S3 Bucket (Source) – The primary location where files are uploaded.
S3 Bucket (Destination) – A bucket in a different AWS region.
AWS Lambda – To execute replication logic when a file is uploaded.
IAM Role – Permissions for Lambda to access both buckets.
S3 Event Notification – Triggers the Lambda function on file upload
(Optionally) SNS – again, for visibility.

Steps to Set Up This Function
Step 1: Create Two Buckets in Different Regions.
source-bucket: my-crr-source (Region: us-east-1)
destination-bucket: my-crr-destination (Region: us-west-2)
Make sure versioning is enabled on both.

Go to Source Bucket → Replication Rules → Create Rule
Choose Destination Bucket
IAM Role: Allow S3 to replicate objects
Save the rule

Create IAM Role for Lambda Assign permissions:
s3:GetObject
s3:PutObject
s3:ListBucket
Trust policy for Lambda.

Step 3: Create an SNS Topic for Email Notification

Go to SNS Console → Create Topic
Topic Name: S3ReplicationNotification
Type: Standard
Create a Subscription
Protocol: Email
Enter your email address
Confirm subscription (Check your email for confirmation)

Write Lambda Function Here’s a basic Python code to replicate objects on s3:ObjectCreated:* event:

`
import boto3
import os

s3 = boto3.client('s3')

DESTINATION_BUCKET = 'destination-bucket-name'

def lambda_handler(event, context):
for record in event['Records']:
src_bucket = record['s3']['bucket']['name']
key = record['s3']['object']['key']

    copy_source = {'Bucket': src_bucket, 'Key': key}

    s3.copy_object(
        CopySource=copy_source,
        Bucket=DESTINATION_BUCKET,
        Key=key
    )

return {
    'statusCode': 200,
    'body': f"Replicated {key} to {DESTINATION_BUCKET}"
}

`
Deploy the Lambda Function

Use the Python boto3 SDK to copy objects from the source to the destination bucket.

Step 5: Set Up S3 Event Trigger for Lambda

Go to Lambda → Create Function → Author from Scratch
Runtime: Python 3.9
Execution Role: Attach IAM Policy with
AmazonS3FullAccess
AmazonSNSFullAccess
Go to Source Bucket → Properties → Event Notifications
Create new event notification
Event Name: S3ReplicationTrigger
Event Type: PUT (File Uploads)
Destination: Lambda Function (Select the Lambda function)

Test Your Setup
Upload a File to source-bucket-us-east-1
Check Destination Bucket (File should appear there)
Check Email for replication notification

For large files or specific object types, include filters or size checks in the Lambda code.
Ensure that Lambda has access to both buckets and is deployed in the same region as the source bucket.
You can extend this by integrating SNS to alert teams when a CRR is performed.

Automating EC2 Shutdown with Lambda, EventBridge & SNS –

Glory Ugochukwu — Wed, 09 Apr 2025 00:45:55 +0000

In cloud computing, efficiency is everything. Imagine you're managing cloud infrastructure with multiple EC2 instances running. We often deploy EC2 instances for testing, learning, or short-term tasks. Some are used for batch jobs and dev environments. Often, these instances are left running overnight, leading to unnecessary billing. What if you could automate shutting them down—say, every night at 10 PM—and even receive an email confirmation when it happens?

This article walks through a real-world automation project that uses AWS Lambda, Amazon EventBridge, SNS, and Python to stop an EC2 instance on a schedule—and send an email notification when it's done.

It's simple, cost-effective, and powerful. And yes, it was part of a real hands-on training session where I executed the entire workflow. Let’s dive in.

Why Automate EC2 Shutdown?
In real cloud environments—especially dev or training setups—it's common to:

Forgot to stop EC2 instances after use.(I have had to pay bills due to forgotten instances running)
Leave dev/test environments running overnight or over weekends.
Lose track of idle instances when managing multiple resources.

Here’s what this automation solves: Real-World Applications & Why It Matters

Cost control: Automatically stop dev/test environments after business hours. saving you money.
Resource Management: Free up unused compute resources.
Operational discipline: Prevent unnecessary resource usage and reduce risk.
Operational Efficiency: Reduce manual intervention and human error.
Security: Shut down public-facing instances during off-hours for added security.
Accountability: Get notified (via email) every time your automation runs.
Scalability: Apply this pattern across environments and projects.
Integration: Use it as part of a broader CI/CD or infrastructure automation strategy.

Scenario and Benefits
Student or Trainee environments: Avoid surprise AWS bills during self-paced learning.

Dev/Test teams: Automatically shut down EC2 environments after office hours.

Cloud Budgets for Startups: Enforce spending discipline without constant human effort.

CI/CD Pipelines: Tear down staging environments after deployment testing.

Freelancers/Consultants: Manage client projects efficiently and remotely.

Services We’ll Use

EC2 (Elastic Compute Cloud) – the target of the automation (the instance you want to stop).
IAM (Identity and Access Management)– because Lambda needs permissions to stop an EC2 instance, I attached a role with ec2:StopInstances permission.
AWS Lambda– the brain of the operation. Serverless compute. where I wrote the Python function to stop the instance.
EventBridge (formerly CloudWatch Events)– this acts like a scheduler. I used this to trigger the Lambda at a specific time or interval.
SNS (Simple Notification Service) – this one was optional, but I wanted to get a confirmation that “Hey, your instance has been stopped!” without going back into the console. So I used SNS to send an email notification.

What is AWS Lambda? AWS Lambda is a serverless computing service where you upload your code, and AWS runs it automatically in response to events. An event-driven infrastructure.

Step-by-Step Implementation
Here are the exact steps I followed,

Launch an EC2 Instance: that we want to automatically stop. Note the Instance ID—you’ll use it in your Lambda function.

Create an SNS Topic & Email Subscription
Create the topic:
Navigate to Amazon SNS >** Topics** > Create topic.
Choose Standard.
Name: StopEC2Topic.

Create an email subscription:

Go to the topic **> **Create subscription.
Protocol: Email
Endpoint: Your email address.
Confirm the subscription from your inbox.

Step 3: Create the Lambda Function
Go to:

AWS Lambda > Create Function
Name: StopEC2Function
Runtime: Python 3.9 or any...
Execution role: Create a new role with basic Lambda permissions or attach the role you created.

Replace code with:

`import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    sns = boto3.client('sns')

    instance_id = 'i-0123456789abcdef0'  # Replace with your Instance ID
    topic_arn = 'arn:aws:sns:region:account-id:StopInstanceTopic'  # Replace with your SNS Topic ARN

    # Stop EC2 instance
    ec2.stop_instances(InstanceIds=[instance_id])

    # Send notification
    message = f"EC2 Instance {instance_id} has been stopped successfully."
    sns.publish(TopicArn=topic_arn, Subject="EC2 Shutdown Notice", Message=message)

    return {
        'statusCode': 200,
        'body': message
    }
`

Add Permissions to Lambda Role: ** Update IAM Role with Required Permission**

Go to IAM > Roles, find the role created with Lambda, and attach the following permissions: AmazonEC2FullAccess AmazonSNSFullAccess

Alternatively, create a role with these permissions and attach it when creating your Lambda function.

Step 5: Create an EventBridge Rule
To schedule the shutdown:

Go to Amazon EventBridge > Rules.
Click Create rule.
Name: StopEC2Schedule
Define schedule:Choose cron expression (e.g., cron(0 22 * * ? *) for 10 PM daily)
Target: Select Lambda Function, then choose the Lambda you created

Step 6: Add EventBridge as a Trigger to Lambda

Go back to your Lambda function:
Click Add trigger
Choose EventBridge (CloudWatch Events)
Select the rule you just created

And That’s It!
You’ve built a fully automated EC2 shutdown system with:

Scheduled execution via EventBridge
Logic handled in a Lambda function
Email alert via SNS And the best part? You don’t need to keep a server running or manually intervene to execute this logic. It’s 100% serverless and scalable.

Bonus Tips
-You can extend this to start instances in the morning. Say, start instances at 8 AM automatically.

Add multiple instance IDs if you need to manage more than one.
Log actions to CloudWatch for auditing.
Use Tags to identify instances for stopping (e.g., AutoStop = true).
Extend this for RDS or S3 lifecycle automation

Conclusion
Cloud Server automation is a powerful superpower. It isn’t just for massive enterprise projects. Even small use cases like this one can save money, reduce errors, and simplify your cloud usage. This is also a great portfolio project for anyone preparing for AWS certifications or roles like Cloud Support Engineer or Solutions Architect.
Try it, customize it, and make it yours.

By: Glory Ugochukwu – AWS Solution Architect Trainee

Building a Scalable E-commerce Backend with DynamoDB, Lambda, API Gateway, and S3.

Glory Ugochukwu — Tue, 08 Apr 2025 22:58:44 +0000

Series: AWS Serverless Projects

Introduction.

In today’s digital era, platforms like Amazon, Temu, and Jumia handle billions of requests daily. From browsing products to adding items to a cart and uploading product images—every click requires a responsive, fault-tolerant backend architecture. Each user interaction is powered by various AWS services working in sync.

In this article, I’ll walk you through how we used DynamoDB, AWS Lambda, API Gateway, and S3 to simulate a lightweight backend for an e-commerce application. This was part of my hands-on class project, where we tested our APIs using Postman.
But before jumping into the how-to, let’s understand why and how these services are relevant—and what makes them ideal for real-world use cases.

DynamoDB: Why DynamoDB for E-commerce?

DynamoDB is a serverless, fully managed, NoSQL database service provided by AWS. Now, “Serverless” here doesn’t mean there are no servers—it means the cloud provider (AWS in our case) manages the servers, scalability, and infrastructure. You focus solely on writing business logic.

Understanding the Data: Structured vs Unstructured and Semi-Structured Data.
Before building, let’s talk data. E-commerce platforms like Temu, Amazon, and Jumia deal with both structured and unstructured data:

Structured Data
Data that fits neatly into Organized tables, rows, and columns (think Excel or SQL tables):

Examples: Users, orders, transactions.
Where it lives: Can go into RDS (Relational Database Service) like MySQL or PostgreSQL

Unstructured / Semi-structured Data
Data that doesn’t follow a strict schema, i.e, doesn’t fit neatly into tables, raw formats.

Examples: Product attributes (color, size, promo details), user reviews, images, videos, large texts, JSON documents.
Where it fits: Perfect for DynamoDB—a NoSQL, key-value/document-based database

Example:
In an e-commerce app:

Use DynamoDB to store product catalog and customer carts in flexible JSON format.
Use RDS for structured transaction logs and payment history. DynamoDB is great for semi-structured data because it stores data in key-value and document formats, typically as JSON objects. It thrives in scenarios requiring high-speed access.

Real-world E-commerce Example: Temu, Amazon, Jumia
Let’s consider an e-commerce store that sells products online:

Product and Customer Data (Structured)
- Each product has a product_id, name, price, category, and Quantity.
- Customer records include user_id, email, and order history.
Product Images (Unstructured) Stored in S3. The connection to the database is made by storing the image URL in DynamoDB. Each file has a key, typically the product ID.
- Every S3 object also has an ARN (Amazon Resource Name) for resource identification.
- DynamoDB links the image via a URL using the partition key (e.g., product_id).
Product Listings – Semi-structured Stored in DynamoDB:

{
  "productID": "12345",
  "name": "Laptop",
  "attributes": {
    "RAM": "8GB",
    "Storage": "512GB SSD",
    "Color": "Silver"
  },
  "price": 800
}

Cart System (Semi-Structured / Temporary) Cart contents change frequently. Storing this temporary data in a persistent database would be costly and inefficient.

Solution: Use Caching
AWS ElastiCache (Redis or Memcached) stores temporary cart data in-memory.
This reduces database read/write load and improves performance.
The cart data can be stored using session IDs, keyed against user_id. If a user doesn’t check out, data can be purged automatically after expiry.

Example DynamoDB JSON Entry:

{
  "product_id": "P123",
  "name": "Bluetooth Speaker",
  "price": 4500,
  "category": "Electronics",
  "image_url": "https://s3.amazonaws.com/mybucket/P123.jpg"
}

How Does S3 Know Which Image Belongs to Which Product?
When an image is uploaded to S3, it receives a URL and is stored under a key (often named using a product ID). In DynamoDB, we store the image_url as part of the product record.
The link between the product and its image is made possible using:

Primary Key or Partition Key (e.g., product_id)
S3 Object URL
Unique Identifier (ARN) for every resource

Caching: Why and How?
E-commerce platforms experience spikes in traffic. Caching helps improve speed and reduce load.

ElastiCache (Redis): Fast, in-memory caching engine for temporary data like sessions, carts, or search queries.
Benefits: Reduces repeated database calls, ensures low latency.

Enter ElastiCache
**ElastiCache **is an AWS in-memory data store, ideal for:

Shopping cart data
User session data
Product views

Architecture Overview
Let’s break down how we built this in our class using Lambda, API Gateway, DynamoDB, and S3:

Component Role
DynamoDB: Stores products in JSON format
S3: Hosts images, connected via product ID or URL
Lambda: Executes code for each API request (e.g., add, update, delete items)
API Gateway: Provides HTTP endpoints to trigger Lambda.
Postman: Tests the API endpoints with sample requests

Step-by-Step (Based on Our Classwork)

Create a DynamoDB Table

Table name: Products
Partition Key: product_id
Additional attributes: name, price, category, image_url

Upload Product Images to S3
- Upload images with file names like P123.jpg
- Make the object publicly accessible (or use pre-signed URLs)
- Note the S3 URL:https://s3.amazonaws.com/mybucket/P123.jpg for use in DynamoDB
Create Lambda Functions
Each function is written in Python (or Node.js) to perform:

POST: Insert product into DynamoDB
GET: Retrieve by product ID
PUT: Update product data
DELETE: Remove product record Each function uses Boto3 (Python SDK) to interact with DynamoDB. When configuring Lambda, go to permissions on the IAM role, attach DynamoDB full access, add your Python code to the Lambda function, and deploy.

Set Up API Gateway

Create REST API
Define routes: /product, /product/{id}
Create and Link methods (put, post, get, delete) to respective Lambda functions

Test with Postman Use Postman to send requests and observe live responses.

{
  "product_id": "P123",
  "name": "Bluetooth Speaker",
  "price": 4500,
  "category": "Electronics",
  "image_url": "https://s3.amazonaws.com/mybucket/P123.jpg"
}

Test the GET, PUT, and DELETE endpoints to complete the flow.

Why This Architecture Works in the Real World

Scalability: All services are fully managed and scale automatically.
Flexibility: DynamoDB's JSON support is perfect for evolving product data.
Low Latency: Lambda + API Gateway = near-instant execution.
Separation of Concerns: Images are stored in S3, metadata in DynamoDB.
Secure Resource Management: Each AWS resource has an ARN and is defined with access via IAM.
Cost-Effective: Pay only for what you use
Highly Available: S3 and DynamoDB are designed for 99.99% uptime
Serverless: No infrastructure management. Multi-region setups: Use Global Tables in DynamoDB and S3 Cross-Region Replication for high availability.

Conclusion
In today’s cloud-driven world, building a robust, serverless, and scalable backend for an e-commerce platform is not only possible but also very practical. This hands-on setup is a mini version of what happens behind the scenes when building e-commerce systems, You don’t just need a database—you need a responsive, modular architecture. DynamoDB, Lambda, S3, and API Gateway form a powerful foundation for a modern, serverless backend. Paired with in-memory services like ElastiCache, this stack supports everything from dynamic product catalogs to blazing-fast cart systems.
Developers can build robust, responsive, and scalable e-commerce applications without managing servers.

Try It Yourself
Want to try this architecture?

Launch a free-tier AWS account.
Create your API Gateway and Lambda function.
Connect to DynamoDB.
Upload a product image to S3 and link its URL in your product item.

I’m documenting my learning journey, AWS, and Cloud Architecture. If you found this useful, consider following me here on Dev.to
I’ll be sharing more hands-on AWS articles, projects, and architecture breakdowns.
Let’s build in the cloud together!

Understanding Load Balancers: Concept, Use Cases & Practical Application.

Glory Ugochukwu — Wed, 05 Mar 2025 18:43:32 +0000

In today's digital landscape, where applications and services must handle millions of requests per second, ensuring availability, reliability, and efficient traffic distribution is crucial. This is where Load Balancers come into play. A Load Balancer acts as an intelligent traffic manager, distributing network or application traffic across multiple servers to optimize resource utilization, maximize throughput, and minimize response time. This article explores the concept, types, functionality, use cases, and a step-by-step approach to setting up a load balancer.

What is a Load Balancer?
A Load Balancer is a networking solution that distributes incoming traffic across multiple servers to ensure high availability, scalability, and reliability of applications. It acts as an intermediary between users and backend servers, preventing any single server from becoming overwhelmed. Load Balancers operate at different layers of the OSI model, typically at:

Layer 4 (Transport Layer): Directs traffic based on IP and TCP/UDP information.
Layer 7 (Application Layer): Routes traffic based on application-level data (HTTP headers, cookies, etc.).

Let's break the Network Component of it down first.

Role in Network Traffic Management A load balancer sits between clients and backend servers, acting as an intermediary that routes network traffic efficiently.It ensures that no single server is overwhelmed, improving network performance and reliability.
Works at Network Layers (OSI Model)as mentioned above.
Uses Network Protocols Load balancers handle requests using protocols such as TCP, UDP, HTTP, and HTTPS. These protocols are fundamental to how devices communicate over a network.
Integral Part of Network Infrastructure Load balancers are deployed within a network architecture to ensure high availability, redundancy, and security. They interact with firewalls, DNS, and backend servers, making them a crucial part of modern network infrastructure.

A load balancer is responsible for directing and managing network traffic at different layers of the OSI model,In AWS, Elastic Load Balancing (ELB) plays this role within a Virtual Private Cloud (VPC) setup, ensuring scalable and fault-tolerant network operations.

How Load Balancers Work

When a client makes a request, the Load Balancer:

Receives the request – determines the best server to handle it. The Load Balancer acts as an intermediary between users and backend servers.
Distributes the request based on a configured algorithm:
-Round Robin: Assigns requests sequentially to servers.
-Least Connections: Directs traffic to the server with the
fewest active connections.
-IP Hashing: Routes users to the same backend based on their IP.
Performs Health Checks: Continuously monitors the health of servers and reroutes traffic if one fails.
Implements SSL/TLS Termination: Decrypts HTTPS requests before forwarding them to backend servers.
Uses Sticky Sessions (Session Persistence): Ensures a user remains connected to the same server when needed.
Caches Content for Faster Performance: In the case of ALB, caching helps improve response time and reduce load.
For instance, global e-commerce marketplaces eg Temu, Jumia, etc use Load Balancers to distribute millions of requests across multiple backend services. During peak shopping seasons, its infrastructure scales dynamically, ensuring fast response times for users worldwide.

Why Use a Load Balancer?

High Availability & Fault Tolerance – Automatically redirect traffic if a server becomes unhealthy. I.e If one server fails, traffic is rerouted to healthy servers.
Improved Performance – Balances the workload across multiple instances, reducing response time.
Scalability – Dynamically adjust the number of servers to handle traffic spikes or reduce costs during low demand. As demand increases, additional instances can be added, and the load balancer efficiently manages them.
Security Enhancement – Acts as a protective layer, preventing direct access to backend servers.

Use Cases of AWS Load Balancers
AWS Load Balancers are used in various scenarios, including:

Web Applications: Distributes HTTP/HTTPS traffic among multiple EC2 instances.
Database Load Balancing: Manages database read/write operations efficiently.
Auto Scaling Integration: Automatically adjusts the number of backend instances based on demand.
Microservices and Containers: Directs traffic between containers in AWS ECS/Kubernetes.
Security and Compliance: Prevents exposure of backend server IPs and protects against DDoS attacks.

Types of AWS Load Balancers
AWS provides three types of Load Balancers:

Application Load Balancer (ALB) – Best for HTTP/HTTPS traffic, Operates at OSI layer 7, the application layer
is used for application architectures and supports advanced routing features.

Network Load Balancer (NLB) – Best for handling millions of requests per second at low-latency TCP/UDP connections. used for TLS offloading, UDP, and static IP addresses. Operates at OSI layer 4, the transport layer

Classic Load Balancer (CLB)– Operates at OSI layers 3 and 7, the transport and application layers
are used if upgrading to other load balancers is not feasible.

Load Balancer Components

Listener: Defines how the Load Balancer accepts traffic. (e.g., HTTP, HTTPS, TCP).
Target Group: A collection of registered backend instances.
Targets: EC2 instances, Lambda functions, IP addresses, or containers.
Rules: Control request routing using host-based or path-based rules (for ALB).

Step-by-Step Guide to Setting Up an AWS Load Balancer.

Step 1: Launch Two EC2 Instances (check steps and config in my dashboard)

Launch two EC2 instances with Amazon Linux or Ubuntu.
Assign them to the same security group.
Attach a User Data script to install a web server automatically.

Example User Data for Instance 1:

#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd
echo "<h1>Server 1: Load Balancer Demo</h1>" > /var/www/html/index.html

Example User Data for Instance 2:

#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd
echo "<h1>Server 2: Load Balancer Demo</h1>" > /var/www/html/index.html

Step 2: Configure Target Group

Go to Target Groups and create a new one.
Register the previously launched EC2 instances.
Define a Health Check path (e.g., /index.html).

Step 3: Create an AWS Load Balancer

Go to AWS Management Console > EC2 > Load Balancers.
Choose Application Load Balancer (ALB).
Set a Listener (HTTP/HTTPS).
Select at least two availability zones for high availability.

Step 4: Attach the Target Group to the Load Balancer

Navigate to Listeners in your Load Balancer settings.
Forward traffic to the Target Group created earlier.

Step 5: Test the Load Balancer

Review the Load Balancer settings and create it.
Copy the DNS name of the Load Balancer.
Open a browser and visit http://your-load-balancer-dns-name, and refresh multiple times to see different responses from the two instances (demonstrating traffic distribution).
Traffic should alternate between Server 1 and Server 2. Mine read Server 1: Load Balancer Demo, Server 2: Load Balancer Demo

NB: After creating your instances, copy your IP address and test-run your servers. here's mine

then here's my Lb
refreshed and

Step 7: Monitor and Optimize

Use AWS CloudWatch to monitor performance metrics.
Enable Auto Scaling to dynamically adjust instance count.

Health Check & Key Considerations When Creating a Load Balancer in AWS
Setting up a Load Balancer (LB) in AWS requires careful configuration to ensure proper traffic distribution, high availability, and fault tolerance. If misconfigured, issues such as unhealthy targets, uneven traffic distribution, or instances not registering can occur. Below are crucial aspects to consider:

1. Selecting the Right Load Balancer Type
AWS provides different types of Load Balancers:

Application Load Balancer (ALB) – Best for HTTP/HTTPS traffic, routes based on URLs, headers, or cookies.
Network Load Balancer (NLB) – Best for high-performance TCP/UDP traffic, handles millions of requests per second.
Classic Load Balancer (CLB) – Older generation, supports both HTTP and TCP but lacks advanced features.
Use case example: If you are hosting a website, use an ALB. If handling financial transactions or gaming servers, use an NLB for low latency.

2. Configuring the Network Mapping
Your Load Balancer and EC2 instances must be properly mapped to ensure smooth communication:

VPC & Subnet Selection: The Load Balancer must be deployed in the same VPC as your EC2 instances.
Availability Zones (AZs): Distribute instances across multiple AZs to ensure high availability.

Subnet Requirements:

ALB requires at least two public subnets in different AZs.
NLBcan work with one or more subnets but benefits from multiple AZs. If your Load Balancer and instances are in different subnets or AZs, some instances may not receive traffic properly.

3. Security Groups and Firewalls
Misconfigured security groups can cause instances to appear unhealthy or fail to receive traffic.
e.g

Load Balancer Security Group:

Allow inbound traffic on port 80 (HTTP) or port 443 (HTTPS).
Allow requests from anywhere (0.0.0.0/0 ) or a specific trusted IP range.

Instance Security Group:

Allow inbound traffic on the application port (e.g., 80, 443, 8080) from the Load Balancer's security group (not 0.0.0.0/0).
Allow outbound traffic to the Load Balancer on the same ports. Incorrect security group rules can cause "unhealthy target" errors, meaning your Load Balancer can't reach your instances.

4. Target Group & Health Checks
The target group ensures that the Load Balancer correctly forwards traffic to healthy instances.

From the image below, you can see that my target group initially showed one unhealthy instance out of two total targets. After troubleshooting, I discovered the issue was due to a Subnet and Availability Zone mismatch. I reconfigured the settings, ensuring proper alignment between the load balancer, subnets, and availability zones, which resolved the issue and restored proper functionality.

Target Type: Choose "Instance" if routing to EC2 or "IP" for specific IP addresses.
Health Check Configuration:
Port & Protocol: This should match your instance's application (e.g., HTTP:80).
Path: Default is /, but if your app runs elsewhere (/status, /health), update it.
Thresholds: Set appropriate intervals and success thresholds to determine health status.
If the health check fails, your instance won’t receive traffic! You may need to troubleshoot by checking instance logs or security settings.

5. DNS & Domain Name Mapping
AWS Load Balancers do not have static IPs (except NLB), so you should use:

AWS Route 53 to map your domain to the Load Balancer's DNS name.
CNAME Record: If using a custom domain, configure a CNAME to point to the Load Balancer.
If only one instance receives traffic, check whether your DNS resolution points to the correct Load Balancer and if your health checks are correctly configured.

6. Logging & Monitoring
Enable monitoring tools to detect and fix issues early:

AWS CloudWatch: Monitor request counts, latency, and unhealthy hosts.
AWS Access Logs: Store detailed logs of incoming requests.
AWS X-Ray: Helps trace request flow and detect delays. If your Load Balancer is unresponsive, check CloudWatch metrics to identify traffic spikes, high latency, or instance failures.

7. Auto Scaling Considerations
To handle varying traffic loads, integrate your Load Balancer with Auto Scaling Groups (ASG):

**ASG **will automatically launch new EC2 instances when traffic increases.
Make sure new instances register with the target group upon creation.
Without auto-scaling, your instances may overload during traffic spikes, causing performance issues.

Practical Example: Troubleshooting Unhealthy Instances
Problem: You noticed only one of your two servers was receiving traffic due to an "unhealthy" target issue.
for instance, only one of my instances was showing,
because of

Steps to Fix:

Check Target Group Health:

Go to EC2 Dashboard → Target Groups → Targets and check the health status.
If an instance is marked unhealthy, hover over it to see the reason.
Verify Health Check Settings:
Ensure the health check path (e.g., /health) returns a 200 OK response.
Use curl or a browser to test http://INSTANCE-IP/health.
Check Security Groups & Network ACLs:
Make sure instances allow traffic from the Load Balancer’s security group.
Verify inbound rules allow traffic on ports 80/443.
Review Subnet & AZ Mappings:
Ensure the Load Balancer and instances are in the same subnets and AZs.
If your instance is in us-east-1a, ensure the LB also has a subnet in us-east-1a.
Check Instance Application Logs
After troubleshooting, refresh the AWS Console and verify both instances are now receiving traffic.

Both instances are now properly registered and passed health checks. The load balancer should now be distributing traffic evenly between the two targets.

Setting up an AWS Load Balancer correctly requires configuring subnets, security groups, health checks, DNS settings, and target groups. If any of these are misconfigured, issues like unhealthy targets, partial traffic distribution, or inaccessible servers may occur. By carefully aligning your Load Balancer with your EC2 instances, you ensure high availability, fault tolerance, and efficient load distribution for your application.

Benefits of Using AWS Load Balancer for E-commerce Marketplace

Scalability – Automatically scales to handle high traffic during shopping events.
High Availability – Ensures zero downtime by rerouting traffic from unhealthy instances.
Security – Integrates with AWS Shield and WAF to prevent DDoS attacks.
Performance Optimization – Reduces latency by routing requests to the closest healthy server.

Conclusion

Load Balancers are a crucial component in modern IT infrastructures, Whether you are running a simple web application or a large-scale cloud deployment, implementing a proper Load Balancing strategy is essential for maintaining optimal performance, security, availability, and scalability. Companies like Temu leverage ALB and NLB to distribute massive traffic efficiently, ensuring seamless shopping experiences. By following this practical setup, you can implement load balancing in your AWS environment.

Criticism and observations are highly welcome! I am still learning and practicing, so please feel free to share your suggestions and feedback on anything you noticed right or wrong in this article to help me improve. Thank you!

Deploying a Secure Static Website Using Amazon S3 and CloudFront.

Glory Ugochukwu — Mon, 24 Feb 2025 01:45:23 +0000

As I explained in the last article, Amazon Simple Storage Service (S3) provides scalable and cost-effective static website hosting. However, directly exposing an S3 bucket to the public poses security risks. Instead, we integrate Amazon CloudFront, a global Content Delivery Network (CDN), to serve content securely and efficiently.

This guide explains the integration between S3 and CloudFront, security best practices, and the correct policy configuration while walking you through the deployment process.

Why Use CloudFront Instead of Public Access in S3?
The Security Risk of Making S3 Public

S3 allows static website hosting, but enabling public access means anyone on the internet can access the bucket directly. This exposes your website to:

Unauthorized access and potential data leaks.
Higher costs due to unnecessary direct requests to S3.
No caching, leading to slower performance.

Best Practice: Use CloudFront as a Secure Proxy
CloudFront acts as a secure intermediary between users and S3, preventing direct access to the S3 bucket. Benefits include:

Restricted S3 Access: The S3 bucket is private, and only CloudFront can fetch content.
Lower Latency: CloudFront caches content at multiple edge locations worldwide, reducing load times.
Enhanced Security: CloudFront enforces HTTPS, preventing unauthorized traffic.
Cost Efficiency: Cached requests reduce the number of direct requests to S3, lowering costs.

CloudFront as a Global Service
Unlike S3 (a regional service), CloudFront is global, meaning it:

Uses edge locations to cache content near users.
Improves website performance by reducing latency.
Supports automatic failover, ensuring reliability.

Now, let's dive into:
Step-by-Step Guide to Deploying with S3 and CloudFront

Go to the AWS S3 console and create a bucket (e.g., my-secure-static-site) (check my article on S3 to see pictorial steps)
Block all public access to the bucket (this is crucial).
Disable static website hosting—we will use CloudFront instead.

Why? Keeping the bucket private ensures no one can access it directly. Only CloudFront will serve the content securely.

Step 2: Upload Website Files to S3

Open the bucket and upload your HTML, CSS, and JS files.
No need to change permissions—CloudFront will handle access.

Step 3: Set Up CloudFront Distribution

Go to CloudFront Console → Create Distribution.
Under Origin Domain, select your S3 bucket (not the website endpoint).
Restrict Bucket Access → Yes.
Create a New Origin Access Control (OAC). Why? OAC allows CloudFront to retrieve content from S3 securely without exposing the bucket.

Step 4: Attach the Correct Policy to S3

After creating the distribution, navigate to S3 → Permissions → Bucket Policy.
Paste the policy from CloudFront, which grants access only to the distribution.

Why Use CloudFront’s Policy Instead of a Public S3 Policy?

The bucket remains private—only CloudFront can fetch content.
Users cannot bypass CloudFront to access files directly.

Step 5: Enable HTTPS and Caching

Under CloudFront Settings, enable Viewer Protocol Policy → Redirect HTTP to HTTPS.
Set Cache Behavior to improve performance.

Why?

HTTPS secures data in transit.
Caching reduces latency and server load.

Step 6: Configure a Custom Domain (Optional)
If using a custom domain:

Set up a CNAME in Route 53 (or your DNS provider).
Request an SSL certificate via AWS Certificate Manager.
Attach the certificate to CloudFront.

Step 7: Test and Verify

Open the CloudFront distribution URL.
Verify that the website loads and redirects to HTTPS.

my website was HTML so what I did was add /index.html and here's the result.

Conclusion

By using I.e integrating CloudFront instead of direct S3 access, we create a secure, fast, and scalable static website hosting solution. CloudFront caches content at edge locations, reducing latency while keeping the S3 bucket private. This approach ensures better performance and cost efficiency while protecting your origin server from excessive requests.

Feel Free to share your thoughts, Feedback, and observations on my article, I'm still learning and practicing, so your suggestions pointing out mistakes, offering improvements, or highlighting what I did well will greatly help me grow. Thank You!

Hosting a Static Website on S3, Versioning, Lifecycle Configuration, Cross-Region Replication (CRR).

Glory Ugochukwu — Thu, 20 Feb 2025 17:36:23 +0000

Steps to host a static website on S3 and Necessary features configurations.

Here's my experience hosting a static website on Amazon S3 and configuring essential features like S3 Versioning, Lifecycle Configuration, and Cross-Region Replication (CRR). These configurations enhance data management, optimize costs, and ensure high availability.

Brief Summary of S3 before the steps

Amazon S3: (Simple, Storage, Service).The Hard Drive of AWS Stores, Retrieve and Scale effortlessly. AWS S3 is a scalable and secure cloud storage solution offered by Amazon Web Services, it allows you to store and retrieve any amount of data, at any time, providing durability, high availability, and low latency.

Use Cases

Hosting Static websites e.g (blogs, product catalogs)
Backup and recovery.

Hosting a Static Website on S3

Amazon S3 allows you to host static websites efficiently without managing servers. This is useful for personal portfolios, documentation sites, or company landing pages.

Steps to Host a Static Website on S3:

Step 1: Create an S3 Bucket

Open the AWS S3 Console.
Click Create Bucket.
Enter a unique bucket name.
Turn off "block all block access"
Enable bucket versioning
Choose a region and leave the default settings.
Click Create Bucket.

Step 2: Upload Website Files

Open the bucket and navigate to the Objects tab.
Click Upload and add your index.html, error.html, and other necessary files.

Here are the files that I uploaded.

Now, let's run some configurations.

Step 3: Enable Static Website Hosting

Go to the Properties tab.
Scroll to Static website hosting and click Edit.
Choose Enable.
Set index.html as the Index document.
Click Save Changes.

Step 4: Set Public Access Permissions

Navigate to the Permissions tab.
Click Block Public Access and disable all restrictions.
Edit the Bucket Policy to allow public access and add your bucket name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::arn:aws:s3:::aws-s3-glory/*"
            ]
        }
    ]
}

Click Save Changes.

Step 5: Access Your Website

Go back to the Properties tab.
Copy the Static website hosting endpoint.
Open it in a browser to see your hosted site.

And here's our (my first static website with S3)Website.

Versioning & Enabling S3 Versioning

S3 Versioning allows you to keep multiple versions of an object, preventing accidental deletions or overwrites.

Steps to Enable Versioning:

Open your bucket in the S3 Console.
Go to the Properties tab.
Click Edit under Bucket Versioning.
Select Enable and click Save Changes.

Key Considerations:

Each object version is stored separately, which may increase storage costs.
Suspending versioning stops new versions from being created but retains existing ones.

Lifecycle Management:
Transition Action: This enables you to move objects between different storage classes based on a defined schedule. S3 will automatically remove all objects within a bucket when a specified date or time in an object's lifetime

Configuring Lifecycle Policies

S3 Lifecycle Configuration helps you manage object storage by transitioning data to different storage classes or automatically deleting them.

Steps to Create a Lifecycle Rule:
Here's a step-by-step guide on how to implement lifecycle management within your bucket:

Navigate to your bucket and choose the "Management" tab.
Click Create lifecycle rule.
Enter a rule name and define the scope of its application.
Configure Transition actions, such as:
Move objects to S3 Infrequent Access (IA) after 30 days.
Move objects to Glacier after 90 days.
Configure Expiration actions, such as deleting objects after a set period.
Click Create rule.

Use Case: Automatically move older website logs to Glacier to save costs.

Setting Up Cross-Region Replication (CRR)

Cross-Region Replication ensures your data is automatically copied to another region, improving disaster recovery and availability.

Steps to Configure CRR:
Enable Versioning on both source and destination buckets.
Go to your source bucket’s Management tab.
Click Replication rules > Create replication rule.
Define a rule name and select a destination bucket in a different region.
Select an IAM Role (create a new one if needed).
Click Save Changes.

Considerations:
Replication applies only to new objects after enabling CRR.
Data transfer and storage costs apply to replicated objects.

And that's all for my first hands-on on S3.

Challenges Faced & Solutions I encountered few challenges while on this,

Replication Delays: CRR does not replicate old files. To fix it, I had to re-upload important objects after enabling replication.

How This Task Contributes to My Learning & Career Growth
Configuring S3 for static website hosting and data management provided me with hands-on experience in cloud storage optimization, cost management, and disaster recovery. These are essential skills for any aspiring Cloud professionals.

Through this task, I also gained deeper insights into AWS best practices, which will be valuable in enterprise-level cloud deployments.

Conclusion

Amazon S3 offers powerful capabilities beyond simple storage. By implementing Versioning, Lifecycle Rules, and CRR, you can enhance data durability, cost efficiency, and high availability.

I highly recommend experimenting with S3’s configurations. Understanding these features will strengthen your cloud expertise and prepare you for real-world scenarios.

Happy learning my fellow learners!