Forem: jaydeep gohel

24 AWS Architecture Blueprints for Building Scalable Cloud Systems

jaydeep gohel — Sat, 07 Feb 2026 16:02:52 +0000

What if you could skip years of trial and error and just copy the patterns that work?

That's exactly it changed everything.

The "Aha" Moment

Picture this: You're staring at a blank AWS console, coffee in hand, deadline looming. The possibilities are endless, but so is the confusion. Serverless? Containers? Multi-account? Zero trust?

We've all been there.
I used to think every cloud problem needed a custom solution. I was wrong.

The Hidden Treasure

This [ repository post ] contains 24 battle-ready AWS architectures. Not theory. Not blog posts. Real, production-ready patterns with Terraform code.

But here's the thing that blew my mind:

These aren't just random architectures. They're mapped to specific industries.

Financial services? There's a pattern for that.

Healthcare? Got you covered.

Manufacturing, retail, public sector, media, transportation, education — every industry has its own blueprint.

Let's Play a Game

Quick question: What industry do you work in?

Financial Services
Healthcare
Retail
Manufacturing
Technology & SaaS
Public Sector
Telecommunications
Media & Entertainment
Transportation & Logistics
Education

Pause and think about it for a second.

Because whatever you picked, there's a curated list of architectures designed specifically for your compliance requirements, security needs, and use cases.

The Architecture That Started It All

Let me tell you about Architecture #01: Serverless.

It's deceptively simple:

[Users] → [Route 53] → [CloudFront] → [API Gateway]
                                              ↓
                                          [Lambda Functions]
                                              ↓
                                    +----------+----------+
                                    |                     |
                               [DynamoDB]          [EventBridge]

No servers to manage. You only pay for what you use. It scales automatically.

But here's what nobody tells you:

Serverless has trade-offs. Cold starts. Execution time limits. Vendor lock-in.

Question for you: Have you ever hit a cold start in production? How did you handle it?

The "Choose Your Fighter" Dilemma

Here's where it gets interesting. The repository doesn't just give you one option. It gives you three ways to run containers:

ECS Fargate — Serverless containers, no EC2 management
EKS Microservices — Full Kubernetes, maximum control
EC2 Auto Scaling — Traditional, predictable, steady-state

Think about this: Which one would you choose for a startup with unpredictable traffic? What about an enterprise with strict compliance requirements?

Try this: Map each option to a scenario where it shines. Now map it to a scenario where it would be a disaster.

The Security Revolution

I need to talk about Architecture #11: Zero Trust.

The old way: Build a castle with a moat. If you're inside, you're trusted.

The new way: Never trust, always verify.

Every single request. Every single time.

[User/Device]
      ↓
[Identity Provider] → Auth & Context Check
      ↓
[Verified Session]
      ↓
[Service A] --(mTLS)--> [Service B]

Question: When was the last time you audited who has access to what in your AWS accounts?

The Multi-Account Mindset

Here's something that took me years to understand:

Single account AWS deployments are like living in a house without walls.

Architecture #07 shows you how to structure accounts properly:

[AWS Organizations (Root)]
           ↓
    +-------+-------+-------+
    |       |       |       |
[Security][Shared][Workload A][Workload B]

Why does this matter?

