DEV Community: Chioma Nwosu

From Silent Failures to Reliable Deployments: Building a Two-Tier AWS Architecture with Terraform

Chioma Nwosu — Sat, 04 Apr 2026 02:20:03 +0000

Deploying applications in the cloud is often presented as a straightforward process — provision infrastructure, deploy code, and everything works.

In reality, things rarely go that smoothly.

In this project, I built and deployed a two-tier web application on AWS using Terraform, automating everything from infrastructure provisioning to application setup. What made this experience truly valuable wasn’t just the final working system — it was the debugging journey that transformed a fragile deployment into a reliable one.

Project Overview

The goal was to deploy a full-stack application with:

Frontend & Backend: Node.js app running on EC2
Database: MySQL on Amazon RDS
Infrastructure: Provisioned entirely with Terraform
Automation: Bash user data script
Architecture

The system follows a classic two-tier architecture:

EC2 (Public Subnet): Hosts the application
RDS (Private Subnet): Stores application data
VPC: Custom networking environment
Security Groups: Control traffic between layers
What I Built
Custom VPC with public and private subnets
Internet Gateway and route tables
EC2 instance with automated setup
RDS MySQL instance in private subnets
Security groups enforcing least privilege
Nginx reverse proxy configuration
PM2 process management for Node.js

All of this was provisioned using Terraform, ensuring repeatability and consistency.

Automation with User Data

To eliminate manual setup, I used a user data script to:

Install dependencies (Node.js, Nginx, MySQL client)
Clone the application repository
Configure database connection dynamically
Run database schema and seed scripts
Start the application using PM2
Configure Nginx as a reverse proxy

This allowed the application to be fully configured on instance launch.

The Challenges (Real Learning Begins Here)

Database Connection Failure

I encountered a SequelizeHostNotFoundError, which indicated that the application couldn’t resolve the RDS endpoint.

Fix:

Verified Terraform outputs
Ensured correct database host configuration

Broken Application Due to JSON Error

The app crashed due to:

Unexpected string in JSON

Fix:

Corrected formatting issues in the configuration file

The “Working” System with No Data

This was the most interesting issue.

Tables were created successfully
Application was running
But the Book table was empty

At first glance, everything looked correct.

The Root Cause

After deeper investigation, I discovered:

The seed script for books was not executed because of a misnamed file:

db/book_seed.sql ❌
db/books_seed.sql ✅

Because the user data script did not enforce failure, this error was silently ignored.

Key Insight

Automation without proper error handling can give a false sense of success.

Fixing the Problem

I implemented the following improvements:

✅ Corrected File Reference

Updated the script to point to the correct seed file.

✅ Fail-Fast Mechanism

Added:

set -e

This ensures the script stops immediately on failure.

✅ Logging for Debugging

Used:

/var/log/cloud-init-output.log

to trace execution and identify issues quickly.

Final Result

After fixing the issues and redeploying:

Infrastructure provisioned successfully
Application deployed automatically
Database fully populated
Application accessible via public IP
System fully repeatable with Terraform
Key Lessons Learned
Small mistakes (like file names) can break automation
Logs are essential for debugging cloud deployments
Always design scripts to fail loudly, not silently
Infrastructure as Code requires validation, not just execution
Troubleshooting is a core DevOps skill
Conclusion

This project reinforced that DevOps is not just about automation — it’s about building reliable, observable, and maintainable systems.

The difference between a beginner and an engineer isn’t avoiding errors — it’s understanding and fixing them effectively.

What’s Next
Adding CI/CD pipeline
Implementing monitoring and alerting
Improving deployment idempotency

From Writing Terraform to Guiding AI: My Journey into Agentic DevOps with Claude Code

Chioma Nwosu — Fri, 27 Mar 2026 18:31:19 +0000

For a long time, I thought DevOps was just about writing scripts, managing infrastructure, and automating deployments.

Then I discovered something that changed everything:

👉 What if instead of just writing code, you could guide an AI to think like a DevOps engineer?

That’s exactly what I explored while taking the Ultimate Agentic AI DevOps with Claude Code course.

And it completely reshaped how I approach building, deploying, and managing systems.

🚀 The Shift: From Tools to Agents

Traditional DevOps is tool-driven:

Terraform for infrastructure
GitHub Actions for CI/CD
Bash scripts for automation

But in this course, I learned something deeper:

DevOps is evolving from tool usage → agent orchestration

Instead of doing everything manually, I started:

Designing workflows for AI agents
Defining rules for how AI should behave
Automating decision-making, not just execution

🧠 The Most Important Concept: Context is Everything

The biggest lesson?

AI is only as good as the context you give it.

This is where CLAUDE.md comes in.

It’s not just a documentation file — it’s a control system for AI behaviour.

Inside CLAUDE.md, I defined:

Project architecture
Deployment workflows
Engineering constraints
Rules (like no JavaScript frameworks allowed)

And something amazing happened.

When I asked Claude to:

“Add a React component to the homepage”

It refused.

Not because it couldn’t — but because it understood the rules of the system.

That moment made one thing clear:

👉 We’re no longer just writing code — we’re designing AI behaviour.

⚙️ Building Real DevOps Workflows with AI

This course wasn’t just theory — it was hands-on.

I worked on:

🔹 Terraform Automation

Using slash commands like:

/tf-plan
/tf-apply

Claude could:

Generate Terraform configurations
Validate infrastructure changes
Suggest improvements

🔹 GitHub Actions + OIDC

I implemented secure CI/CD pipelines using:

GitHub Actions
OpenID Connect (OIDC)

This eliminated the need for long-lived AWS credentials, making deployments more secure.

🔹 AI Sub-Agents

One of the most powerful concepts was creating specialised AI agents, such as:

Security agent → checks for misconfigurations
Cost optimisation agent → flags expensive resources
Deployment agent → handles release workflows

This felt like building a DevOps team powered by AI.

🔹 MCP Servers (Connecting AI to Real Infrastructure)

I also explored Model Context Protocol (MCP) servers.

This allows AI to:

Interact with real systems
Fetch live data
Execute meaningful DevOps tasks

Instead of static responses, AI becomes environment-aware.

🌍 Real Outcome: What I Built

To apply everything I learned, I built and deployed:

👉 A static portfolio website on AWS (S3 + CloudFront)

But this wasn’t just a basic deployment.

I used:

AI-assisted workflows
Structured project context (CLAUDE.md)
DevOps best practices

The result?

A clean, scalable, and production-ready deployment powered by AI-guided engineering decisions.

⚠️ Challenges I Faced

This journey wasn’t without obstacles.

Struggled with MCP server connections
Faced authentication and configuration issues
Had to troubleshoot CLI environments and permissions

But these challenges helped me understand:

DevOps isn’t about avoiding problems — it’s about solving them systematically.

💡 Key Takeaways

Here’s what stood out the most:

AI doesn’t replace engineers — it amplifies structured thinking
Clear documentation is now a core engineering skill
DevOps is evolving into AI-assisted system design
Security and guardrails are more important than ever
The future is not just automation — it’s intelligent automation

🔮 Final Thoughts

We’re entering a new phase of software engineering.

One where:

You don’t just write code
You define rules, context, and intent
And AI helps execute within those boundaries

Learning how to guide AI effectively is becoming just as important as learning how to code.

And for me, this course was the starting point of that journey.

🙌 Acknowledgment

Big thanks to Pravin Mishra for creating such a practical and forward-thinking course on Agentic DevOps.

📌 What’s Next?

I’m continuing to explore:

Advanced Terraform automation
AI-driven infrastructure management
Scalable cloud architectures

If you’re also learning DevOps or exploring AI in engineering, let’s connect and grow together 🚀

DMI DevOps Diary #1: From Fork to Pull Request 🚀

Chioma Nwosu — Fri, 30 Jan 2026 23:03:16 +0000

This post kicks off my DevOps Micro Internship (DMI) DevOps Diary — a series where I document my hands-on journey learning how real DevOps teams work in production-style environments.

I’m starting with something foundational but often misunderstood open-source collaboration using Git and GitHub.
What this first entry is about
For this assignment, I didn’t build a feature or deploy an app. Instead, I focused on process— the same workflow engineers use daily when collaborating on shared codebases.

Here’s what I worked through:

Forked an upstream repository (no direct write access)
Cloned my fork locally
Configured origin (my fork) and upstream (original repo)
Created a feature branch instead of working on main
Made a single, scoped documentation change
Synced with upstream to avoid conflicts
Opened a Pull Request back to upstream

Small change. Real workflow.

Why these matters in DevOps