Blast radius reduction (one compromised account doesn't take everything)
Clear billing separation
Different security boundaries per team

Pause and think: How many AWS accounts does your organization have? If it's one, you might want to reconsider.

The Database Dilemma

Pick your poison:

Architecture	Best For	Trade-off
RDS	Traditional apps	Vertical scaling only
Aurora Serverless	Variable workloads	Higher cost at scale
DynamoDB	Massive scale	Limited query flexibility

Real talk: I've seen teams pick the wrong database and spend months migrating later.

Question: What's the biggest database mistake you've made or seen?

The Industry Mapping That Changed Everything

This is the feature that made me save this repository immediately.

Every architecture is mapped to industries with:

Key use cases
Recommended architectures
Compliance requirements

Example: Financial Services

PCI-DSS, SOX, GDPR compliance
Real-time transaction processing
Fraud detection
Multi-region active/active for global availability

Example: Healthcare

HIPAA, HITECH compliance
Patient data protection
Zero trust architecture
Disaster recovery for patient safety

Think about this: What compliance nightmares keep you up at night? This repository has patterns to address them.

The Terraform Goldmine

Here's the kicker: Every architecture comes with Terraform code.

Not just snippets. Complete, working infrastructure as code.

terraform/
├── 01-serverless-architecture/
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
│   └── app/
│       └── main.py
├── 02-ecs-fargate-architecture/
├── 03-eks-microservices-architecture/
└── ... (24 total)

Try this: Pick one architecture and actually deploy it. See how it works. Modify it. Break it. Learn from it.

The Complexity Spectrum

Not all architectures are created equal:

Architecture	Complexity	When to Use
Static Website	⭐	Marketing sites, docs
Serverless	⭐⭐	APIs, event-driven
ECS Fargate	⭐⭐⭐	Microservices
EKS	⭐⭐⭐⭐	Complex K8s workloads
Multi-region Active/Active	⭐⭐⭐⭐⭐	Mission-critical global apps

Question: Are you over-engineering? Or under-engineering? Be honest.

The Disaster Recovery Wake-Up Call

Architecture #24: Disaster Recovery.

Here's the uncomfortable truth: Most companies don't think about DR until it's too late.

This repository shows you:

Backup strategies
Multi-region failover
RTO/RPO considerations
Testing procedures

Pause and think: If your primary region went down right now, how long would it take to recover? Do you even know?

The Streaming Revolution

Architecture #17: Kinesis Streaming.

Real-time data is the new normal. Clickstreams. IoT telemetry. Log aggregation. Financial transactions.

Kinesis makes it possible:

[Data Sources] → [Kinesis Streams] → [Processing] → [Storage/Analytics]

Question: What real-time data are you missing out on because you don't have a streaming architecture?

The Machine Learning Infrastructure

Architecture #20: Machine Learning.

It's not just about models. It's about the infrastructure to:

Train models at scale
Serve predictions with low latency
Monitor model performance
Retrain continuously

Think about this: Your ML model is only as good as the infrastructure that runs it.

The Event-Driven Paradigm

Architecture #18: Event-Driven.

This is how modern systems communicate:

[Service A] → [EventBridge] → [Service B]
                          → [Service C]
                          → [Service D]

Loose coupling. Asynchronous processing. Natural scalability.

Question: How many tightly coupled integrations are you maintaining that should be event-driven?

The IoT Explosion

Architecture #19: IoT.

Smart homes. Industrial telemetry. Fleet management. Connected devices everywhere.

The pattern is consistent:

[Devices] → [IoT Core] → [Kinesis] → [Processing] → [Storage/ML]

Think about this: What could you build if you had a reliable IoT infrastructure pattern ready to deploy?

The Data Lake Foundation

Architecture #21: Data Lake.

All your data. One place. Queryable.

Raw data lands here
Gets transformed
Becomes analytics-ready
Feeds ML models

Question: How much time do your data scientists spend just getting access to data?

The Transit Gateway Game-Changer

Architecture #09: Transit Gateway.

If you have more than 10 VPCs, you need this.

    [VPC A]      [VPC B]
         \          /
          \        /
       [Transit Gateway]
          /        \
         /          \
    [VPC C]      [VPN/DX]

The old way: VPC peering mesh (n² complexity).

The new way: Hub-and-spoke (linear complexity).

Pause and think: How many VPCs do you have? How are they connected?

The Direct Connect Decision

Architecture #10: Direct Connect.

When internet connectivity isn't enough:

Consistent performance
Lower bandwidth costs at scale
Private, secure connection

Question: Are you paying for internet data transfer that should be on Direct Connect?

The Load Balancer Trinity

Three load balancers, three purposes:

Load Balancer	Layer	Best For
ALB	7 (HTTP/S)	Web apps, API routing
NLB	4 (TCP/UDP)	Gaming, IoT, high performance
GWLB	3 (Network)	Firewalls, appliances

Question: Are you using the right load balancer for your workload?

The Identity Foundation

Architecture #12: Identity.

Centralized authentication. Single sign-on. Least privilege.

[User] → [IAM Identity Center] → [Account A/Account B/Account C]

Real talk: Identity is the new perimeter. Get this wrong, and nothing else matters.

The Security Hub

Architecture #22: CloudTrail + Security Hub.

Compliance monitoring. Threat detection. Audit trails.

Every regulated industry needs this.

Question: When was the last time you reviewed your CloudTrail logs?

What I Learned From 24 Architectures

After going through all of them, here's what stuck:

Start simple. VPC + Identity first.
Security isn't optional. Zero trust from day one.
Compliance is easier when you design for it.
Multi-account isn't just for enterprises.
Disaster recovery is non-negotiable.
Serverless isn't always the answer.
Containers aren't always the answer.
There's no perfect architecture. Only trade-offs.

Your Turn

I have three challenges for you:

Pick one architecture from this repository that you've never used. Deploy it. Break it. Learn it.
Map your current infrastructure to the patterns here. What are you missing? What are you over-engineering?
Share your experience. Which architecture resonated with you? Which one confused you? What did you learn?

The Bottom Line

This repository isn't just documentation. It's a shortcut to wisdom that usually takes years to acquire.

24 architectures. 10 industries. Complete Terraform code.

The patterns are there. The code is there. The only missing piece is you.

What will you build?

If you found this valuable, save it for later. Share it with your team. And most importantly — actually use one of these architectures. Reading about cloud architecture is easy. Building it is where the real learning happens.

[ Blog Post of Repository ]

☕ Send coffee

Don't Like my work : Feedback in comment section.

This article was written with the small help of AI.

One Dockerfile to Rule Them All: Building a DevSecOps Container You'll Actually Love

jaydeep gohel — Sun, 26 Oct 2025 12:58:14 +0000

The Problem Every DevOps Engineer Knows Too Well

It's 3 AM. You're debugging a Kubernetes issue in production. You SSH into your jump box and... kubectl isn't installed. Fine, you install it. But wait, you also need helm. And kubectx. Oh, and that security scanner your manager asked about three sprints ago.

Two hours later, you've got 23 tabs open about installing tools, half of them conflict with each other, and you're Googling "how to uninstall everything and start over" while questioning your career choices.

I've been there. We've all been there.

So one weekend, fueled by frustration and probably too much coffee, I decided to build something different: a single Docker container with every DevSecOps tool I'd ever need. Not just the basics—I'm talking everything. Kubernetes? Check. Security scanning? Triple check. Infrastructure as Code? You bet. Cost optimization tools? Why not!

What started as a simple "let me automate my setup" project turned into a 475-line Dockerfile odyssey, 130+ tools, and more debugging adventures than I'd like to admit.

This is that story.

🎯 The Idea: One Container to Rule Them All

Here's the thing about DevSecOps: the tools are amazing, but managing them is a nightmare.

You've got:

🛡️ Security scanners (Trivy, Kubescape, Grype, oh my!)
☸️ Kubernetes tools (kubectl, helm, k9s, kustomize, and 20 plugins you forgot you installed)
🏗️ Infrastructure as Code (Terraform, but also OpenTofu now because licensing, plus Terragrunt, plus Ansible...)
🔄 GitOps platforms (ArgoCD? Flux? Why not both!)
☁️ Cloud CLIs (AWS, GCP, Azure—because of course you support all three)

And that's just scratching the surface.

GitHub and Docker Hub links at the end of this article

My vision was simple: A single Docker container that has everything. No more "let me install this real quick." No more dependency hell. No more "it works on my machine" (because my machine is now a container).

💡 Key Philosophy: If Batman can have a utility belt with gadgets for every situation, why can't we have a container with tools for every DevOps situation?

🏔️ Why Alpine? (Or: How I Learned to Love Minimalism)

Let me tell you about my first attempt: Ubuntu.

The Dockerfile worked great! The image size? 23GB.

Eight. Gigabytes.

For a tools container.

That's when Alpine Linux entered the chat. At ~5MB base image size, Alpine is like Marie Kondo for containers—ruthlessly minimal, sparking joy through sheer efficiency.

FROM alpine:3.20

# That's it. That's the base. 5MB of pure minimalist beauty.

The Good:

⚡ Lightning-fast pulls
🎯 Minimal attack surface (security team loved this)
📦 Small layer sizes

The "Character Building Moments":

Uses BusyBox (no GNU tools by default)
Missing libraries you thought were "standard"
apk instead of apt (not hard, just different)

But here's the thing: those constraints make you better. You learn what tools actually need versus what they're just used to having. It's like moving to a tiny house—you discover you didn't need 90% of your stuff anyway.

# Install base utilities - this took longer than I'd like to admit
RUN apk add --no-cache \
    bash \
    curl \
    wget \
    git \
    jq \
    vim \
    # ... and about 30 more carefully chosen tools

The --no-cache flag? That's Alpine's way of saying "we don't keep unnecessary package indexes around." This alone saves hundreds of megabytes.

🛠️ Building the Toolbox: Where Things Got Interesting

Stage 1: The Kubernetes Essentials

Everyone needs kubectl. That's not controversial. But here's where it gets fun:

# Install kubectl - latest version, dynamically fetched
RUN KUBECTL_VERSION=$(curl -L -s https://dl.k8s.io/release/stable.txt) && \
    curl -LO "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl" && \
    install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl && \
    rm kubectl

Translation: "Dear GitHub API, what's the latest version? Cool, download that. Thanks."

This pattern became my best friend. Instead of hardcoding versions (which become outdated in 3 days), I fetch the latest. Sure, it makes builds slightly slower, but your tools are always current.

Then came the plugins. Oh, the plugins.

# kubectx and kubens - because typing is overrated
RUN KUBECTX_VERSION=$(curl -s https://api.github.com/repos/ahmetb/kubectx/releases/latest | \
    sed -n 's/.*"tag_name": "v\([0-9.]*\)".*/\1/p') && \
    wget https://github.com/ahmetb/kubectx/releases/download/v${KUBECTX_VERSION}/kubectx_v${KUBECTX_VERSION}_linux_x86_64.tar.gz && \
    tar -xzvf kubectx*.tar.gz && \
    mv kubectx /usr/local/bin/ && \
    rm kubectx*.tar.gz

If you've ever typed kubectl config use-context production-cluster-us-east-1-k8s-cluster more than once, you understand why kubectx exists.

Stage 2: The Security Battalion

This is where I went a bit overboard. In a good way.

# Trivy - because vulnerabilities don't scan themselves
RUN TRIVY_VERSION=$(curl -s https://api.github.com/repos/aquasecurity/trivy/releases/latest | \
    sed -n 's/.*"tag_name": "\([^"]*\)".*/\1/p') && \
    curl -LO "https://github.com/aquasecurity/trivy/releases/download/${TRIVY_VERSION}/trivy_${TRIVY_VERSION#v}_Linux-64bit.tar.gz" && \
    tar -xvzf trivy*.tar.gz -C /usr/local/bin && \
    rm trivy*.tar.gz

# Kubescape - CNCF's gift to security teams
RUN curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Grype, Syft, Docker Scout... the gang's all here

I ended up with 18 different security tools.

Is that excessive? Maybe.

But have you ever been in a meeting where someone asks "Can we scan for X?" and you can confidently say "Already got three tools for that"?

Chef's kiss.

Stage 3: Infrastructure as Code (Or: The Terraform Saga)

Terraform installation looks simple:

RUN TF_VERSION=$(curl -s https://checkpoint-api.hashicorp.com/v1/check/terraform | \
    jq -r .current_version | sed 's/^v//') && \
    wget "https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip" && \
    unzip terraform.zip && \
    mv terraform /usr/local/bin/ && \
    rm terraform.zip

Then HashiCorp changed their license. The community forked it into OpenTofu. So now we have:

# OpenTofu - because open source matters
RUN OPENTOFU_VERSION=$(curl -s https://api.github.com/repos/opentofu/opentofu/releases/latest | \
    grep tag_name | cut -d '"' -f 4 | sed 's/^v//') && \
    wget "https://github.com/opentofu/opentofu/releases/download/v${OPENTOFU_VERSION}/tofu_${OPENTOFU_VERSION}_linux_amd64.zip" && \
    unzip tofu.zip && \
    mv tofu /usr/local/bin/ && \
    rm tofu.zip

Both Terraform and OpenTofu. Because flexibility.

Then I added Terragrunt (for the overachievers), tflint (for the perfectionists), terraform-docs (for the documenters), and tfsec (for the security conscious).

At this point, my IaC tooling alone could deploy infrastructure on Mars.

🐛 The Debugging Chronicles: A Comedy in Three Acts

Act 1: The BusyBox Awakening

RUN grep -P "something" file.txt
# grep: invalid option -- P

Me: "What do you mean invalid option? -P is standard!"

Alpine: "Not in BusyBox, buddy."

BusyBox implements common Unix utilities but with fewer options. Perl-compatible regex (-P)? Not supported. Extended regex (-E)? Also no.

Solution: Install grep from GNU coreutils, or rewrite my patterns. I chose option B and learned to love basic regex again. Character development!

Act 2: The gzip Mystery

RUN tar -xzf tool.tar.gz
# gzip: invalid magic

This error message haunted my dreams. "Invalid magic"—like I was casting the wrong spell.

After hours of debugging, the culprit? Partial downloads. The network connection kept timing out, leaving me with corrupted archives.

Solution: Added retry logic and hash verification:

RUN wget --tries=3 --timeout=30 https://example.com/tool.tar.gz && \
    sha256sum tool.tar.gz  # Verify it's not cursed

Act 3: The GitHub API Null Saga

TOOL_VERSION=$(curl -s https://api.github.com/repos/owner/tool/releases/latest | jq -r .tag_name)
# Version: null

GitHub's API rate limit hit me like a brick wall. Without authentication, you get 60 requests per hour. My Dockerfile had 50+ tools using this pattern.

Solution: Batch the API calls and add fallbacks:

# Use cached version as fallback
RUN TOOL_VERSION=$(curl -s https://api.github.com/repos/owner/tool/releases/latest | \
    jq -r .tag_name || echo "v1.0.0") && \
    # ... rest of installation

Also, building at 3 AM when API rates reset helps. Not that I did that. Multiple times.

🎨 The Final Touches: Organization is Everything

Here's a secret: the organization matters more than the tools.

I split the Dockerfile into 21 logical stages:

STAGE 1:  Environment Setup
STAGE 2:  Base System Packages
STAGE 3:  Networking & Diagnostics
STAGE 4:  Programming Languages
STAGE 5:  Cloud CLI Tools
STAGE 6:  Container & Orchestration
STAGE 7:  Kubectl Plugins
STAGE 8:  Infrastructure as Code
STAGE 9:  Service Mesh Tools
STAGE 10: GitOps & CI/CD
...and 11 more

Each stage is clearly commented, explaining why each tool exists and what it does.

################################################################################
# STAGE 6: CONTAINER & ORCHESTRATION TOOLS
################################################################################
# Purpose: Everything you need to build, run, and manage containers
# Includes: Docker CLI, kubectl, helm, k9s, kind
################################################################################

This isn't just for others reading the Dockerfile—it's for future me. When I come back in 6 months wondering "why did I install this?", clear comments save the day.

The Developer Experience Layer

I also added quality-of-life tools that don't technically fit "DevSecOps" but make daily work so much better:

# lazygit - because Git UIs are nice actually
# bat - cat but with syntax highlighting and line numbers
# fzf - fuzzy finder that will change your life
# httpie - curl's friendlier cousin

These tools transform the container from "functional" to "actually enjoyable to use."

🎁 The Big Reveal: What's Actually In This Thing?

Let me give you the highlight reel of the 130+ tools packed into this container:

☸️ Kubernetes (25+ tools)

kubectl, helm, k9s (the TUI you never knew you needed)
kubectx, kubens (context switching made human)
stern (multi-pod logs), popeye (cluster linter)
skaffold (local development magic)

🛡️ Security (18 tools)

trivy, grype, syft (the CVE hunting trio)
kubescape, kube-bench (Kubernetes hardening)
checkov, tfsec, terrascan (IaC security)
snyk, falco (because paranoia is good)

🏗️ Infrastructure (10 tools)

terraform + opentofu (choose your fighter)
terragrunt (for the truly ambitious)
ansible (the original cool kid)
pulumi (modern IaC with real code)

🔄 GitOps (5 tools)

argocd, flux (declarative everything)
tekton (cloud-native pipelines)
gh, glab (GitHub/GitLab from CLI)

🔐 Secrets (4 tools)

sops, age (encrypt all the things)
vault, kubeseal (production-grade secrets)

💰 Cost Optimization (2 tools)

kubecost (know where money goes)
infracost (Terraform cost estimation)

Plus: Service mesh tools (Istio, Linkerd, Cilium), cloud CLIs (AWS, GCP, Azure), database clients, linters, performance testing tools, and a whole developer experience suite.

📦 Container Stats:

Base: Alpine Linux 3.20 (~5MB)

Final Size: ~15-16GB (yes still humongous, with 130+ tools)

Build Time: ~15-30 minutes (based on your hardware + internet conncetion)

Time Saved: Countless hours

🔗 Want to Try It Yourself?

The full Dockerfile, complete with all 130+ tools, comprehensive documentation, and even an automated build script with security scanning, is available on GitHub:

👉 GITHUB LINK HERE
🐳 Direct Docker Hub Image - docker pull erjaydeepgohel/devsecops-toolkit:main

What you'll find in the repo:

✅ Complete Dockerfile with detailed comments
✅ Build script with security scanning
✅ Docker Compose setup
✅ 3400+ lines of documentation
✅ Cheat sheet with all commands

To get started:

# Clone the repo
git clone [GITHUB LINK HERE]

# Build it (automated with security scans)
./build.sh

# Run it
docker-compose run --rm devsecops bash

# Marvel at your new superpowers
kubectl version
terraform version
trivy --version
# ... try all 130+ tools!

🎓 What I Learned (Besides Patience)

1. Dynamic Version Fetching is Worth It

Yes, it makes builds slower. But having kubectl 1.28 when 1.30 is out feels wrong. Always fetch latest.

2. Organization Beats Cleverness

A well-organized 500-line Dockerfile beats a "clever" 50-line one that nobody understands.

3. Constraints Make You Better

Alpine's limitations forced me to think carefully about each tool. Every megabyte mattered. This discipline creates better containers.

4. Documentation is a Love Letter to Future You

When you return to your Dockerfile 6 months later, clear comments are the difference between "oh right!" and "what was I thinking?!"

5. Developer Experience Matters

Tools like fzf, bat, and lazygit aren't "necessary," but they transform a container from tolerable to delightful.

🚀 What's Next?

This container is solid, but there's always room for improvement:

Future Ideas:

🤖 Add AI/ML tools (k8sgpt, kubectl-ai)
📊 More observability (Grafana Loki CLI, Tempo)
🔒 Extended security (OPA Gatekeeper, Kyverno policies)
⚡ Performance tools (eBPF utilities, perf)
🌐 Multi-architecture builds (ARM64 support)

The Real Magic:

You can fork this and make it yours. Need different tools? Change the Dockerfile. Want to remove stuff? Easy. Need to add your company's custom tools? Go for it.

💡 Pro Tip: Use this as a template for your own "DevOps Swiss Army Knife." The structure and patterns are designed to be extended.

🎬 The TL;DR

I spent way too much time building a Docker container with 130+ DevSecOps tools so you don't have to. It's based on Alpine Linux, includes everything from Kubernetes tools to security scanners to cost optimization platforms, and comes with 3400+ lines of documentation because I believe in doing things right.

Is it overkill? Definitely.

Is it awesome? Absolutely.

Will it save you hours of setup time? Definitely.

Would I do it again? Already planning v2.

If you've ever found yourself installing the same tools repeatedly, or if you've ever thought "there has to be a better way," this container is for you.

Give it a try. Break it. Improve it. Make it yours. That's what open source is all about.

And hey, if you build something cool with it, let me know! I'm always excited to see what the community creates.

Happy containerizing! 🐳✨

P.S. — If you enjoyed this journey through Dockerfile hell and back, give the repo a star ⭐ on GitHub. It feeds my developer ego and helps others discover it. Also, follow me here on for more DevSecOps adventures, tales from the terminal, and the occasional "I spent a weekend automating something that takes 5 minutes manually" story.

About the Author:
A DevSecOps Consultant with a slight obsession with automation. Currently explaining why our tools container needs 130+ applications when “kubectl and vim would be enough.”

Like my work : ☕ Send coffee and GitHub stars.

Don’t Like my work : Feedback in comment section.

This article was written with the small help of AI.