From a DevOps perspective, this wasn’t just about Git commands — it was about risk reduction and system safety:

Forks protect shared repositories
Feature branches isolate changes
Clean commits simplify reviews
Pull Requests enforce accountability

These same principles show up later in infrastructure-as-code, CI/CD pipelines, and production deployments.

What I learned

Open-source contribution is structured and repeatable
Collaboration skills are as important as technical skills
Clean Git history is a professional signal, not a nice-to-have

What’s coming next in the series

This assignment lays the groundwork for what’s next in DMI:
automation, deployment workflows, and production-level DevOps practices.

Each diary entry will build on the last — moving from how teams collaborate to how systems are deployed, monitored, and maintained.

🔗 GitHub fork for this entry:
https://github.com/Treasurematrix/devops-micro-internship-interviews

📖 Full walkthrough with screenshots:

https://medium.com/@chiomanwosu2019/from-fork-to-pull-request-my-first-open-source-contribution-dmi-249fc80b4652

# ☁️ Creating a Highly Available Environment on AWS (Multi-AZ Architecture)

Chioma Nwosu — Fri, 31 Oct 2025 20:23:58 +0000

Building applications that stay online during failures is a critical skill for any cloud engineer. In this hands-on project from the AWS Academy Cloud Architecting programme, I redesigned a simple, single-instance setup into a fault-tolerant, highly available (HA) architecture running across multiple AWS Availability Zones.

This post breaks down the core components, how they work together, and what I learned along the way.

✅ What I Built

The goal was to transform a basic application into a multi-tier, multi-AZ architecture capable of surviving instance or Availability Zone failures.

The final environment included:

VPC with public & private subnets
Application Load Balancer (ALB) using two AZs
Auto Scaling Group running EC2 instances across private subnets
Amazon RDS (Multi-AZ) MySQL database
NAT Gateways for secure outbound access
Security Groups forming a strict 3-tier model
CloudWatch for health checks and monitoring

This setup follows AWS best practices for reliability and security.

✅ Key Architecture Components

1. Application Load Balancer (ALB)

The ALB distributes traffic evenly across instances and performs continuous health checks.
If an instance becomes unhealthy, the ALB automatically routes traffic to healthy ones.

2. EC2 Auto Scaling Group

I created an AMI of the base web server and used it in a launch template.
The ASG maintains two instances at all times and replaces failed ones automatically — creating a self-healing system.

3. RDS Multi-AZ

Amazon RDS was upgraded to a Multi-AZ setup to provide automated failover.
If the primary database fails, traffic is redirected to a standby instance seamlessly.

4. Networking & Security

The architecture uses:

Public subnets → Load Balancer
Private subnets → EC2 application servers
Private DB subnets → RDS instance
NAT Gateways → Secure outbound traffic

Security groups enforce strict “layer-to-layer” communication:

ALB → App layer
App layer → DB layer

✅ Testing High Availability

The most exciting part was intentionally terminating one of the EC2 instances to simulate a failure.

Here’s what happened:

✔️ The ALB stopped routing traffic to the failed instance
✔️ The application stayed online with zero downtime
✔️ Auto Scaling launched a replacement automatically

This confirmed the architecture was functioning exactly as a real HA system should.

✅ What I Learned

How to design for failure, resilience, and redundancy
Importance of Multi-AZ deployments
How Auto Scaling + ALB creates a self-healing system
Building secure VPC environments with tiered security groups
Using CloudWatch for monitoring and health checks
Applying AWS Well-Architected Framework best practices

✅ Final Thoughts

This project showed me how enterprise-grade cloud systems are designed — not just to run, but to keep running even when things break.

I’m excited to keep building more AWS and DevOps projects that focus on reliability, automation, and scalability.

If you're also learning AWS or working on cloud architecture, I’d love to connect!

When AWS Went Down: Lessons in Cloud Resilience from the Real World

Chioma Nwosu — Tue, 21 Oct 2025 20:37:06 +0000

When AWS experienced a global outage, it disrupted more than cloud services — it disrupted learning. As an ALX AWS Cloud Architect observer, I watched how the outage impacted Vocareum labs and brought cloud resilience principles to life. Here’s what it taught us about designing for failure, recovery, and real-world reliability.

On October 20th, 2025, something strange happened — AWS went dark.

At first, it felt like a typical hiccup. But soon, messages started pouring in across the ALX Cloud Architect community:

“My Vocareum lab won’t load.”
“EC2 console is just spinning.”
“Is it my internet or AWS again?”

It wasn’t just one of us. It was everyone.

The Ripple Effect

The outage didn’t just stall projects — it became a live case study. Students running hands-on labs couldn’t deploy instances, monitor workloads, or test automation pipelines. For many, it was frustrating. For others, it was a wake-up call about the fragility of even the biggest systems we rely on.

And that’s when it hit me: this is what cloud architecture is really about.
It’s not about the flawless uptime we dream of — it’s about designing systems that can bend without breaking.

Lessons Reinforced

From the chaos came clarity. Every principle I’d studied in my ALX Cloud Architect track suddenly had real weight:

High Availability isn’t just a term — it’s your safety net.

Multi-Region Design matters because failures do happen.

Monitoring and Alerts aren’t optional — they’re your early warning system.

Fault Tolerance isn’t about preventing crashes; it’s about recovering fast when they happen.

It was one of those moments where the theory became alive.

The Way Forward

After the dust settled, I found myself more inspired than frustrated. If AWS — the gold standard of reliability — can stumble, it only proves that no system is perfect.

As cloud professionals in training, our mission isn’t to eliminate outages.
It’s to prepare for them.
To design better.
To learn continuously.

And maybe next time an outage strikes, we’ll be the ones explaining why it happened — and how to prevent it from taking everything down.

🔐 Hands-On with AWS IAM: Users, Groups, and Policies in Action

Chioma Nwosu — Sat, 30 Aug 2025 03:02:34 +0000

Cloud platforms are powerful, but with great power comes great responsibility — especially when it comes to 'who has access to what'. Recently, I completed a guided lab on "AWS Identity and Access Management (IAM)", and I want to share what I learned with other builders in the community.

🌍 Why IAM Matters

IAM is AWS’s way of managing identities (users) and their permissions.

Users by default have no access.
Permissions are granted through policies.
Groups make it easier to assign policies to multiple users at once.

This lab reinforced the 'principle of least privilege' — always give just enough permissions to get the job done.

🛠 Lab Breakdown

The lab gave me:

*3 users: user-1, user-2, user-3
*3 groups:

S3-Support → AmazonS3ReadOnlyAccess (managed policy)
EC2-Support → AmazonEC2ReadOnlyAccess (managed policy)
EC2-Admin → Custom inline policy

Here’s an example of the inline policy for EC2-Admin:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
]
}

This policy allows admins to view, start, and stop EC2 instances.

👥 Assigning Users to Roles

I assigned each user based on their job function:

user-1 → S3-Support (read-only S3 access)
user-2 → EC2-Support (read-only EC2 access)
user-3 → EC2-Admin (can start/stop EC2 instances)

🔑 Testing Permissions

This was the fun part — logging in as each user via the IAM sign-in URL.

user-1: Could browse S3 buckets ✅ but denied in EC2 ❌
user-2: Could view EC2 instances ✅ but couldn’t stop them ❌, no S3 access ❌
user-3: Could view/start/stop EC2 ✅

Seeing the difference in permissions really drove home how IAM boundaries work.

💡 Key Takeaways

Start with zero access – AWS gives nothing until you explicitly allow it.
Groups > Direct permissions – Easier to scale as teams grow.
Managed vs Inline Policies – Managed = reusable; Inline = custom-fit.
Always test – what’s in the JSON doesn’t always feel real until you log in as the user.
Least Privilege is real – This isn’t just theory; IAM enforces it strictly.

🚀 Why It Matters for Devs

As developers, we often focus on building apps and services. But in the cloud, 'who has permission to deploy, read, or stop resources' can make or break a system.

This lab reminded me that IAM isn’t “just an admin’s job” — developers need to understand it too, especially if you’re working in teams or deploying production workloads.

✅ Final Thoughts

This IAM lab was a practical way to see how access control works in AWS. Instead of reading docs, I actually lived through what happens when users have too much, too little, or just the right amount of access.

👉 Question for the DEV community:
Do you usually stick with AWS managed policies for simplicity, or do you create custom inline policies for fine-grained control?

If you found this useful, follow me here on DEV — I’ll be sharing more hands-on AWS learning journeys.

#AWS #Cloud #IAM #Security #DevOps