Most people trying to break into cloud are stuck in an endless loop.

They watch tutorials. They collect certifications. They spin up a Lambda function, follow along with a YouTube video, tear it down, and call it “experience.”

Then they apply to 50, 100, maybe 200 jobs, and hear nothing back.

Here’s the uncomfortable truth: the market doesn’t reward what you know. It rewards what you can prove.

Right now, thousands of professionals who want to switch to cloud careers are competing for the same roles with the same certifications, the same generic resumes, and zero evidence that they can build anything real.

The ones who break through do something different. They follow a system.

In this article, we’ll dive into that system, which consists of four steps.

Step 1: Build Real-World Cloud Projects

Not toy examples. Not tutorial clones.

Build production-style projects using industry best practices, the kind you can confidently walk through in an interview without breaking eye contact.

That means proper architecture. Infrastructure as Code. CI/CD pipelines. Monitoring. Cost awareness. Security considerations. The full picture.

When an interviewer asks, “Tell me about something you’ve built,” you should have a project so solid that your biggest challenge is deciding which part to talk about first.

Step 2: Turn Those Projects Into a Recruiter-Ready Portfolio

Building is only half the battle. If nobody can find your work, it doesn’t exist.

Instead, showcase your projects properly. Upload clean, well-documented code to GitHub with strong READMEs. Write blog posts explaining your architecture decisions and trade-offs.

I’ve seen candidates with mediocre projects outperform stronger builders simply because their work was visible and well presented.

Also, optimize your LinkedIn profile. Treat it like a landing page, not a digital CV. Use a clear headline that states what you do and who you help. Post consistently about what you’re building and learning. Recruiters search LinkedIn daily, so make sure they find you.

Step 3: Get Visible and Secure Interviews

You can’t get hired from the shadows. Network with intent.

Engage on LinkedIn, join cloud communities, and attend local meetups.

But don’t just lurk. Comment on posts with genuine insights, share your learnings publicly, and connect with people doing the work you want to do.

I’ve seen more opportunities come from a single thoughtful comment than from hundreds of cold applications.

Showcase your projects publicly. Talk about what you’re building, what broke, and what you learned.

This isn’t bragging, it’s signaling.

You’re telling the market: “I’m here, I’m building, and I’m serious.”

The interviews will come. Not from luck, but from visibility.

Step 4: Prepare for and Master Interviews

Getting the interview isn’t the finish line. It’s the starting line.

Practice explaining your architecture decisions, trade-offs, and problem-solving approach until it becomes second nature.

Know why you chose DynamoDB over RDS. Know what you’d change if requirements shifted. Know how you’d scale under pressure.

Walk in confident, not guessing.

The candidates who land offers aren’t always the most technically brilliant. They’re the ones who communicate clearly, own their decisions, and show they think like engineers who ship to production.

The Problem With Doing This Alone

You already know what you need to do. The steps above aren’t a secret.

But knowing and executing are two different things.

Most people get stuck between Step 1 and Step 2 — building projects that aren’t strong enough or never making them visible.

Others network randomly, apply generically, and wonder why nothing lands.

What separates people who break in from people who stay stuck isn’t talent.

It’s having a structured path, accountability, and someone who’s done it before showing you exactly where to focus.

That’s Why I Built the Cloud Career Bootcamp

Over the past six years, I’ve personally guided more than 200 professionals through their transition into cloud careers using this system.

The results have been consistently strong.

People who felt their backgrounds were holding them back successfully landed cloud roles at companies like AWS, J.P. Morgan, Airbnb, Uber, Pfizer, and more.

Career changers who thought it was too late to pivot moved into cloud positions.

Instead of facing constant rejection, they started receiving multiple offers from companies eager to hire them.

Now, I’m putting together a program that walks you through this entire roadmap, step by step, with hands-on guidance, real feedback, and a community of people on the same path.

If you’re serious about breaking into cloud and you’re done spinning your wheels, join the waitlist:

👉 Cloud Career Bootcamp — Join the Free Waitlist Now

Spots will be limited.

Get on the list so you’ll be the first to know when doors open.

You’re running a production workload on AWS. You set up S3, maybe enabled versioning because “best practice,” and moved on. Six months later, your S3 bill is three times what you expected, and you have no idea why.

You’re not alone. S3 pricing is deceptively simple on the surface, but underneath it hides several cost traps that lifecycle policies are supposed to solve. The problem? Most teams either skip lifecycle rules entirely or configure them in ways that barely help.

Let’s talk about what’s silently eating your budget.

The Versioning Tax

Versioning is great for data protection. Every overwrite or delete keeps the old object around, which means you can recover from accidental changes. What nobody emphasizes: every old version is a billable object.

If you’re writing logs, reports, or processed data that gets overwritten frequently, you could be storing 10x or 50x the “visible” data. The S3 console shows you the current objects. The old versions hide underneath, quietly accumulating storage charges.

The fix: Always pair versioning with a lifecycle rule that expires non-current versions. Ask yourself: “Do I really need 90 days of old versions, or would 7 days cover any realistic recovery scenario?”

The Multipart Upload Graveyard

When a large upload fails halfway, the uploaded parts don’t disappear. They sit in your bucket as incomplete multipart uploads, invisible in the console’s normal view, but fully billable.

If you’re running data pipelines, ETL jobs, or any process that writes large objects and occasionally fails, these orphaned parts add up. Some teams discover gigabytes of phantom storage they never knew existed.

The fix: Add a lifecycle rule to abort incomplete multipart uploads after a short window, 7 days is generous for most workloads. Some teams set it to 1 day.

The “I’ll Transition Everything to Glacier” Mistake

A common first move: create a lifecycle rule that transitions all objects to S3 Glacier after 30 days. Sounds sensible, cold storage is cheap.

Here’s what catches people:

• Minimum storage duration charges. Glacier has a 90-day minimum. Delete an object on day 45? You still pay for 90 days.

• Retrieval costs. If your application or downstream process ever needs those objects back, retrieval fees and restore times can surprise you.

• Small object overhead. Glacier adds 32KB of metadata per object. If you’re storing millions of tiny files, the overhead alone can exceed what you’d pay in Standard.

The right question: Before transitioning, map your actual access patterns. If objects are never accessed after 30 days, Glacier Deep Archive might make sense. If they’re occasionally accessed, Infrequent Access (IA) with its simpler retrieval model is a safer bet.

Lifecycle Rules That Don’t Actually Apply

This one is subtle. You create a lifecycle rule, confirm it’s active, and assume it’s working. But lifecycle rules scope by prefix and tags. If your bucket structure changed after you wrote the rule — new prefixes, different naming conventions — your rule might be covering 10% of the bucket while the rest grows unchecked.

The fix: Audit lifecycle rules quarterly. Use S3 Storage Lens to see the actual breakdown of storage classes, current vs. non-current versions, and incomplete multipart uploads across your buckets. If the numbers don’t match your expectations, your rules have gaps.

A Mental Model for Getting This Right

Think of lifecycle policies as a three-layer system:

1. Expiration layer: What can be deleted, and when? Non-current versions, expired delete markers, incomplete uploads.

2. Transition layer: What should move to cheaper storage, and based on what access pattern evidence?

3. Audit layer: How do you verify the rules are actually working as intended?

Most teams only think about layer two and skip layers one and three entirely. That’s where the silent costs hide.

The Takeaway

S3 is not “set and forget.” The defaults are designed for durability, not cost efficiency. If you’re not actively managing object versions, failed uploads, and storage class transitions with lifecycle rules, and validating those rules still match reality, you’re overpaying.

Start with a single bucket. Check its Storage Lens dashboard. You’ll probably find at least one surprise waiting for you.

If you want to break into a cloud role (Cloud Engineer, Cloud Developer, Software Engineer, DevOps, SRE, Solutions Architect, etc.) and you have an interview coming up, understanding cloud architecture is non-negotiable if you want to stand out in interviews.

Most candidates focus on certifications or memorising AWS services, but interviews are designed to test something deeper: how you think about building scalable, reliable, and resilient systems.

In this article, we’ll look at 5 fundamental architectures you should know. Master them, understand the trade-offs behind them, and you’ll stand out for the right reasons.

If you want hands-on practice with these 5 architectures, grab my free PDF, 5 AWS Projects To Get You Hired., featuring 5 real-world AWS projects with architecture diagrams and step-by-step implementation guides.

Download the FREE PDF

1. 3-Tier Architecture

This is the foundation. Frontend, backend, database: three distinct layers, each with a clear responsibility. Simple in concept, but interviewers expect you to go far beyond drawing three boxes on a whiteboard.

Key AWS Services: CloudFront + S3 (frontend), ALB + EC2/ECS with Auto Scaling (backend), RDS Multi-AZ or Aurora (database).

What interviewers expect you to know:

• How to scale each tier independently: stateless backends behind a load balancer, read replicas for database read-heavy workloads.

• Failure scenarios: what happens when an AZ goes down? How does Multi-AZ RDS failover work?

• Caching strategies: ElastiCache between backend and database to reduce latency and DB load.

• The difference between horizontal and vertical scaling, and why horizontal wins at scale.

When discussing this architecture, show that you understand the why behind each layer’s separation, not just the what.

2. Microservices

Breaking a monolith into smaller, independent services sounds clean on paper. In practice, it introduces a whole new category of challenges.

Key AWS Services: ECS or EKS, Lambda.

What interviewers expect you to know:

• Trade-offs vs. monoliths: when the operational overhead isn’t worth it (small teams, early-stage products).

• Data ownership: each service owns its data store. No shared databases.

• How you handle failures across service boundaries: circuit breakers, retries with exponential backoff, timeouts.

• Observability: how do you trace a request that flows through 5 services?

The key insight interviewers look for: you chose microservices because the problem demanded it, not because it was trendy.

3. Serverless

No servers to patch, no infrastructure to manage. You can build entire applications without provisioning a single instance.

Key AWS Services: Lambda, API Gateway.

What interviewers expect you to know:

• Cold starts: what causes them, how to mitigate

• Cost model: pay-per-invocation is cheap at low scale but can surprise you with high-throughput workloads. Know the break-even point vs. containers.

• When NOT to use serverless: long-running processes, workloads needing persistent connections, or latency-critical paths where cold starts are unacceptable.

The interview-winning move is demonstrating that you can evaluate when serverless is the right tool and when it introduces more problems than it solves.

4. Event-Driven Architecture

This is where modern cloud design becomes powerful. Instead of services calling each other directly, they produce and consume events asynchronously. The result: loose coupling, high scalability, and systems that are naturally resilient to spikes in traffic.

Key AWS Services: EventBridge, SNS, SQS.

What interviewers expect you to know:

• The difference between queuing (SQS one consumer) and pub/sub (SNS fan-out to many consumers).

• Eventual consistency: data won’t be immediately up to date across services. You need to explain how your system handles this.

• Idempotency: events can be delivered more than once. Your consumers must handle duplicates gracefully.

• Dead-letter queues: what happens when an event fails processing repeatedly? How do you monitor and replay?

• A real scenario: an order is placed → event fires → inventory, notifications, and analytics services react independently without knowing about each other.

The challenge is showing you can design systems where components don’t need to know about each other but still behave correctly as a whole.

5. Containers

Containers give you consistency across environments and fine-grained control over your runtime. They sit between the full control of EC2 and the abstraction of serverless.

Key AWS Services: ECS, EKS, ECR.

What interviewers expect you to know:

• When containers beat serverless: long-running processes, specific runtime needs, workloads needing persistent connections, or apps being migrated from on-premises.

• When serverless beats containers: short-lived, event-triggered functions with variable traffic.

• Health checks, rolling deployments, and blue/green strategies for zero-downtime updates.

• You don’t need to be a Kubernetes expert. But you should understand pods, services, and why teams choose (or avoid) K8s.

Conclusion

These five architectures cover the vast majority of what you’ll face in cloud interviews. You don’t need to memorise every AWS service. You need to understand patterns, trade-offs, and when to apply each one.

The candidates who stand out are the ones who can explain why they chose an architecture, not just draw it on a board. Show your reasoning. Discuss trade-offs. Acknowledge limitations.

Cloud interviews are rarely about knowing the “correct” AWS service. They’re about proving you can make good engineering decisions under constraints.

If you want hands-on practice with these 5 architectures, grab my free PDF, 5 AWS Projects To Get You Hired., featuring 5 real-world AWS projects with architecture diagrams and step-by-step implementation guides.

Download the FREE PDF

Multi-agent systems are everywhere now. Every team wants autonomous agents collaborating on complex tasks, research, planning, execution, validation. The problem? Orchestrating multiple agents that need to wait on each other, handle failures gracefully, and maintain state across long-running conversations is painful. We’ve been duct-taping this together with Step Functions, SQS queues, and DynamoDB state tables for too long.

Lambda Durable Functions change the game here. In this article we will walk through why durable functions are a natural fit for multi-agent orchestration, design a document processing pipeline with four agents, and show how the architecture holds together without a single line of state management code.

Why Durable Functions for Multi-Agent

Standard Lambda functions run start-to-finish in a single invocation. If something fails midway, you retry everything. For a multi-agent workflow where Agent A researches, Agent B plans, Agent C executes, and Agent D validates. That’s unacceptable. You can’t re-run a 4-minute research phase because the validation agent hit a transient error.

Durable functions automatically checkpoint progress, suspend execution for up to one year during long-running tasks, and recover from failures. No custom state management. No DynamoDB tables tracking “which step are we on.” The runtime handles it.

This is exactly what multi-agent orchestration needs: reliable progress tracking across agents that may take seconds or minutes to respond, with automatic recovery when things go wrong.

The Example: Document Processing Pipeline

Let’s see an example of a document processing pipeline and how we can build it with Lambda durable functions. We have four agents and one durable function orchestrating them. The agents are:

• Classifier Agent — Reads an incoming document, determines its type (invoice, contract, support ticket), and extracts metadata.

• Enrichment Agent — Takes the classification, pulls additional context from internal systems, and augments the document with business context.

• Decision Agent — Evaluates the enriched document against business rules and decides the routing: auto-approve, escalate, or reject.

• Action Agent — Executes the decision: files the document, notifies stakeholders, or triggers downstream workflows.

Architecture

┌─────────────────────────────────────────────────────────────────────────────┐
│                     Lambda Durable Function (Orchestrator)                  │
│                                                                             │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐   │
│  │ Checkpoint 1 │    │ Checkpoint 2 │    │ Checkpoint 3 │    │ Checkpoint 4 │  
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘    └──────┬──────┘   │
│         │                  │                  │                  │          │
│         ▼                  ▼                  ▼                  ▼          │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐   │
│  │  Step 1:    │    │  Step 2:    │    │  Step 3:    │    │  Step 4:    │   │
│  │  Classify   │───▶│  Enrich     │───▶│  Decide     │───▶│  Act        │   │
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘    └──────┬──────┘   │
│         │                  │                  │                  │          │
└─────────┼──────────────────┼──────────────────┼──────────────────┼──────────┘
          │                  │                  │                  │
          ▼                  ▼                  ▼                  ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│  Classifier     │  │  Enrichment     │  │  Decision       │  │  Action         │
│  Agent          │  │  Agent          │  │  Agent          │  │  Agent          │
│  (Lambda)       │  │  (Lambda)       │  │  (Lambda)       │  │  (Lambda)       │
│                 │  │                 │  │                 │  │                 │
│  - Reads doc    │  │  - Pulls context│  │  - Evaluates    │  │  - Files doc    │
│  - Classifies   │  │  - Calls APIs   │  │    rules        │  │  - Notifies     │
│  - Extracts     │  │  - Augments     │  │  - Routes       │  │  - Triggers     │
│    metadata     │  │    metadata     │  │                 │  │    downstream   │
└────────┬────────┘  └────────┬────────┘  └────────┬────────┘  └────────┬────────┘
         │                    │                    │                     │
         ▼                    ▼                    ▼                     ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│  Amazon Bedrock │  │  Internal APIs  │  │  Human Review   │  │  S3 / SNS /     │
│  (LLM)          │  │  (DynamoDB,     │  │  (Callback -    │  │  EventBridge    │
│                 │  │   other svcs)   │  │   Wait/Resume)  │  │                 │
└─────────────────┘  └─────────────────┘  └─────────────────┘  └─────────────────┘

The Flow

The durable function receives a document event. It invokes the Classifier Agent as a durable step and progress is checkpointed. If Lambda recycles the execution environment after classification completes, the function resumes from that checkpoint, not from scratch.

The Classifier’s output feeds into the Enrichment Agent. Another durable step, another checkpoint. The Enrichment Agent might call external APIs that take 30 seconds. The durable function suspends, pays nothing while waiting, and resumes when enrichment completes.

Here’s where it gets interesting. The Decision Agent might determine that a human needs to review this document. The durable function uses a wait where it suspends execution entirely, for hours or days if needed, until a callback arrives with the human’s decision. No polling. No idle compute. The function simply resumes where it left off.

Finally, the Action Agent executes. If it fails, maybe a downstream system is temporarily unavailable, the durable function retries that specific step without re-running classification, enrichment, or decision. Four agents, one orchestration function, zero state management infrastructure.

Why This Beats the Alternative

Before durable functions, this same workflow required: a Step Functions state machine, DynamoDB for intermediate state, SQS queues between agents, dead-letter queues for failures, and CloudWatch alarms for stuck executions. That’s five services to manage for what is conceptually a single workflow.

With durable functions, it’s one Lambda function. Same programming model you already know. Same event handler. Same integrations. The durability is built into the execution model itself.

The Trade-Off

Durable functions use a checkpoint-replay model. Every time execution resumes, it replays from the last checkpoint. This means your orchestration logic must be deterministic, so no random values, no reading the current time for branching decisions outside of durable steps. This is a constraint worth understanding upfront.

For multi-agent workflows specifically, this is rarely a problem. Your orchestration logic is typically: call agent, get result, pass to next agent. That’s inherently deterministic.

When to Reach for This

Multi-agent workflows that involve waiting on humans, on slow external systems, on other agents, are the sweet spot. If your agents all respond in under a second and never fail, you probably don’t need durability. But that’s not the real world.

In the real world, agents call LLMs that timeout, external APIs that rate-limit, and humans that go to lunch. Durable functions handle all of that without you writing a single line of state management logic.

I’ve attended a couple of tech events over the past two weeks, and they reminded me just how much value is sitting right there, if you know how to look for it. Most people show up, sit through sessions, and leave. But the real ROI of a tech event goes well beyond the agenda.

Here’s what I’ve learned about making the most of them.

1. Do Your Research Beforehand

Walking into an event blind is a missed opportunity. Before you even step through the door, check the agenda. Which sessions are actually worth your time? Which workshops align with what you’re working on right now? Who’s speaking, and more importantly, who’s attending?

Identify two or three people you’d genuinely like to connect with. Not just big names, but people whose work you follow, whose problems overlap with yours, or whose perspective you’d find valuable. Having that list in your head changes how you move through the event. You stop wandering and start being intentional.

2. Don’t Just Attend — Connect

This is where most people leave value on the table. They attend the sessions, they clap at the end, and they head to the next room. But the conversations that happen in the hallways, at the coffee station, or right after a talk? Those are often worth more than the talk itself.

Talk to speakers. Ask them a follow-up question. Share your perspective on something they said. Disagree, even — respectfully. The best conversations I’ve had at events started with “I see it slightly differently, here’s why.”

Networking isn’t about collecting business cards or LinkedIn connections. It’s about meaningful exchange. One real conversation with the right person can open a door that no session ever could.

3. Participate Actively

Side events, workshops, roundtables, and hackathons are where the real engagement happens. The more you put in, the more you get out. It sounds obvious, but most people default to passive attendance.

When you participate actively, you become memorable. People remember the person who asked the sharp question, who contributed to the workshop discussion, who showed up to the evening side event when everyone else went back to the hotel. That presence compounds over time.

4. Capture and Apply Insights

Take notes. Not on everything, but on what genuinely stands out. A new mental model. A tool you hadn’t heard of. A framing of a problem that clicked. A name someone mentioned three times.

The real value isn’t in the notes themselves. It’s in what you do with them afterward. Block time in the week after the event to review what you captured and identify one or two things you can actually apply. That’s the difference between an event that felt good and one that moved the needle.

The Right Measure of Success

Here’s a reframe that changed how I approach events: you don’t need to walk away with ten new contacts, a notebook full of insights, and a job offer to call it a success.

If you leave with one valuable new connection, one useful takeaway, or simply a great experience that reminded you why you’re in this field — that’s a win. Set that bar, and you’ll almost always clear it.

The mistake is treating events as passive consumption. The sessions are the structure, but the value is in how you engage with everything around them. Come prepared, stay curious, and be willing to start a conversation.

That’s where the real return is.

We’ve all been there. A service gets deployed, an API route goes live, and three weeks later someone asks, “Wait, what does this endpoint actually do?” The answer lives in someone’s head, a Slack thread, or a Confluence page nobody has updated since the initial design meeting. That’s the problem Spec-Driven Development (SDD) solves, and on AWS, it changes how you build, test, and evolve systems regardless of whether you’re running Lambda, ECS, EKS, or EC2.

This hands-on Spec-Driven Development workshop is built for that exact problem. Instead of watching demos, you’ll build a real application while learning how to define clear specs and guide AI to produce reliable, production-ready outputs.

After a sold-out first cohort, Cohort 2 is now open.

👉 Register here: https://www.eventbrite.co.uk/e/hands-on-spec-driven-development-workshop-cohort-2-tickets-1985498625838?aff=lefteris

Use code SD40 for 40% off

Spec-Driven Workshop at 40% off

What Is Spec-Driven Development?

Spec-Driven Development is a practice where the contract, also know as specification, is written before any implementation begins. The spec becomes the single source of truth. Everything else, the application logic, the infrastructure configuration, the event schemas, derives from it.

This isn’t documentation-first development in the old sense. It’s not about writing a Word document before you code. It’s about defining the shape of your system - inputs, outputs, events, errors - in a machine-readable format that your tooling, your tests, and your team can all reason about simultaneously.

Why It Matters Across AWS Architectures

The need for specs is a distributed systems problem, and AWS workloads are distributed by nature, whether you’re running microservices on ECS Fargate, a data pipeline on EMR, a real-time processing layer on Kinesis, or a containerized platform on EKS.

Every boundary between components is a contract. A service on ECS calling another service over HTTP, a Kafka consumer reading from MSK, an EKS pod publishing to an SQS queue, each of these is an implicit agreement about shape, behavior, and failure modes. Without a spec, that agreement is undocumented and fragile.

We’ve seen this break in predictable ways. A team running microservices on ECS changes the response schema of an internal API. The downstream service starts returning 500s. No contract test caught it. No spec was ever written. The failure surfaces in production, during peak traffic, after a deployment that passed all unit tests. A spec would have made that breaking change visible before it shipped.

The same pattern plays out in data engineering. A Glue job changes the shape of a Parquet file it writes to S3. The Athena queries downstream start failing. The schema was never formally defined, it was inferred from the data. An explicit schema contract, enforced at write time, would have caught the drift immediately.

Where Kiro Changes the Game

This is where AWS’s agentic IDE, Kiro, becomes directly relevant to how we practice SDD.

Kiro inverts the model most AI coding tools use. Kiro starts with the spec. When you describe a feature or a system in natural language, Kiro doesn’t generate code. It generates a structured specification first. That spec lives in three artifacts: requirements.md, design.md, and tasks.md.

The requirements file expands your prompt into user stories with acceptance criteria written in EARS notation, a structured format that captures preconditions, triggers, and expected system responses, including edge cases that would otherwise surface during implementation. The design file produces a technical design document covering architecture decisions and sequence diagrams. The tasks file breaks the design into discrete, sequenced implementation steps with dependency tracking. Only after you review and approve those artifacts does Kiro begin writing code.

This is spec-driven development operationalized inside your IDE. The spec isn’t a side artifact you produce reluctantly. It’s the primary artifact the entire workflow is built around. Code becomes the build output of the spec, not the other way around.

For teams building on AWS, this matters because it forces the contract conversation to happen before a single line of application or infrastructure code is written. Whether you’re defining an API contract between two ECS services, an event schema for an EventBridge rule, or the interface between a CDK construct and the team consuming it, all of it gets defined and reviewed at the spec level, not discovered during a production incident.

The Spec as the Center of Gravity

The shift SDD requires is treating the spec as the artifact that drives everything else, not as something you generate after the fact.

When we start a new API, the OpenAPI spec is written first. The service is built to satisfy it. The tests validate against it. When a consumer team needs to integrate, we hand them the spec, not a Slack message. The same principle applies to infrastructure. Before a new CDK construct is published for internal use, its interface contract is defined and reviewed. Breaking changes are explicit. They show up in the diff before they show up in a broken pipeline.

This approach forces clarity early. You can’t write a spec for something you haven’t thought through. The act of speccing a service or an event forces you to answer questions you’d otherwise defer: What are the required fields? What are the error states? What does a partial failure look like? What’s the versioning strategy?

The Discipline It Demands

Adopting SDD, with or without Kiro, requires a workflow shift.

• Design reviews happen at the spec level. Before any service is built, the team reviews the OpenAPI, AsyncAPI, or infrastructure spec. This is where architectural decisions get made, not in code review.

• Mocking becomes trivial. A spec-first API can be mocked immediately. Consumer teams don’t wait for implementation. Parallel development becomes the default.

• Breaking changes become visible. When the spec is versioned and diffed, breaking changes are explicit. A field removal or type change shows up in the diff before it shows up in a production incident.

• Onboarding accelerates. A new engineer joining the team can understand the system’s boundaries by reading the specs. The spec is the architecture, expressed precisely.

The temptation is always to skip the spec and start building, especially under deadline pressure. But the cost of that shortcut compounds. Every undocumented contract is technical debt that accrues interest in the form of production incidents, integration failures, and onboarding friction. Kiro makes that discipline easier to maintain by making the spec the default starting point, not an afterthought.

Write the spec first. Build to it. Everything else follows.

AI can get you to the first feature fast, but most developers struggle when the system starts to grow.

This hands-on Spec-Driven Development workshop is built for that exact problem. Instead of watching demos, you’ll build a real application while learning how to define clear specs and guide AI to produce reliable, production-ready outputs.

After a sold-out first cohort, Cohort 2 is now open.

Register here: https://www.eventbrite.co.uk/e/hands-on-spec-driven-development-workshop-cohort-2-tickets-1985498625838?aff=lefteris

Use code SDD40 for 40% off

Spec-Driven Workshop at 40% off

I took a different approach. I built projects that forced me to understand the services deeply, not just what they do, but why you’d choose them, what breaks under load, and how the pieces connect. I passed the SAA-C03 and could talk confidently in interviews about real implementations. Here are the 5 projects I recommend.

Sponsored by Salesforce

Cross-Platform Consistency with Agentforce AXL

If you’ve ever tried to maintain brand and logic parity for an AI agent across Slack, web, and mobile, you know the pain. Enter the Agentforce Experience Layer (AXL). This new abstraction layer allows you to define agent logic and UI components once and have them render natively across any surface—including third-party platforms like Microsoft Teams.

Stream the AXL Orchestration Session

Watch the developer conference of the year. On demand on Salesforce+

Agentic AI is changing the game and Agentforce is leading the way. Watch TDX on demand to explore dozens of sessions covering the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Watch TDX on Salesforce+ to:

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all starts with the main keynote, where you’ll experience the future of software and learn how to build it. Watch it now and catch every moment at your own pace.

👉 Watch Now

Let’s now go back to our article and see the 5 projects.

Project 1: Three-Tier Web Application

What you build: A custom VPC with public and private subnets, an Application Load Balancer, an Auto Scaling Group, and an RDS database.

Why it matters: This is the foundational architecture pattern behind almost every production web workload on AWS. The exam tests it constantly, and so does every technical interview.

The critical insight here is traffic flow. Your ALB lives in the public subnet and accepts inbound traffic on port 443. Your EC2 instances sit in private subnets and only accept traffic from the ALB’s security group, not from the internet. Your RDS instance sits in a separate private subnet and only accepts traffic from the EC2 security group. Nothing in the data tier is ever directly reachable.

When you build this yourself, you stop memorizing “databases should be private” and start understanding why: defense in depth, blast radius reduction, and compliance requirements that mandate network isolation. You also learn where Auto Scaling actually helps, horizontal scaling behind the ALB, and where it doesn’t, like a single-AZ RDS instance that becomes your bottleneck at 500 concurrent connections.

What the exam will ask: Multi-AZ RDS failover behavior, ALB vs. NLB selection criteria, and how security group rules differ from NACLs. Build this project and those questions answer themselves.

Project 2: Serverless Image Processing Pipeline

What you build: An S3 upload triggers Lambda, which resizes the image, stores metadata in DynamoDB, and sends an SNS notification.

Why it matters: Event-driven architecture is the dominant pattern in modern cloud systems. This project teaches you how AWS services communicate asynchronously, and what happens when they don’t.

The flow looks simple: S3 event → Lambda → DynamoDB write + SNS publish. But building it forces you to confront real decisions. What’s your Lambda timeout? If image processing takes 8 seconds and you set 5, you’ll see silent failures. What’s your DynamoDB write capacity? If you’re processing 200 images per minute and your table is provisioned for 50 WCU, you’ll hit throttling. What happens to the SNS notification if the DynamoDB write fails? You’ll need to think about idempotency and partial failure handling.

What the exam will ask: S3 event notification targets, Lambda concurrency limits, DynamoDB capacity modes, and SNS delivery guarantees. This project covers all of them.

Project 3: Disaster Recovery Solution

What you build: Cross-region S3 replication, automated RDS backups, and Route 53 failover routing.

Why it matters: DR is one of the most heavily tested domains on the SAA-C03, and it’s also one of the most misunderstood in practice. Most candidates can recite the four DR strategies. Few can explain the trade-offs that determine which one you’d actually choose.

Building this project forces you to internalize the RTO/RPO trade-off with real numbers. Cross-region S3 replication gives you near-zero RPO for object storage, replication typically completes in under 15 minutes for objects under 5GB. But your RDS automated backup has an RPO of up to 24 hours unless you’re using read replicas or Aurora Global Database. Route 53 health checks with failover routing can redirect traffic in under 60 seconds, but only if your secondary environment is already running (warm standby) or fully active (multi-site active-active).

The exam distinguishes between backup/restore (hours of RTO, lowest cost), pilot light (minutes of RTO, minimal running infrastructure), warm standby (seconds to minutes, scaled-down but live), and multi-site active-active (near-zero RTO, highest cost). Build this project and you’ll understand why a financial services company chooses multi-site active-active at $40,000/month while a content platform chooses backup/restore at $200/month.

What the exam will ask: S3 replication configuration, RDS backup retention, Route 53 routing policies, and how to calculate RTO/RPO for each DR tier.

Project 4: Hybrid Storage Solution

What you build: AWS Storage Gateway connected to on-premises systems, S3 lifecycle policies moving data through storage tiers, and IAM policies controlling access.

Why it matters: Most cloud engineers underestimate how much enterprise workload still runs on-premises. Storage Gateway is the bridge, and understanding it makes you sound experienced in interviews because it signals you’ve thought about migration, not just greenfield architecture.

Storage Gateway has three modes: File Gateway (NFS/SMB access to S3), Volume Gateway (iSCSI block storage backed by S3), and Tape Gateway (virtual tape library for backup software). The exam tests which mode fits which scenario. Build a File Gateway and you’ll understand why a media company with 200TB of on-premises video assets uses it to extend their NAS to S3 without rewriting their editing workflows.

S3 lifecycle policies complete the picture. Moving objects from S3 Standard to S3 Standard-IA after 30 days saves roughly 46% on storage costs. Moving to S3 Glacier Instant Retrieval after 90 days saves another 68%. For a workload storing 10TB of infrequently accessed data, that’s the difference between $230/month and $40/month. The exam will ask you to design the right lifecycle policy for a given access pattern, build this project and you’ll answer from experience, not memorization.

What the exam will ask: Storage Gateway modes, S3 storage class trade-offs, lifecycle policy configuration, and IAM policy structure for cross-account S3 access.

Project 5: Containerized Microservices Application

What you build: Two services deployed on ECS with Fargate, task definitions with resource limits, ALB path-based routing to each service, and CloudWatch Container Insights for logging and metrics.

Why it matters: Containers are now a core SAA-C03 domain, and ECS with Fargate is the AWS-native answer to “I want containers without managing servers.” Building this project teaches you the ECS mental model, clusters, services, task definitions, and tasks, and how they map to the infrastructure underneath.

The ALB routing piece is where most candidates get confused. Path-based routing lets you send /api/orders/* to your orders service and /api/inventory/* to your inventory service, both running as separate ECS services behind a single ALB. Each service has its own target group, its own task definition with CPU and memory limits, and its own auto-scaling policy based on CPU utilization or request count. When you build this, you understand why a task definition with 256 CPU units and 512MB memory will throttle under load before it scales, and how to set the right CloudWatch alarm threshold to trigger scaling before users notice.

CloudWatch Container Insights gives you container-level CPU, memory, network, and disk metrics without any instrumentation. You’ll see exactly which task is consuming resources and correlate it with application logs in the same console. That operational visibility is what separates a working prototype from a production-ready deployment.

What the exam will ask: ECS vs. EKS selection criteria, Fargate vs. EC2 launch type trade-offs, ALB target group configuration, and CloudWatch metrics for container workloads.

Conclusion

Watching videos teaches you what AWS services do. Building projects teaches you what they cost, where they fail, and why you’d choose one over another. Every question on the SAA-C03 is ultimately asking: given these constraints, what’s the right architecture decision?

These five projects give you the intuition to answer that question, not just on the exam, but in the room when a customer asks why their database is the bottleneck, why their DR plan won’t meet their RTO, or why their serverless pipeline is costing more than expected.

Build the projects. Pass the exam. Show up to the interview ready to talk about real systems.

Sponsored by Salesforce

Salesforce goes Headless 360

The biggest news out of SF last week wasn’t a new UI, it was the decoupling of it. Salesforce is officially pivoting to an API-first “Headless 360” architecture. For those of us tired of the walled garden constraints, this is a massive shift. By separating core CRM logic and data from the standard UI, we can now treat Salesforce as a backend engine for any custom frontend or external application stack.

Click the link here and let me know what you think!

Explore the biggest announcements, launches, and innovations from TDX 2026.

Agentic AI is changing the game and Agentforce is leading the way. Watch TDX on demand to explore dozens of sessions covering the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Watch TDX on Salesforce+ to:

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all starts with the main keynote, where you’ll experience the future of software and learn how to build it. Watch it now and catch every moment at your own pace.

👉 Watch Now

The Requirements

Let’s now go back to our article. We needed security that addressed four critical concerns:

Application-layer protection against SQL injection, XSS, and other OWASP Top 10 attacks that target business logic rather than infrastructure.

DDoS mitigation at both network and application layers without manual intervention. When attacks happen at 3 AM, automated response is non-negotiable.

Rate limiting and throttling that works across a global user base. Simple IP-based limiting breaks with legitimate users behind corporate NATs or mobile carriers.

Performance constraints of sub-200ms API response times even with all security layers active. Security cannot become the bottleneck.

We also needed complete observability into every attack attempt with real-time alerting when patterns emerge. The solution had to scale automatically, security couldn’t become the constraint during traffic spikes.

The AWS Services

API Gateway serves as the entry point, handling authentication, request validation, and throttling before requests reach backend functions. It’s the first line of defense that rejects malformed requests immediately.

AWS WAF sits in front of API Gateway, inspecting every HTTP request against managed rule sets and custom rules. It blocks attacks at the edge before they consume API Gateway capacity or cost Lambda invocations.

AWS Shield Standard comes automatically with API Gateway, providing DDoS protection against common network and transport layer attacks. Shield Advanced is available for scenarios requiring dedicated DDoS response team support.

The Flow

When a request hits our API, it reaches the regional API Gateway with WAF rules applied at the edge. If the request matches a block rule, suspicious patterns, known bad IPs, rate limit exceeded, it’s rejected with a 403 before reaching API Gateway.

For legitimate requests that pass WAF inspection, API Gateway applies its own throttling limits, validates the request structure, checks API keys or JWT tokens, and only then invokes backend functions. If anything fails validation, the request is rejected without consuming compute capacity.

This layered approach means attacks get stopped at the cheapest point possible. WAF blocks cost nothing beyond the WAF inspection fee. API Gateway rejections cost nothing beyond the API call. Only legitimate requests that pass all checks consume Lambda invocations.

Deep Dive: WAF Rule Strategy

We started with AWS Managed Rules, they catch 90% of common attacks immediately. But we hit false positives on legitimate API calls that included JSON payloads with special characters.

Our custom rules operate with three priorities:

IP reputation list blocks known malicious IPs. We integrated threat intelligence feeds that update hourly. This stops repeat offenders before they even attempt an attack.

Rate-based rules block IPs making more than 2,000 requests in five minutes. This catches credential stuffing attempts targeting our login endpoints. We observed attackers cycling through stolen credentials at exactly this rate, fast enough to test thousands of accounts but slow enough to avoid obvious detection.

Geo-blocking rules target countries with no legitimate users but high attack traffic. This was controversial internally, but the data was clear: 95% of attacks came from regions with zero paying customers.

The critical decision: we set WAF to count mode initially, not block. We observed traffic patterns for two weeks, identified false positives, tuned rules, then switched to block mode. This prevented accidentally blocking legitimate users during the learning phase.

Deep Dive: API Gateway Security Features

API Gateway provides multiple security layers beyond basic routing.

Request validation happens before Lambda invocation, rejecting requests with malformed JSON, missing required parameters, or invalid data types. This prevents malicious payloads from reaching backend code. We defined JSON schemas for every endpoint, verbose to maintain, but it stops entire classes of attacks.

Authentication integrates with multiple mechanisms. We use API keys for simple use cases, Lambda authorizers for custom logic, and Cognito user pools for OAuth 2.0 flows. Each request is validated before consuming any compute resources.

Resource policies add another control layer. We restricted our internal APIs to specific VPCs, preventing public internet access entirely while maintaining the benefits of API Gateway’s managed service.

Deep Dive: Throttling Strategy

API Gateway’s throttling operates at multiple levels, and understanding each is critical.

Account-level limits serve as a safety net, but real control comes from usage plans. Each usage plan has both rate limits (steady-state) and burst capacity. Burst capacity matters during traffic spikes when clients temporarily exceed their rate limit using burst tokens. We set burst to 2x the rate limit, this handles legitimate spikes without triggering false positives.

Custom throttling in WAF for specific endpoints adds another layer. Our login endpoints get rate-limited to 10 requests per minute per IP, far more restrictive than general API limits. This stops brute force attacks without impacting normal API usage.

Method-level throttling provides even finer control. Read operations (GET) can have higher limits than write operations (POST, PUT, DELETE), reflecting their different resource consumption and risk profiles. We observed that 80% of attacks targeted write endpoints, so we throttled them more aggressively.

Deep Dive: Shield Protection

Shield Standard provides automatic protection against common DDoS attacks at the network and transport layers. It detects and mitigates SYN floods, UDP reflection attacks, and other volumetric attacks without any configuration.

The protection operates inline with minimal latency impact. Shield’s detection algorithms analyze traffic patterns in real-time, distinguishing legitimate traffic spikes from attack patterns. When attacks are detected, mitigation happens automatically within seconds.

For our API, Shield Advanced wasn’t initially necessary. The decision point: Shield Advanced makes sense when API downtime costs exceed $3,000/month or when regulatory requirements mandate dedicated security response. We added it after a competitor suffered a multi-day DDoS attack that made headlines.

Monitoring and Observability

WAF logs every blocked request to CloudWatch Logs. We stream these to S3 for long-term analysis. Analyzing these logs reveals attack patterns, identifies false positives, and guides rule tuning. We set up CloudWatch alarms for blocked request spikes, when blocks exceed 1,000 per minute, we get paged.

API Gateway metrics expose throttling events, 4xx/5xx error rates, and latency distributions. We correlate WAF blocks with API Gateway metrics to see the full security picture, which attacks reached API Gateway versus which were blocked at WAF.

X-Ray tracing adds end-to-end visibility, showing exactly where requests spend time and where failures occur. This proved essential when debugging whether performance issues stemmed from security layers, backend code, or downstream services.

Cost Breakdown

WAF costs run approximately $5/month base fee plus $1 per million requests plus $1 per rule per month. With 10 custom rules and 100 million requests monthly, that’s $115/month.

API Gateway costs are $3.50 per million requests for REST APIs. At 100 million requests monthly, that’s $350/month. Caching can reduce backend invocations significantly.

Shield Standard is included at no additional cost. Shield Advanced costs $3,000/month plus data transfer fees, only justified for high-value APIs where downtime is extremely costly.

Lambda invocations saved by blocking malicious requests represent the hidden cost savings. We block approximately 5 million malicious requests monthly that would have cost $1 in Lambda invocations plus potential data breach costs.

Total monthly cost for our security stack: approximately $465 for WAF and API Gateway, blocking attacks that would cost far more in compute resources and potential breaches.

Key Takeaways

This architecture stops millions of malicious requests monthly, requests that would cost money and potentially compromise systems. The layered approach proves essential: WAF catches obvious attacks, API Gateway enforces business logic throttling and authentication, and Shield protects against network-layer DDoS. No single layer would be sufficient.

Sponsored by Salesforce

The shift toward Agentic AI isn’t just another buzzword—it’s redefining how we design, architect, and build modern systems.

That’s exactly why I’ll be tuning into TDX on Salesforce+ to explore how Agentforce is shaping the next generation of the developer roadmap.

If you’re serious about staying ahead of the curve, I highly recommend grabbing a free spot and joining the sessions.

Plus, when you register, you’ll be automatically entered for a chance to win one of 20 AI exam vouchers (valued at $200)—available to legal residents of the U.S., Canada, New Zealand, and the U.K.

Stream the developer conference of the year. Live on Salesforce+.

Agentic AI is changing the game and Agentforce is leading the way. Stream TDX to join dozens of sessions and virtual hands-on trainings that explore the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Tune in to TDX on Salesforce+ to:

• Build hands-on skills with virtual trainings and live demos

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all kicks off with the main keynote, where you’ll experience the future of software and learn how to build it. Add it to your calendar so you don’t miss a moment.

👉 Register for free

Why Tracing Matters in Serverless

Serverless applications are inherently distributed. A single user request might trigger an API Gateway endpoint, invoke multiple Lambda functions, write to DynamoDB, publish messages to SNS, and queue tasks in SQS. When something goes wrong, or even when you’re optimizing performance, pinpointing the bottleneck becomes challenging without proper tracing.

X-Ray solves this by creating a complete map of your request journey, showing you exactly where time is spent, where errors occur, and how services interact with each other. It’s the difference between guessing and knowing.

Understanding the Service Map

The service map is X-Ray’s visual representation of your application architecture. It automatically discovers and displays all the services your application uses, showing the relationships between them. Each node represents a service, and the connections show how requests flow between them.

What makes this powerful is the real-time health indicators. You can immediately spot services with high error rates or elevated latency. The color coding provides instant visual feedback, green for healthy, yellow for warnings, and red for errors. This bird’s-eye view helps you understand your system’s behavior at a glance.

Traces and Segments: The Building Blocks

Every request that flows through your application creates a trace. Within each trace, individual services create segments that represent the work they perform. For Lambda functions, a segment captures the entire function execution. For downstream calls to DynamoDB or other services, subsegments provide granular detail.

The trace timeline shows you exactly how long each segment took, helping you identify slow operations. You can drill down into specific traces to see the complete request path, including all the metadata, annotations, and errors associated with each segment.

Practical Tips for Effective Tracing

Start with sampling strategies wisely. X-Ray uses sampling to balance cost and visibility. The default sampling rule captures the first request each second and 5% of additional requests. For production environments, this is usually sufficient. However, for critical workflows or during troubleshooting, consider creating custom sampling rules to capture 100% of specific API paths or error conditions.

Use annotations for filtering and grouping. Annotations are indexed key-value pairs that you can use to filter traces in the X-Ray console. Add annotations for user IDs, transaction types, or feature flags. This makes it easy to analyze specific user journeys or compare performance across different code paths.

Leverage metadata for context. Unlike annotations, metadata isn’t indexed but provides rich contextual information when viewing individual traces. Include relevant business context, configuration values, or debugging information that helps you understand what was happening during the request.

Monitor cold starts separately. Lambda cold starts can significantly impact performance. Use X-Ray annotations to tag cold start invocations, allowing you to analyze their frequency and impact separately from warm starts. This helps you make informed decisions about provisioned concurrency.

Set up alarms on key metrics. X-Ray integrates with CloudWatch, allowing you to create alarms based on error rates, latency percentiles, or fault rates. Don’t wait to discover problems, let X-Ray notify you when thresholds are breached.

Trace asynchronous workflows. For event-driven architectures using SNS, SQS, or EventBridge, ensure you’re propagating trace context through message attributes. This maintains the trace continuity across asynchronous boundaries, giving you end-to-end visibility even in complex event chains.

Use trace groups for organization. As your application grows, create trace groups to organize and filter traces by environment, application component, or team ownership. This keeps your X-Ray console manageable and helps teams focus on their specific services.

The Bottom Line

AWS X-Ray transforms serverless observability from reactive debugging to proactive optimization. By providing clear visibility into request flows, performance characteristics, and error patterns, it empowers you to build more reliable and efficient serverless applications.

The key is to integrate X-Ray early in your development process, not as an afterthought when problems arise. With proper instrumentation and thoughtful use of annotations and sampling, X-Ray becomes an invaluable tool for understanding and improving your serverless architecture.

Sponsored by Salesforce

Stream the developer conference of the year. Live on Salesforce+.

Agentic AI is changing the game and Agentforce is leading the way. Stream TDX to join dozens of sessions and virtual hands-on trainings that explore the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Tune in to TDX on Salesforce+ to:

• Build hands-on skills with virtual trainings and live demos

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all kicks off with the main keynote, where you’ll experience the future of software and learn how to build it. Add it to your calendar so you don’t miss a moment.

👉 Register for free

What Are Canary Deployments?

A canary deployment is a progressive rollout strategy where you route a small percentage of production traffic to a new version of your application while the majority continues using the stable version. The term comes from the historical practice of using canaries in coal mines as early warning systems, if something goes wrong with the new version, only a small subset of users are affected.

In API Gateway, canary deployments work at the stage level. When you create a canary, you’re essentially splitting traffic between two versions of your API: the base deployment and the canary deployment. Each can point to different Lambda function versions or aliases, allowing you to test new code with real production traffic.

How Canary Deployments Work with Lambda

The integration between API Gateway canary deployments and Lambda is straightforward but powerful. When you deploy a canary in API Gateway, you specify a percentage of traffic to route to the canary version, typically starting with 5-10%. The remaining traffic continues flowing to your stable base deployment.

API Gateway uses a weighted random distribution to split traffic. This means if you set a 10% canary weight, approximately 10% of requests will hit your canary Lambda function version, while 90% go to the base version. The distribution happens at the request level, not the user level, so individual users might experience both versions during a canary deployment.

The key is that both deployments exist simultaneously in the same stage. Your base deployment might point to Lambda alias “production” running version 5, while your canary points to alias “canary” running version 6. This allows you to validate new functionality with real traffic patterns before committing to a full rollout.

Practical Tips for Success

Start Small and Increase Gradually: Begin with 5-10% traffic to your canary. Monitor metrics closely for 15-30 minutes before increasing. A common progression is 10% → 25% → 50% → 100%, with monitoring periods between each increase.

Use Lambda Aliases, Not Versions Directly: Always point your API Gateway integrations to Lambda aliases rather than specific versions. This gives you flexibility to update what version an alias points to without redeploying your API. Use one alias for production traffic and another for canary testing.

Monitor the Right Metrics: Focus on error rates, latency percentiles (especially p99), and business-specific metrics. Don’t just watch averages, a 1% error rate on your canary means 1 in 100 of your customers are having problems. Set up CloudWatch alarms that compare canary metrics against baseline metrics.

Implement Proper Logging: Ensure your Lambda functions log which version they are. Include version information in structured logs so you can quickly filter and compare behavior between canary and base deployments during troubleshooting.

Have a Rollback Plan: Know how to quickly promote your canary to 100% if it’s successful, or delete it entirely if problems arise. Practice these operations in non-production environments. The API Gateway console and CLI both support these operations, but automation through CI/CD pipelines is ideal.

Consider Stage Variables: Use API Gateway stage variables to pass configuration to your Lambda functions. This allows the same Lambda code to behave differently based on whether it’s handling base or canary traffic, useful for feature flags or environment-specific settings.

Test with Realistic Load: Canary deployments are most valuable when they experience real production traffic patterns. Avoid deploying canaries during low-traffic periods if possible, you want enough requests to generate statistically significant results.

Don’t Rush the Process: The entire point of canary deployments is risk reduction. If you promote a canary to 100% within minutes, you’re not giving yourself time to detect issues. Plan for canary periods of at least several hours for critical APIs.

When to Use Canaries

Canary deployments shine when rolling out significant changes: new business logic, performance optimizations, dependency updates, or architectural changes. They’re less critical for minor bug fixes or configuration changes, though the safety they provide is always valuable.

The overhead of managing canaries is minimal compared to the protection they offer. For production APIs serving real customers, canary deployments should be your default deployment strategy, not an exception.

Sponsored by Salesforce

Stream the developer conference of the year. Live on Salesforce+.

Agentic AI is changing the game and Agentforce is leading the way. Stream TDX to join dozens of sessions and virtual hands-on trainings that explore the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Tune in to TDX on Salesforce+ to:

• Build hands-on skills with virtual trainings and live demos

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all kicks off with the main keynote, where you’ll experience the future of software and learn how to build it. Add it to your calendar so you don’t miss a moment.

👉 Register for free

Architecture Overview

Our multi-region architecture consists of four key components working together:

• Route 53: Provides intelligent DNS routing to direct users to the nearest regional endpoint

• API Gateway: Regional REST or HTTP APIs that serve as entry points in each region

• Lambda: Compute layer that processes requests with minimal latency

• DynamoDB Global Tables: Multi-region, fully replicated database with automatic conflict resolution

This architecture provides active-active deployment across multiple AWS regions, ensuring that if one region experiences issues, traffic automatically fails over to healthy regions.

The Architecture Flow

At the heart of a multi-region serverless architecture lies a carefully orchestrated chain of AWS services working together to deliver a seamless global experience.

Route 53: The Global Traffic Director

Amazon Route 53 serves as the entry point for all user requests. Using health checks and routing policies like latency-based or geoproximity routing, Route 53 intelligently directs users to the nearest healthy regional endpoint. This ensures that a user in Tokyo connects to the Asia Pacific region while a user in Frankfurt connects to Europe, minimizing latency and improving user experience.

API Gateway: Regional Entry Points

Each region hosts its own API Gateway endpoint, acting as the front door for that region’s serverless infrastructure. API Gateway handles request validation, throttling, and authentication before passing requests to the compute layer. With features like request/response transformation and built-in AWS WAF integration, it provides a robust security perimeter for your application.

Lambda: Distributed Compute

Behind each regional API Gateway sits AWS Lambda functions that execute your business logic. These functions are deployed identically across all regions, ensuring consistent behavior regardless of where the request originates. Lambda’s automatic scaling handles traffic spikes in each region independently, while its pay-per-use model keeps costs optimized even with a multi-region footprint.

DynamoDB Global Tables: The Data Layer

The foundation of this architecture is DynamoDB Global Tables, which provides fully managed, multi-region, multi-active database replication. When a Lambda function writes data in one region, DynamoDB automatically replicates that data to all other configured regions, typically within seconds. This means users can read and write data from their nearest region while maintaining global consistency.

Key Architectural Considerations

Conflict Resolution: DynamoDB Global Tables uses a last-writer-wins reconciliation strategy. Your application design should account for this, potentially using timestamps or version numbers to handle concurrent updates across regions.

Replication Lag: While DynamoDB replication is fast, there’s still a brief window where data might not be consistent across all regions. Design your application to handle eventual consistency gracefully.

Regional Failover: Route 53 health checks continuously monitor your regional endpoints. If a region becomes unhealthy, traffic automatically routes to the next best region, providing transparent failover without user intervention.

Cost Implications: Running infrastructure in multiple regions increases costs through data transfer charges and duplicated resources. Balance the number of regions against your actual user distribution and availability requirements.

The Benefits

This architecture delivers several compelling advantages. Users experience lower latency by connecting to nearby infrastructure. Your application remains available even if an entire AWS region experiences an outage. Data is protected through geographic redundancy. And perhaps most importantly, you can scale globally without redesigning your architecture.

When to Use This Pattern

Multi-region architectures make sense for applications with a global user base, strict availability requirements, or regulatory needs for data residency. However, they add complexity and cost, so evaluate whether your application truly needs global distribution or if a single-region deployment with good disaster recovery would suffice.

Conclusion

Building a multi-region serverless architecture with Route 53, API Gateway, Lambda, and DynamoDB Global Tables provides a robust foundation for globally distributed applications. This architecture delivers low-latency responses to users worldwide while maintaining high availability and disaster recovery capabilities.

The key to success is embracing eventual consistency, implementing comprehensive monitoring, and regularly testing your failover mechanisms. While the initial setup requires careful planning, the operational benefits of automatic scaling, reduced latency, and improved reliability make it worthwhile for applications serving a global user base.

The Serverless Testing Challenge

Serverless architectures introduce complexity that makes testing more nuanced than traditional applications. Lambda functions don’t run in isolation, they interact with API Gateway, DynamoDB, S3, SQS, SNS, EventBridge, and numerous other AWS services. The pay-per-invocation model means you can’t simply spin up a test environment and leave it running. Additionally, the distributed nature of serverless systems means that failures can cascade across multiple services in ways that are difficult to predict and reproduce.

The testing pyramid for serverless applications looks different from traditional applications. While you still want a solid foundation of unit tests, the integration layer becomes significantly more important because so much of your application’s behavior depends on how services interact with each other.

Unit Testing Lambda Functions

Unit testing Lambda functions focuses on testing your business logic in isolation from AWS services. The key principle is to separate your core logic from the Lambda handler and AWS SDK calls. This separation allows you to test your business logic without needing to mock AWS services or make actual API calls.

Testing Frameworks: Use Jest or Mocha for Node.js Lambda functions, pytest for Python, JUnit for Java, or Go’s built-in testing package for Go-based functions. These frameworks provide the foundation for writing and running your unit tests with features like test discovery, assertions, and test reporting.

Your Lambda handler should be thin, primarily responsible for parsing events, calling your business logic, and formatting responses. The actual business logic should live in separate modules that can be tested independently. This architectural pattern makes your code more testable and maintainable.

When unit testing, focus on testing edge cases, error conditions, and business rule validation. Test how your code handles malformed input, missing required fields, and unexpected data types. These tests should run quickly and require no external dependencies, making them ideal for rapid feedback during development.

Mocking Tools: Mock external dependencies at the boundaries of your application using tools like aws-sdk-mock for JavaScript, or moto for Python. Rather than mocking the entire AWS SDK, create abstraction layers or interfaces that represent the operations your code needs to perform. This approach makes your tests more resilient to changes in the AWS SDK and keeps your business logic decoupled from infrastructure concerns.

Integration Testing Strategies

Integration testing for serverless applications verifies that your Lambda functions work correctly with actual AWS services. This is where you test the contracts between your code and services like DynamoDB, S3, SQS, and API Gateway. Integration tests are more expensive and slower than unit tests, but they catch issues that unit tests cannot.

Integration Testing Tools: Leverage AWS SAM CLI for local testing and deployment, Serverless Framework’s invoke local command, or LocalStack for comprehensive AWS service emulation. For end-to-end testing, consider Postman or Newman for API testing, and aws-testing-library for programmatic integration tests.

There are several approaches to integration testing in serverless environments. One strategy involves deploying to a dedicated testing environment in AWS and running tests against real services using AWS CDK or Terraform for infrastructure provisioning. This approach provides the highest confidence that your application will work in production, but it’s also the slowest and most expensive option.

Another approach uses local emulation tools like LocalStack, SAM Local, or Serverless Offline that simulate AWS services on your development machine. These tools provide a faster feedback loop than deploying to AWS, but they may not perfectly replicate the behavior of actual AWS services. They’re best used for rapid iteration during development, with periodic validation against real AWS services.

Contract Testing: Consider implementing contract testing using Pact or Spring Cloud Contract for your Lambda functions. Contract tests verify that your functions correctly handle the event formats they receive from triggers like API Gateway, EventBridge, or SQS. They also verify that your functions produce output in the format expected by downstream services. This approach helps catch breaking changes early.

Integration tests should cover the critical paths through your application, the workflows that represent your core business value. Test how your functions handle retries, how they behave under throttling conditions, and how they recover from transient failures using tools like Chaos Toolkit or AWS Fault Injection Simulator for chaos engineering experiments. These scenarios are difficult to test with unit tests alone.

Local Development Strategies

Effective local development for serverless applications requires tools and workflows that provide rapid feedback without requiring constant deployment to AWS. The goal is to enable developers to iterate quickly while maintaining confidence that their code will work when deployed.

Local Development Tools: Use AWS SAM CLI with sam local start-api and sam local invoke commands, Serverless Framework with the serverless-offline plugin, or LocalStack for comprehensive local AWS service emulation. Docker is essential for containerizing your development environment to match Lambda’s execution environment.

Local development environments should replicate the Lambda execution environment as closely as possible using Docker images based on AWS Lambda base images. This includes matching the runtime version, environment variables, memory configuration, and timeout settings. Discrepancies between local and deployed environments are a common source of bugs that only appear in production.

Consider using Docker Compose to orchestrate containerized development environments that mirror the Lambda runtime. This approach ensures consistency across your development team and reduces “works on my machine” issues. Containers can include all necessary dependencies, tools, and configurations, making onboarding new developers faster and more reliable.

Debugging Tools: Local development should support debugging with breakpoints and step-through execution using VS Code’s built-in debugger, AWS Toolkit for VS Code, IntelliJ IDEA with AWS Toolkit, or PyCharm’s remote debugging. The ability to pause execution, inspect variables, and step through code line by line is invaluable for understanding complex issues. This capability is especially important when working with asynchronous operations and event-driven workflows.

Conclusion

Testing serverless applications requires a comprehensive strategy that spans unit testing, integration testing, local development, and production monitoring. The distributed nature of serverless architectures and the tight integration with managed services make testing more complex than traditional applications, but the right tools and approach can provide confidence in your application’s reliability and correctness.

In this article, we'll cover what they are, when you should use them, and how they compare with AWS Step Functions to help you choose the right orchestration tool for your serverless applications.

What Are Lambda Durable Functions?

Lambda Durable Functions are regular Lambda functions enhanced with stateful execution capabilities. They allow you to write complex, long-running workflows directly in your application code using familiar programming languages, rather than defining workflows in a separate orchestration language.

The key innovation lies in automatic checkpointing. As your function executes, AWS Lambda automatically saves progress at strategic points. If your workflow needs to wait for an external event, such as a webhook callback, a manual approval, or a scheduled delay, the function pauses without consuming compute resources. When the awaited event occurs, execution resumes from the last checkpoint with full context preserved.

This approach embeds orchestration logic directly into your Lambda code, eliminating the need to manage state manually or architect separate state management systems. The result is a serverless-first approach that reduces operational overhead while maintaining the scalability and pay-per-use economics that make serverless attractive.

When to Use Durable Functions

Lambda Durable Functions excel in specific scenarios where application logic naturally involves multiple steps with waiting periods:

AI and Machine Learning Workflows - Orchestrating multi-stage AI pipelines where each step might involve model inference, data transformation, or human review. The ability to pause between stages without incurring costs makes this particularly economical for batch processing scenarios.

Order Processing and E-commerce - Managing order fulfillment workflows that span inventory checks, payment processing, shipping coordination, and customer notifications. These workflows often involve waiting for external system responses or scheduled delivery windows.

Approval and Human-in-the-Loop Processes - Building loan applications, expense approvals, or content moderation systems where workflows must pause for human decisions before proceeding. The year-long execution window accommodates even the most extended approval cycles.

Event-Driven Application Logic - Coordinating complex business processes that respond to multiple events over time, such as customer onboarding journeys, subscription lifecycle management, or multi-step data processing pipelines.

Application-Centric Orchestration - When your workflow logic is tightly coupled with your application code and benefits from being expressed in the same programming language as the rest of your business logic.

How Durable Functions Compare with Step Functions

Both Lambda Durable Functions and AWS Step Functions solve the problem of orchestrating multi-step workflows, but they approach it from fundamentally different philosophical and architectural standpoints.

Architectural Philosophy

Step Functions is built for infrastructure orchestration. It excels at coordinating disparate AWS services, providing a visual workflow designer, and offering a declarative approach using Amazon States Language (ASL). The workflow definition lives separately from your application code, making it ideal for workflows that need to be understood and modified by operations teams or non-technical stakeholders.

Durable Functions, by contrast, are optimized for application orchestration. The workflow logic lives within your Lambda function code, written in your preferred programming language. This code-first approach makes it natural for developers who want to keep orchestration logic alongside business logic, use familiar debugging tools, and leverage existing programming constructs like loops, conditionals, and error handling.

Developer Experience

With Step Functions, you define workflows in ASL—a JSON-based state machine definition language. While powerful and expressive, this requires learning a new syntax and switching contexts between your application code and workflow definitions. Local testing typically involves additional tooling or mocking frameworks.

Durable Functions let you write workflows as regular code. If you know how to write a Lambda function, you already know how to write a durable function. The workflow logic uses standard programming constructs, making it more intuitive for developers and easier to test locally using familiar development tools.

Visibility and Monitoring

Step Functions provides superior visual representation of workflows. The built-in graphical interface shows execution flow, making it easy for stakeholders to understand complex processes at a glance. This visualization is particularly valuable for compliance, auditing, and operational monitoring.

Durable Functions trade some of this visual clarity for code simplicity. While you can still monitor executions through CloudWatch and Lambda insights, the workflow structure isn’t as immediately apparent to non-technical observers.

Use Case Alignment

Choose Step Functions when you need to:

• Orchestrate multiple AWS services (Lambda, ECS, Glue, etc.)

• Provide workflow visibility to non-technical stakeholders

• Build workflows that benefit from visual design and monitoring

• Implement complex branching, parallel execution, or error handling patterns that benefit from declarative definition

• Maintain clear separation between orchestration and business logic

Choose Durable Functions when you need to:

• Keep workflow logic tightly integrated with application code

• Leverage existing programming language features and libraries

• Simplify development by avoiding context switching between code and ASL

• Build workflows where the orchestration is primarily application logic rather than service coordination

• Optimize for developer velocity and code maintainability within Lambda

Cost Considerations

Both services charge only for active execution time, not idle waiting periods. However, the pricing models differ slightly. Step Functions charges per state transition, while Durable Functions follow Lambda’s standard pricing model with additional charges for state persistence. For workflows with many state transitions, Durable Functions may offer cost advantages. For workflows coordinating many AWS services, Step Functions’ integration capabilities may provide better value.

Conclusion

Lambda Durable Functions and Step Functions aren’t competitors—they’re complementary tools in your serverless toolkit. Durable Functions shine when you want to write workflow logic as code within your Lambda functions, keeping orchestration close to your application logic. Step Functions excel when you need to coordinate multiple AWS services with clear visual representation and operational oversight.

The choice ultimately depends on your team’s preferences, the nature of your workflows, and whether you value code-centric development or service-centric orchestration. Many organizations will find themselves using both, selecting the right tool for each specific use case.

That’s exactly the problem Kiro is designed to solve.

What Is Kiro?

Kiro is an AI-powered IDE built for developers who work with cloud infrastructure. It’s not just a code editor with a chatbot bolted on, it’s a development environment that understands your infrastructure context and actively helps you build, validate, and troubleshoot it.

One of Kiro’s most compelling features is its Powers system. Powers are purpose-built AI capabilities that you can install directly into your IDE, each one tailored to a specific domain or technology. Think of them as expert co-pilots for different parts of your stack.

And for AWS engineers, there’s one Power that deserves your full attention.

The “Build AWS Infrastructure with CDK and CloudFormation” Power

Available at kiro.dev/powers, this Power is built specifically for AWS infrastructure development. Its description is straightforward but the implications are significant:

“Build well-architected AWS infrastructure with CDK using latest documentation, best practices, and code samples. Validate CloudFormation templates, check resource configuration security compliance, and troubleshoot deployments.”

This isn’t a generic AI assistant that happens to know some AWS. This is a focused, infrastructure-aware capability that integrates directly into your development workflow.

What This Power Actually Does

Under the hood, this Kiro Power is backed by the AWS Infrastructure as Code (IaC) MCP Server, a tool built on the Model Context Protocol (MCP) that connects AI assistants to your local AWS development environment.

The Power gives Kiro access to a set of specialized tools organized into two categories:

Documentation and Knowledge Tools

• Search CDK documentation and best practices

• Read specific CDK documentation pages

• Search CDK samples and constructs

• Search CloudFormation documentation

Validation and Troubleshooting Tools

• Validate CloudFormation templates before deployment

• Check resource configuration for security compliance

• Get pre-deployment validation instructions

• Troubleshoot CloudFormation deployment failures

Together, these capabilities cover the full lifecycle of infrastructure development, from the moment you start designing a stack to the moment you’re debugging a failed deployment.

Why This Changes Your CDK and CloudFormation Workflow

You Stop Guessing at Best Practices

One of the most common pain points with CDK is knowing how to use it correctly, not just that you can use it. Should you use a Construct or an L2 Construct? What’s the right pattern for a serverless API? What are the security defaults you should always set?

With this Power active, Kiro can answer these questions in context, pulling from the latest AWS documentation and surfacing the right patterns for your specific use case. You’re not getting generic advice; you’re getting guidance grounded in current AWS best practices.

You Catch Errors Before They Reach AWS

CloudFormation template errors are notoriously painful to debug. You deploy, wait several minutes, and then get a cryptic rollback message. With Kiro’s validation tools, you can catch configuration issues and security compliance gaps before you ever run cdk deploy or submit a stack.

This alone can save significant time in any infrastructure development cycle.

You Troubleshoot Deployments Faster

When deployments do fail, Kiro can help you understand why. Rather than manually cross-referencing CloudTrail logs and CloudFormation events, you can ask Kiro directly, and it will surface the relevant error context and suggest a fix. For example, if CloudTrail shows an AccessDenied error for a specific API call, Kiro can identify the missing permission and tell you exactly what needs to change in your deployment role.

You Learn While You Build

If you’re newer to CDK or expanding into unfamiliar AWS services, this Power doubles as a learning accelerator. You can ask Kiro to show you how to build a specific architecture pattern, and it will search CDK constructs and samples to give you multiple implementation approaches, not just one answer, but a range of options with context.

Security and Local Execution

A reasonable concern with any AI-assisted development tool is: where does my code go?

The IaC MCP Server that powers this Kiro capability runs entirely on your local machine. Your CloudFormation templates and CDK code are not sent to external services. The only external calls made are for documentation searches. AWS credentials are used from your existing local configuration, the same way the AWS CLI works, and communication between the server and Kiro happens over standard input/output with no network ports opened.

For teams working in regulated environments or with sensitive infrastructure, this local execution model is a meaningful architectural choice.

Getting Started

Installing the Power is straightforward from within the Kiro IDE. Navigate to the Powers panel in the sidebar, find “Build AWS infrastructure with CDK and CloudFormation” under the Recommended section, and install it. Once active, Kiro gains access to all the CDK and CloudFormation tools described above.

The Bigger Picture

CDK and CloudFormation are not going away. If anything, infrastructure as code is becoming more central to how teams build and operate on AWS, not less. The question isn’t whether you’ll use these tools; it’s how efficiently you’ll use them.

Kiro’s CDK and CloudFormation Power represents a meaningful shift in that equation. It brings documentation, validation, compliance checking, and troubleshooting directly into your development environment, reducing the context-switching that slows down infrastructure work and helping you build well-architected systems faster.

If you’re serious about AWS infrastructure development, this is worth adding to your workflow.

But here’s the thing: serverless is not a silver bullet.

After years of building on AWS, I’ve seen teams adopt serverless for everything — and sometimes pay the price in performance, cost, complexity, or all three. The best architects don’t just know when to use a tool. They know when not to.

In this article, I’ll walk you through five real-world use cases where going serverless is the wrong choice, and what you should consider instead.

1. Long-Running, Compute-Heavy Workloads

The Problem

AWS Lambda has a hard timeout of 15 minutes. If your workload takes longer than that, Lambda simply isn’t an option. But even workloads that fit within 15 minutes can be a poor match.

Think about:

• Video transcoding or rendering

• Large-scale data transformations (ETL)

• Machine learning model training

• Complex PDF generation from massive datasets

These tasks are CPU-intensive and often run for extended periods. Shoehorning them into Lambda means you’ll spend your time fighting the platform instead of leveraging it.

Why Serverless Fails Here

• 15-minute max execution time is a hard ceiling you can’t negotiate.

• CPU is allocated proportionally to memory in Lambda. To get meaningful compute power, you might need to allocate 4–10 GB of memory — even if you only need 512 MB of RAM. You’re paying for memory you don’t use just to get CPU.

• No GPU access. If your workload benefits from GPU acceleration, Lambda is out of the question.

• Orchestrating many short Lambda functions to chunk the work adds significant complexity and potential failure points.

What to Use Instead

• AWS Fargate (ECS) — Containerized long-running tasks without managing servers

• EC2 Spot Instances — Cost-effective heavy compute (batch jobs, rendering)

• AWS Batch — Managed batch processing at scale

• SageMaker — ML model training specifically

• Step Functions + Fargate — Orchestrated pipelines with long-running steps

A Practical Example

Let’s say you’re processing uploaded video files. Instead of Lambda:

S3 Upload Event → EventBridge → Fargate Task (ECS)

Fargate gives you configurable vCPU and memory, no time limits, and you only pay for the duration of the task. You still get the “no servers to manage” benefit without Lambda’s constraints.

2. High-Throughput, Latency-Sensitive Applications

The Problem

You’re building an application that needs to handle thousands of requests per second with consistent, single-digit millisecond response times. Think:

• Real-time bidding platforms

• High-frequency trading APIs

• Multiplayer game backends

• Real-time fraud detection at the edge

Why Serverless Fails Here

The biggest villain here is the cold start.

When Lambda spins up a new execution environment, there’s an initialization delay.

• Python, Node.js: 100–300 ms

• Java, .NET: 500 ms – 2+ seconds

For most applications, cold starts are a minor nuisance. For latency-critical systems, they’re a dealbreaker.

Yes, Provisioned Concurrency exists, and SnapStart helps with Java. But:

• Provisioned Concurrency is essentially pre-warming containers — which defeats the core serverless value proposition. You’re paying for idle compute.

• You still can’t guarantee tail latency (p99/p99.9) the way you can with a warm, long-running process.

• At high throughput, the API Gateway overhead (typically 10–30 ms) adds up and is hard to eliminate.

What to Use Instead

• ECS/EKS on Fargate or EC2 — Long-running containers with persistent connections and predictable latency.

• EC2 with Auto Scaling — Maximum control over the runtime, networking, and performance tuning.

• ElastiCache (Redis) — Pair with containers for ultra-low-latency data access.

The Key Takeaway

If your SLA says “p99 latency under 10 ms”, serverless will make that extremely difficult and expensive to achieve. Use always-on compute with connection pooling and warm caches.

3. Applications with Complex or Stateful Workflows (That Need Persistent Connections)

The Problem

Serverless functions are stateless and ephemeral by design. Each invocation is independent. There’s no shared memory, no local disk that persists, and no guarantee that the same instance handles consecutive requests.

This becomes painful when you need:

• WebSocket connections with complex server-side state

• Long-lived database connection pools

• In-memory caching across requests

• Sticky sessions

Why Serverless Fails Here

Database connections are the classic pain point. Every Lambda invocation may open a new connection to your relational database. Under load, you can easily exhaust your database’s connection limit.

100 concurrent Lambda invocations = 100 database connections
1,000 concurrent invocations = 💥 database connection limit exceeded

RDS Proxy helps by pooling connections, but it:

• Adds cost

• Adds latency (~5–15 ms per query overhead)

• Is another component to configure and monitor

• Doesn’t eliminate the fundamental mismatch — it just papers over it

In-memory state is another problem. If your application logic depends on keeping data in memory across requests (e.g., a game server tracking player positions, a collaborative editing backend), Lambda can’t help you. You’d have to externalize all state to DynamoDB, ElastiCache, or S3 — adding latency and complexity for every operation.

What to Use Instead

• ECS/Fargate with long-running containers that maintain connection pools and in-memory state.

• EC2 for maximum control over memory, connections, and runtime behavior.

• ElastiCache if you need shared in-memory state across instances.

• AppSync for managed GraphQL with real-time subscriptions (a serverless option that does handle WebSockets well, but for a specific use case).

When It’s a Judgment Call

If you’re building a standard REST API with a relational database, serverless can work — especially with RDS Proxy and moderate traffic. But if your application is connection-heavy or state-heavy, you’ll spend more time fighting the architecture than building features.

4. Predictable, Always-On, Steady-State Workloads

The Problem

Serverless pricing is brilliant for spiky, unpredictable, or low-traffic workloads. You pay per invocation, per millisecond of compute. When traffic is zero, your bill is zero.

But what about workloads that run 24/7 at a consistent, high volume?

• A backend API serving millions of requests per day, evenly distributed

• A stream processor consuming from Kinesis around the clock

• A WebSocket server with thousands of persistent connections

Why Serverless Fails Here

Let’s do some back-of-the-envelope math.

Scenario: An API handling 50 million requests/month, average execution time of 200 ms, with 512 MB memory allocated.

Lambda Cost:

Compute: 50M × 0.2s × 0.5 GB = 5,000,000 GB-seconds
Cost:    5,000,000 × $0.0000166667 = ~$83.33
Requests: 50M × $0.20/million     = ~$10.00
API Gateway: 50M × $1.00/million  = ~$50.00
                                    --------
Total:                              ~$143/month

Fargate Equivalent (2 tasks, 0.5 vCPU, 1 GB each):

vCPU:   2 × 0.5 × $0.04048/hr × 730 hrs = ~$29.55
Memory: 2 × 1 GB × $0.004445/hr × 730 hrs = ~$6.49
ALB:    ~$16.20 + LCU charges (~$5-10)     = ~$25.00
                                              --------
Total:                                       ~$61/month

That’s a ~57% cost reduction with Fargate — and the gap widens as traffic increases.

The Rule of Thumb

Ask yourself:

“Will my compute utilization be consistently above 20-30%?”

If yes, reserved/always-on compute (Fargate, EC2 Reserved Instances, or Savings Plans) will almost always be cheaper.

What to Use Instead

• Fargate with Auto Scaling — Steady containerized workloads with occasional spikes

• EC2 Reserved Instances / Savings Plans — Predictable, long-term workloads at the best price

• EKS — When you need Kubernetes orchestration at scale

The Hybrid Approach

The best architectures often mix serverless and containers:

• Use Lambda for event-driven, asynchronous tasks (S3 triggers, SNS handlers, cron jobs).

• Use Fargate/EC2 for the high-throughput, steady-state API layer.

You get the best of both worlds.

5. Complex Local Development and Debugging Requirements

The Problem

This one is less about production and more about developer experience — which matters more than many teams admit.

Serverless applications are inherently distributed. A single user action might involve:

API Gateway → Lambda → DynamoDB → DynamoDB Stream → Lambda → SNS → Lambda → SQS → Lambda

Try debugging that locally.

Why Serverless Fails Here

• Local emulation is imperfect. Tools like SAM CLI and LocalStack are helpful but don’t perfectly replicate IAM permissions, event source mappings, service integrations, or edge cases.

• “Console log” debugging is still the primary debugging strategy for many Lambda developers. Attaching a real debugger with breakpoints is possible but cumbersome.

• Integration testing is hard. You often need a deployed AWS environment to truly test your application, which slows down the feedback loop.

• Distributed tracing adds overhead. You’ll need X-Ray or third-party tools to understand request flows across services.

• Each developer needs their own cloud sandbox. Unlike a containerized app where you can docker-compose up and have a full environment locally, serverless often requires deploying to AWS — leading to shared-environment conflicts or the cost of per-developer AWS accounts.

When This Matters Most

• Large teams where developer productivity at scale is critical

• Complex, multi-service architectures with many interconnected functions

• Regulated industries where you need to reproduce and debug production issues quickly

• Teams new to serverless with existing expertise in containers or traditional architectures

What to Use Instead

If developer experience is a priority and your team is more productive with containers:

• Docker Compose + ECS/Fargate — Develop locally with Docker, deploy to Fargate. Nearly identical environments.

• EKS with Skaffold or Telepresence — Hot-reload Kubernetes development.

A Balanced View

To be fair, the serverless developer experience is improving rapidly. Tools like SST (Serverless Stack), AWS SAM Accelerate, and Lambda Powertools have made development significantly better. If you’re starting a greenfield project with a small team, serverless DX is often good enough.

But for large, complex systems — especially if your team has deep container expertise — forcing a serverless-first approach can meaningfully slow development velocity.

So... When SHOULD You Go Serverless?

After all that, let’s end on a positive note. Serverless is the right choice when:

1. Your traffic is spiky, unpredictable, or low-volume

2. You want to minimize operational overhead (no patching, no capacity planning)

3. You’re building event-driven architectures (S3 triggers, message processing, webhooks)

4. You need to ship fast with a small team

5. Your workloads are short-lived (seconds, not minutes)

6. You want automatic scaling from zero to massive without configuration

7. You’re building microservices, APIs, or background jobs with moderate latency requirements

The Bottom Line

The best cloud architects aren’t loyal to any single paradigm. They pick the right tool for the job.

Serverless is incredible — I use it extensively and recommend it often. But blindly applying it to every problem leads to over-engineered, expensive, and frustrating architectures.

Before going serverless, ask yourself:

1. Does my workload fit within Lambda’s execution limits?

2. Can I tolerate cold start latency?

3. Is my application fundamentally stateless?

4. Is my traffic pattern spiky or variable?

5. Can my team debug and develop effectively in a serverless model?

If the answer to any of these is “no”, consider containers, EC2, or a hybrid approach. There’s no shame in using a server. After all, serverless still runs on them.

The good news? You can dramatically reduce your risk by following a clear set of steps in the first 24 hours. This article is that checklist.

Let’s get started.

Why the First 24 Hours Matter

New AWS accounts are often in their most vulnerable state right after creation. Default settings are permissive, there’s no monitoring in place, and credentials are frequently mishandled. Automated bots constantly scan for exposed keys and misconfigured resources. Stories of developers waking up to five-figure AWS bills after accidentally committing credentials to GitHub are not myths, they happen regularly.

Treating security as a “day one” priority is not paranoia. It’s engineering discipline.

Phase 1: Protect the Root Account

The root account is the single most powerful identity in your AWS environment. It has unrestricted access to everything, and it cannot be limited by IAM policies. Your first actions should be to lock it down.

1. Set a Strong, Unique Password for the Root User

The password you chose during sign-up might have been rushed. Go to the account settings and make sure the root password is long, random, and stored in a reputable password manager. Do not reuse a password from another service.

2. Enable Multi-Factor Authentication (MFA) on the Root Account

This is the single most important step on this entire list. Go to the IAM console, select the root user, and enable MFA. A hardware security key (such as a YubiKey) is the strongest option. A virtual MFA app like Google Authenticator or Authy is a solid alternative. Avoid SMS-based MFA if possible, as it is vulnerable to SIM-swapping attacks.

3. Do Not Generate Access Keys for the Root Account

The root user should never have programmatic access keys. If keys already exist for the root account, delete them immediately. There is no legitimate operational reason to use root access keys.

4. Store Root Credentials Securely and Rarely Use Them

After setting up the root account, you should almost never log into it again. Store the credentials and MFA recovery codes in a secure vault (a physical safe or an encrypted password manager with restricted access). The root account should only be used for the handful of tasks that specifically require it, such as changing the account’s support plan or closing the account.

Phase 2: Set Up Proper IAM Identity Management

Now that root is locked away, you need a secure way for humans and services to interact with the account.

5. Create an IAM Admin User or Use AWS IAM Identity Center

Create a dedicated IAM user (or, even better, use IAM Identity Center if you’re working within AWS Organizations) with administrative permissions. This is the identity you’ll use for day-to-day management — not root.

If you’re managing a single account, an IAM user in the “Administrators” group is sufficient. If you’re managing multiple accounts, invest the time to set up IAM Identity Center (formerly AWS SSO) from the start. It will save you enormous headaches later.

6. Enable MFA for All Human IAM Users

Every person who can log into the AWS console should have MFA enabled. No exceptions. Consider creating an IAM policy that denies all actions until MFA is activated, which encourages users to set it up immediately upon first login.

7. Apply the Principle of Least Privilege

Resist the temptation to give every user or role full admin access. Start with the minimum permissions required for each person or service, and expand only when there is a justified need. Use AWS managed policies as a starting point, but review what they allow. The “PowerUserAccess” policy, for example, is far more permissive than most people realize.

8. Create an IAM Password Policy

Configure a strong password policy for IAM users in your account. Enforce minimum length (at least 14 characters), require a mix of character types, and enable password expiration if your organization requires it. This is found under IAM > Account settings.

Phase 3: Enable Logging and Monitoring

You can’t protect what you can’t see. Visibility into account activity is non-negotiable.

9. Enable AWS CloudTrail in All Regions

CloudTrail records every API call made in your account. It’s your audit trail, your forensic evidence, and your early warning system. Create a trail that applies to all regions and logs to a dedicated S3 bucket. Enable log file validation so you can verify that logs haven’t been tampered with.

This is one of those services that costs very little but provides enormous value. Do not skip it.

10. Enable CloudTrail Log File Integrity Validation

When you set up CloudTrail, enable digest file delivery. This allows you to later verify that no log files were modified or deleted after delivery. In the event of a security incident, you need to trust your logs.

11. Turn On AWS Config

AWS Config continuously monitors and records your resource configurations and evaluates them against rules. Enable it in all regions. It answers questions like: “When did this security group change?” and “Is this S3 bucket publicly accessible?”

You can start with the AWS Config conformance packs, which provide pre-built rule sets for common compliance frameworks.

12. Enable Amazon GuardDuty

GuardDuty is a threat detection service that analyzes CloudTrail logs, VPC flow logs, and DNS logs to identify malicious activity. It can detect things like cryptocurrency mining, compromised credentials, and unusual API calls. Enabling it takes about 30 seconds, and it starts working immediately.

There is a 30-day free trial, and the ongoing cost is typically very reasonable relative to the protection it provides.

13. Set Up Billing Alerts and Anomaly Detection

Security incidents often show up as billing anomalies first. Go to the Billing and Cost Management console and enable the following:

• AWS Budgets: Create a monthly budget with a threshold alert. Even a simple “notify me if my spend exceeds $50” can save you from a surprise bill.

• Cost Anomaly Detection: This service uses machine learning to detect unusual spending patterns and alert you automatically.

An unexpected spike in EC2 or Lambda charges could be the first sign that someone is using your account for unauthorized purposes.

Phase 4: Secure Your Network Defaults

Every new AWS account comes with default networking resources that are more permissive than you might want.

14. Review and Restrict Default Security Groups

Every VPC comes with a default security group that allows all outbound traffic and allows all inbound traffic from resources assigned to the same security group. While this isn’t publicly open, it’s more permissive than most workloads need. Adopt the practice of creating custom, purpose-specific security groups and never attaching the default security group to resources.

15. Delete or Ignore the Default VPC (Use Custom VPCs Instead)

The default VPC in each region comes with public subnets and an internet gateway already attached. It’s designed for convenience, not security. For any real workload, create a custom VPC with a deliberate network design — private subnets for backend services, public subnets only where necessary, and proper route table configuration.

You don’t necessarily need to delete the default VPC (some AWS services expect it to exist), but make a rule to never deploy production workloads into it.

16. Block Public Access to S3 at the Account Level

One of the most common AWS security headlines involves publicly exposed S3 buckets. AWS now provides an account-level setting called “S3 Block Public Access.” Enable all four options at the account level. If a specific bucket later needs public access (for static website hosting, for example), you can override it deliberately for that one bucket. The default should be locked down.

Phase 5: Establish Account-Level Protections

These steps create safety nets that protect you across the entire account.

17. Enable EBS Default Encryption

Navigate to the EC2 console and enable default EBS encryption for each region you plan to use. This ensures that every new EBS volume is encrypted automatically, without requiring the person launching the instance to remember to check a box. You can use the AWS-managed key or specify a customer-managed KMS key.

18. Configure Account-Level Contacts

Under Account Settings, make sure the security, billing, and operations contact fields are filled in with valid email addresses. AWS uses these contacts to reach you in the event of abuse notifications or security issues. If these emails go to an unmonitored inbox, you might miss a critical warning.

19. Enable AWS Security Hub (Optional but Recommended)

Security Hub aggregates findings from GuardDuty, Config, IAM Access Analyzer, and other services into a single dashboard. It also runs automated security checks against industry benchmarks like CIS AWS Foundations. If you’ve already enabled the services listed above, Security Hub ties everything together and gives you a centralized security posture score.

20. Enable IAM Access Analyzer

IAM Access Analyzer helps you identify resources in your account that are shared with an external entity — for example, an S3 bucket policy that grants access to another AWS account, or an IAM role that can be assumed externally. Enable it in each region. It runs continuously and alerts you when it finds unintended external access.

Phase 6: Plan for the Worst

Security isn’t just about prevention. You also need to prepare for the possibility that something goes wrong.

21. Document Your Incident Response Plan

Even a simple one-page document is better than nothing. Answer these questions in advance:

• Who is responsible for responding to a security alert?

• How do we revoke compromised credentials?

• Where are our logs stored and how do we access them?

• Who do we contact at AWS for support?

Under pressure during an incident is the worst time to figure out these answers.

22. Know How to Contact AWS Support

If your account is compromised, you may need to contact AWS quickly. Make sure you know how to open a support case, and consider whether your current support plan (Basic, Developer, Business, or Enterprise) provides the response time you’d need in an emergency. Business-level support or above gives you 24/7 access to Cloud Support Engineers.

23. Create an Emergency “Break Glass” Procedure for Root Access

Since you’ve locked down root access (as described in Phase 1), document the procedure for accessing it in an emergency. Who has access to the password vault? Where is the MFA device stored? What approvals are needed? This should be written down, tested, and reviewed periodically.

Final Thoughts

None of these steps are difficult. Most take less than five minutes. But together, they form a security foundation that will protect you from the vast majority of common AWS threats.

The most expensive security incident is the one you could have prevented with ten minutes of configuration on day one. Don’t learn that lesson the hard way.

Bookmark this checklist. Share it with your team. Run through it every time a new account is created. Your future self will thank you.

In this article, we’ll break down the differences between SQL and NoSQL databases on AWS, explore the main services available, and give you a practical decision framework so you can choose with confidence.

Understanding the Fundamentals

Before diving into AWS services, let’s make sure we’re on the same page about what sets these two paradigms apart.

SQL (Relational Databases)

Relational databases store data in tables with predefined schemas made up of rows and columns. They use Structured Query Language (SQL) to query and manipulate data and enforce relationships between tables through foreign keys and joins.

Key characteristics:

• Structured schema: You define your tables, columns, and data types upfront.

• ACID compliance: Transactions are Atomic, Consistent, Isolated, and Durable.

• Strong consistency: Reads always return the most recent write.

• Vertical scaling: Traditionally scaled by adding more power (CPU, RAM) to a single server.

• Complex queries: Excellent support for JOINs, aggregations, and ad-hoc queries.

NoSQL (Non-Relational Databases)

NoSQL databases break away from the rigid tabular model. They come in several flavors, document, key-value, wide-column, and graph, each optimized for different access patterns.

Key characteristics:

• Flexible schema: Fields can vary from record to record.

• BASE model: Basically Available, Soft state, Eventually consistent.

• Horizontal scaling: Designed to scale out across many nodes.

• High throughput: Optimized for massive read/write workloads.

• Simple queries: Best suited for known access patterns rather than ad-hoc queries.

SQL Databases on AWS

Amazon RDS (Relational Database Service)

Amazon RDS is a managed service that supports six popular relational engines:

• MySQL

• PostgreSQL

• MariaDB

• Oracle

• SQL Server

• Amazon Aurora (MySQL & PostgreSQL compatible)

When to use RDS:

• Your data is highly relational with complex relationships.

• You need ACID-compliant transactions (e.g., financial systems).

• Your team is experienced with SQL.

• You want a managed service but with a traditional relational model.

Example use cases: E-commerce order management, HR systems, CMS platforms, ERP systems.

Amazon Aurora

Aurora deserves special attention. It’s AWS’s cloud-native relational database, compatible with MySQL and PostgreSQL but re-engineered for the cloud.

Why Aurora stands out:

• 5x throughput of standard MySQL, 3x of standard PostgreSQL.

• Storage auto-scales up to 128 TB.

• 6-way replication across 3 Availability Zones.

• Supports up to 15 read replicas with minimal lag.

• Aurora Serverless v2 scales capacity automatically based on demand.

When to use Aurora over standard RDS:

• You need higher performance and availability.

• Your workload has unpredictable traffic (Aurora Serverless).

• You want automatic storage scaling.

NoSQL Databases on AWS

Amazon DynamoDB

DynamoDB is AWS’s flagship fully managed key-value and document database. It’s designed for applications that need consistent, single-digit millisecond latency at any scale.

Key features:

• Serverless: No servers to manage, patch, or provision.

• Auto-scaling: Throughput adjusts to traffic automatically (on-demand mode).

• Global Tables: Multi-region, multi-active replication.

• DAX (DynamoDB Accelerator): In-memory caching for microsecond reads.

• Streams: Capture item-level changes for event-driven architectures.

When to use DynamoDB:

• You need extreme scale and low latency.

• Your access patterns are well-defined and predictable.

• You’re building serverless applications (Lambda + API Gateway + DynamoDB).

• You need a simple key-value or document store.

Example use cases: Gaming leaderboards, IoT telemetry, session management, shopping carts, real-time bidding.

Amazon DocumentDB (MongoDB Compatible)

If your team already uses MongoDB, DocumentDB provides a managed, MongoDB-compatible document database.

When to use DocumentDB:

• You’re migrating from MongoDB.

• You need flexible JSON document storage with rich query capabilities.

• You want managed infrastructure without running your own MongoDB clusters.

Amazon ElastiCache (Redis & Memcached)

ElastiCache provides in-memory key-value stores for caching and real-time workloads.

When to use ElastiCache:

• You need sub-millisecond response times.

• You’re caching frequently accessed data from another database.

• You need real-time features like session stores, pub/sub messaging, or leaderboards.

Amazon Neptune

Neptune is a graph database for highly connected datasets.

When to use Neptune:

• Social networks, recommendation engines, fraud detection.

• Your queries involve traversing complex relationships between entities.

Head-to-Head Comparison

Decision Framework: 7 Questions to Ask Yourself

Use these questions to guide your choice:

1. How relational is your data?

Highly relational (many joins, foreign keys, normalized tables) → SQL
Loosely structured or denormalized → NoSQL

2. How complex are your queries?

Need ad-hoc queries, complex reporting, aggregations → SQL
Known, simple access patterns (get by key, query by index) → NoSQL

3. What’s your scale?

Moderate, predictable traffic → SQL (RDS/Aurora) handles this well
Massive, spiky, or unpredictable traffic → NoSQL (DynamoDB) scales seamlessly

4. What are your latency requirements?

Single-digit millisecond → Both work
Microsecond → DynamoDB + DAX or ElastiCache

5. Do you need ACID transactions?

Complex multi-table transactions → SQL
Simple transactions → DynamoDB Transactions may be sufficient

6. Are you building serverless?

DynamoDB integrates natively with Lambda, API Gateway, and EventBridge.
RDS in serverless architectures can be problematic (connection limits), though Aurora Serverless v2 and RDS Proxy help.

7. What’s your budget model preference?

Predictable monthly cost → RDS (reserved instances)
Pay-per-use → DynamoDB on-demand mode

Real-World Scenarios

Scenario 1: E-Commerce Platform

Requirements: Product catalog, orders, inventory, payments.

Recommendation: Aurora PostgreSQL + DynamoDB (hybrid)

• Use Aurora for orders and payments (ACID transactions, complex queries).

• Use DynamoDB for the product catalog and shopping cart (high read throughput, flexible attributes).

• Use ElastiCache Redis for session management and caching.

Scenario 2: Real-Time Gaming Backend

Requirements: Leaderboards, player profiles, matchmaking, millions of concurrent users.

Recommendation: DynamoDB

• Scales horizontally to handle millions of players.

• Single-digit millisecond latency for leaderboard reads/writes.

• Global Tables for multi-region play.

Scenario 3: Financial Reporting System

Requirements: Complex queries, regulatory compliance, audit trails, historical analysis.

Recommendation: Aurora PostgreSQL

• Full ACID compliance for transaction integrity.

• Complex SQL queries for financial reporting.

• Point-in-time recovery for audit requirements.

Scenario 4: IoT Data Platform

Requirements: Millions of devices sending telemetry every second.

Recommendation: DynamoDB + Amazon Timestream

• DynamoDB for device state and metadata.

• Timestream (purpose-built time-series DB) for telemetry data.

The Hybrid Approach: Why Not Both?

In practice, many production systems on AWS use both SQL and NoSQL databases. This is called polyglot persistence, using the best database for each specific job.

┌──────────────┐     ┌──────────────────┐     ┌──────────────┐
│   Frontend   │────▶│   API Gateway +  │────▶│  DynamoDB    │
│   (React)    │     │   Lambda         │     │  (Catalog,   │
└──────────────┘     └──────┬───────────┘     │   Sessions)  │
                            │                 └──────────────┘
                            │
                            ▼
                     ┌──────────────────┐     ┌──────────────┐
                     │   ECS / EKS      │────▶│  Aurora       │
                     │   (Order Service)│     │  (Orders,    │
                     └──────────────────┘     │   Payments)  │
                                              └──────────────┘

Tips for a hybrid approach:

• Use DynamoDB for high-throughput, simple-access workloads.

• Use Aurora for transactional and reporting workloads.

• Use ElastiCache as a caching layer in front of either.

• Use Amazon EventBridge or DynamoDB Streams to sync data between databases when needed.

Final Thoughts

There’s no universal “best” database, only the best database for your specific use case. The most important thing is to start with your access patterns and requirements, not with the technology.

Ask yourself:

• What does my data look like?

• How will I query it?

• How much will it scale?

• What consistency guarantees do I need?

Let the answers guide you to the right choice. And remember, on AWS, you’re never locked into one paradigm. Embrace polyglot persistence and use the right tool for each job.

Here’s the truth: VPCs are simpler than they seem. Once you understand the core concepts and how they fit together, everything else clicks into place. The terminology can feel overwhelming at first, CIDR blocks, route tables, gateways, but each of these is just a small, logical piece of a bigger puzzle. This guide will walk you through VPCs step-by-step, with visual explanations that make sense. By the end, you won’t just understand VPCs, you’ll understand why they’re designed the way they are.

What Is a VPC, Really?

Think of a VPC as your own private section of the AWS cloud. It’s like having your own data center, but virtual. Inside this space, you can launch AWS resources (like EC2 instances, databases, and Lambda functions) and control exactly how they communicate with each other and the outside world.

To make this even more concrete, imagine you’re renting an entire floor in a massive office building. The building is AWS’s cloud infrastructure, shared among millions of tenants. But your floor? That’s entirely yours. You decide how to partition the rooms, who gets access to what, which doors lead outside, and which rooms are locked away from public view. Other tenants can’t wander into your space, and you can’t wander into theirs, unless you both explicitly agree to connect your floors together.

Every AWS account comes with a default VPC in each region, pre-configured so you can start launching resources immediately. However, for production workloads, you’ll almost always want to create a custom VPC where you have full control over the network design. The default VPC is convenient for experimentation, but it makes assumptions about your architecture that may not align with your security or organizational needs.

The key benefit: Complete control over your network environment, IP addresses, subnets, route tables, and network gateways. You decide what’s exposed, what’s hidden, and how every piece communicates.

The Building Blocks

Let’s break down the essential components you need to understand:

1. VPC (Virtual Private Cloud)

What it is: The container for your entire network. It’s the foundational layer upon which everything else is built.

Key details:

• You define an IP address range using CIDR notation (e.g., 10.0.0.0/16). CIDR stands for Classless Inter-Domain Routing, and it’s simply a compact way of expressing a range of IP addresses. The /16 part is called the prefix length and determines how many IP addresses are available within the range. A smaller number after the slash means a larger network, /16 gives you 65,536 addresses, while /24 gives you only 256.

• Choosing your CIDR block is one of the most important early decisions because you cannot change it after creation (though you can add secondary CIDR blocks later). If you choose a range that’s too small, you’ll run out of IP addresses as your infrastructure grows. If you choose one that overlaps with another VPC or your on-premises network, you’ll run into conflicts when you try to connect them later.

• Each VPC is isolated from other VPCs by default. This is a fundamental security property. Even if two VPCs use the exact same CIDR block, they cannot communicate unless you explicitly set up a connection between them (using VPC Peering or a Transit Gateway). This isolation means a misconfiguration in one VPC won’t accidentally leak traffic into another.

• A VPC exists within a single AWS Region but spans all of that region’s Availability Zones. This is important: your VPC isn’t confined to a single data center. It’s a regional construct that gives you the ability to distribute resources across multiple physically separated facilities.

Visual concept:

┌───────────────────────────────────┐
│         VPC (10.0.0.0/16)         │
│                                   │
│  [Your AWS resources live here]   │
│                                   │
└───────────────────────────────────┘

2. Subnets

What they are: Subdivisions of your VPC’s IP address range. If the VPC is your floor in the office building, subnets are the individual rooms you create within it.

Why you need them: To organize resources and control access to the internet. Subnets give you the ability to apply different network rules and routing behaviors to different groups of resources. Without subnets, every resource in your VPC would have to follow the same networking rules, and that’s not practical when some resources need public exposure and others need to stay hidden.

Two types:

• Public subnets: Resources here can communicate directly with the internet. These are for things that need to be reachable by users or external systems, web servers, load balancers, bastion hosts, and similar front-facing infrastructure.

• Private subnets: Resources here cannot directly access the internet and, crucially, cannot be directly reached from the internet. This makes them far more secure. These are ideal for databases, application servers, internal microservices, caches, and anything that doesn’t need a public-facing presence.

It’s important to understand that there’s nothing inherently “public” or “private” about a subnet itself. What makes a subnet public or private is its route table configuration, specifically, whether its route table includes a route to an Internet Gateway. This is a common source of confusion for beginners who think the distinction is set at creation time.

Each subnet lives within a single Availability Zone and cannot span multiple AZs. This is by design, it allows AWS to provide strong isolation guarantees. If one AZ experiences issues, subnets in other AZs remain unaffected. This is why best practice dictates creating matching subnets across multiple Availability Zones, so your application can survive the loss of an entire data center.

Each subnet also has a small number of reserved IP addresses that AWS uses for internal purposes. In every subnet, the first four IP addresses and the last IP address are reserved. For a /24 subnet (256 addresses), that means 251 are actually usable. This is a small detail, but it matters when you’re planning tightly-sized subnets.

Visual concept:

┌──────────────────────────────────────────────┐
│              VPC (10.0.0.0/16)               │
│                                              │
│  ┌──────────────────┐  ┌──────────────────┐  │
│  │  Public Subnet   │  │  Private Subnet  │  │
│  │  10.0.1.0/24     │  │  10.0.2.0/24     │  │
│  │                  │  │                  │  │
│  │  [Web Servers]   │  │  [Databases]     │  │
│  └──────────────────┘  └──────────────────┘  │
│                                              │
└──────────────────────────────────────────────┘

Best practice: Create subnets in multiple Availability Zones for high availability. A common pattern is to have at least two public subnets and two private subnets, each pair spread across two different AZs. Some organizations go further and use three AZs for even greater resilience.

3. Internet Gateway (IGW)

What it is: The door between your VPC and the public internet. It’s a horizontally scaled, redundant, and highly available component managed entirely by AWS.

What it does: Allows resources in public subnets to communicate with the internet, both sending requests out and receiving requests in. Without an Internet Gateway, your VPC is a completely sealed-off network with no path to the outside world.

The Internet Gateway serves two critical functions. First, it acts as a target in your route table for internet-bound traffic, giving your resources a path to follow when they need to reach an external address. Second, it performs Network Address Translation (NAT) for instances that have been assigned a public IPv4 address. When traffic leaves your instance, the IGW replaces the private IP with the public IP; when responses come back, it reverses the translation. This is why simply attaching an IGW isn’t enough, your instances also need public IP addresses (or Elastic IPs) and the correct route table entries to actually use it.

Visual concept:

                    Internet
                       ↕
              ┌────────────────┐
              │ Internet       │
              │ Gateway (IGW)  │
              └────────────────┘
                       ↕
┌────────────────────────────────────┐
│           VPC (10.0.0.0/16)        │
│                                    │
│  ┌────────────────┐                │
│  │ Public Subnet  │                │
│  │ 10.0.1.0/24    │                │
│  │                │                │
│  │ [Web Server]   │                │
│  └────────────────┘                │
└────────────────────────────────────┘

Key point: You attach one IGW per VPC. You cannot attach multiple Internet Gateways to the same VPC, and you cannot share an IGW across VPCs. It’s a one-to-one relationship. Without it, nothing in your VPC can reach the internet, and nothing on the internet can reach your VPC. It’s also worth noting that the IGW itself doesn’t impose bandwidth limits or become a bottleneck, AWS manages its scaling transparently.

4. Route Tables

What they are: Sets of rules (called routes) that determine where network traffic is directed. Every single packet of data that moves through your VPC is guided by a route table.

How they work: Each subnet is associated with exactly one route table, and that route table tells traffic where to go based on its destination. When a resource in your subnet sends a packet, the VPC examines the destination IP address, looks it up in the route table, and forwards the packet to the matching target. If there are multiple matching routes, the most specific route (the one with the longest prefix) wins.

Every VPC comes with a main route table automatically. Any subnet that isn’t explicitly associated with a custom route table will use the main route table by default. This is a subtle but important point, it means newly created subnets silently inherit the main route table’s behavior. For this reason, many practitioners recommend keeping the main route table restrictive (private) and explicitly assigning custom route tables with internet access only to the subnets that need it. This way, if someone creates a new subnet and forgets to assign a route table, it defaults to private rather than accidentally becoming public.

Example routes:

• 10.0.0.0/16 → local : Traffic destined for any IP within the VPC stays inside the VPC. This route is automatically present in every route table and cannot be removed. It’s what allows your resources to communicate with each other across subnets.

• 0.0.0.0/0 → igw-xxxxx : All other traffic (anything not matching a more specific route) goes to the Internet Gateway. This is the route that makes a subnet “public.” The 0.0.0.0/0 destination is a catch-all, often called the default route.

Visual concept:

Public Subnet Route Table:
┌─────────────────┬──────────────┐
│ Destination     │ Target       │
├─────────────────┼──────────────┤
│ 10.0.0.0/16     │ local        │
│ 0.0.0.0/0       │ igw-xxxxx    │
└─────────────────┴──────────────┘

Private Subnet Route Table:
┌─────────────────┬──────────────┐
│ Destination     │ Target       │
├─────────────────┼──────────────┤
│ 10.0.0.0/16     │ local        │
└─────────────────┴──────────────┘

The difference: Public subnets have a route to the IGW; private subnets don’t. That single route entry is literally the only thing that separates a “public” subnet from a “private” one. Route tables can also contain routes pointing to other targets like NAT Gateways, VPC Peering connections, Transit Gateways, VPN connections, and VPC endpoints, which is how more complex architectures are built.

5. NAT Gateway

What it is: A managed service that allows resources in private subnets to initiate outbound connections to the internet (for software updates, API calls, downloading patches, etc.) without exposing them to inbound internet traffic. It performs Network Address Translation, replacing the private IP address of the originating resource with its own public IP address before forwarding the request to the internet.

Why you need it: Your database in a private subnet needs to download security patches, your application server needs to call a third-party API, or your Lambda function in a private subnet needs to reach an external webhook. But you don’t want any of these resources to be directly reachable from the internet. The NAT Gateway solves this by acting as a one-way intermediary, it allows traffic out but blocks unsolicited traffic in.

Visual concept:

                    Internet
                       ↕
              ┌────────────────┐
              │ Internet       │
              │ Gateway (IGW)  │
              └────────────────┘
                       ↕
┌──────────────────────────────────────────────┐
│              VPC (10.0.0.0/16)               │
│                                              │
│  ┌────────────────┐    ┌─────────────────┐   │
│  │ Public Subnet  │    │ Private Subnet  │   │
│  │ 10.0.1.0/24    │    │ 10.0.2.0/24     │   │
│  │                │    │                 │   │
│  │ [NAT Gateway]  │←───│ [Database]      │   │
│  └────────────────┘    └─────────────────┘   │
│                                              │
└──────────────────────────────────────────────┘

How it works:

1. The database initiates an outbound connection (e.g., to download a security patch).

2. The private subnet’s route table sends internet-bound traffic (0.0.0.0/0) to the NAT Gateway in the public subnet.

3. The NAT Gateway replaces the database’s private IP address with its own public Elastic IP address and forwards the traffic to the Internet Gateway.

4. The IGW sends the request out to the internet.

5. The response comes back through the same path in reverse, IGW to NAT Gateway, which translates the address back and forwards the response to the database.

The key security property here is that while the database can reach out to the internet, no one on the internet can initiate a connection to the database. The NAT Gateway will simply drop any unsolicited inbound traffic.

Important architectural consideration: A NAT Gateway is deployed into a specific subnet within a specific Availability Zone. If that AZ goes down, resources in private subnets in other AZs that depend on that NAT Gateway will lose their internet access. This is why production architectures deploy a NAT Gateway in each AZ and configure each private subnet to route through the NAT Gateway in its own AZ. This adds cost but ensures that an AZ failure doesn’t cascade into a networking failure for your private resources.

Cost note: NAT Gateways cost approximately $0.045/hour (about $32/month) plus data processing charges of $0.045 per GB. In a multi-AZ setup with two NAT Gateways, that’s roughly $64/month before any data transfer. For learning environments or development workloads, you can use a NAT Instance (a regular EC2 instance configured to perform NAT) to save money, though it won’t offer the same availability, bandwidth, or managed maintenance that a NAT Gateway provides. Some teams also explore VPC endpoints as a way to avoid NAT Gateway costs entirely for traffic destined to supported AWS services like S3 or DynamoDB.

6. Security Groups

What they are: Virtual firewalls that control inbound and outbound traffic at the instance level (more precisely, at the network interface level). Every EC2 instance, RDS database, Lambda function in a VPC, and many other AWS resources are associated with one or more Security Groups.

How they work: You define rules that allow specific traffic. This is an important distinction: Security Groups are allow-only. You cannot write a rule that explicitly denies traffic. If traffic doesn’t match any allow rule, it is implicitly denied. This makes Security Groups relatively straightforward to reason about, if it’s not explicitly permitted, it’s blocked.

Example rules:

Web Server Security Group:
Inbound:
- Allow HTTP (port 80) from 0.0.0.0/0 (anywhere)
- Allow HTTPS (port 443) from 0.0.0.0/0
- Allow SSH (port 22) from your IP only

Outbound:
- Allow all traffic (default)

Database Security Group:
Inbound:
- Allow MySQL (port 3306) from Web Server Security Group only

Outbound:
- Allow all traffic

One of the most powerful features of Security Groups is the ability to reference other Security Groups as sources or destinations in your rules. In the example above, the database Security Group doesn’t allow MySQL traffic from a specific IP address, it allows it from any resource associated with the Web Server Security Group. This means if you add a new web server and attach the same Security Group, it automatically gains database access without any rule changes. This creates a dynamic, self-maintaining security model that scales with your infrastructure.

Key concept: Security Groups are stateful, if you allow inbound traffic on a port, the corresponding response traffic is automatically allowed outbound, regardless of the outbound rules. Likewise, if an instance initiates an outbound connection, the response is automatically allowed inbound. This means you don’t need to worry about creating matching rules for both directions of a conversation, which significantly reduces the complexity of your firewall configuration.

Another important behavior: Security Groups evaluate all rules before making a decision. Unlike NACLs (which process rules in order and stop at the first match), Security Groups aggregate all rules and allow traffic if any rule permits it. This means you never have to worry about rule ordering within a Security Group.

7. Network ACLs (NACLs)

What they are: An additional layer of security that operates at the subnet level. While Security Groups wrap around individual resources, NACLs wrap around entire subnets, filtering traffic as it enters and exits the subnet boundary.

Difference from Security Groups:

• NACLs are stateless, you must explicitly write rules for both inbound and outbound traffic. If you allow inbound HTTP traffic on port 80, you must also create an outbound rule allowing the response traffic (which typically uses an ephemeral port in the range 1024–65535). Forgetting the outbound rule is one of the most common NACL mistakes, and it results in traffic appearing to be silently dropped.

• NACLs support both allow and deny rules, unlike Security Groups which only support allow rules. This makes NACLs useful for explicitly blocking specific IP addresses or ranges, for example, blocking a known malicious IP that’s attempting to probe your infrastructure.

• NACLs process rules in order, starting from the lowest numbered rule and stopping at the first match. This means rule ordering matters significantly. A common pattern is to use low-numbered rules (like 100, 200, 300) for your specific allow/deny rules, leaving gaps so you can insert new rules later without renumbering everything.

• NACLs apply to all resources within a subnet automatically. You don’t attach a NACL to an individual instance, every resource in the subnet is subject to the NACL’s rules, with no exceptions.

• Each subnet must be associated with exactly one NACL. If you don’t explicitly assign one, the subnet uses the VPC’s default NACL, which allows all inbound and outbound traffic. Custom NACLs, by contrast, deny all traffic by default until you add rules, another common gotcha for beginners.

Think of NACLs and Security Groups as two concentric walls of defense. Traffic entering a subnet first passes through the NACL. If the NACL allows it, the traffic then reaches the Security Group attached to the target resource. Both must permit the traffic for it to get through. This is an example of defense in depth, even if one layer is misconfigured, the other layer can still provide protection.

When to use them: Most beginners can stick with Security Groups for day-to-day access control. NACLs are most useful when you need subnet-wide rules, when you need to explicitly deny traffic from specific sources, or when your organization’s compliance requirements mandate multiple layers of network filtering. In many production environments, NACLs are kept relatively permissive while Security Groups do the heavy lifting of fine-grained access control.

Putting It All Together: A Complete VPC Architecture

Here’s a production-ready VPC setup:

                         Internet
                            ↕
                   ┌────────────────┐
                   │ Internet       │
                   │ Gateway (IGW)  │
                   └────────────────┘
                            ↕
┌─────────────────────────────────────────────────────┐
│                  VPC (10.0.0.0/16)                  │
│                                                     │
│  Availability Zone A          Availability Zone B   │
│  ┌──────────────────┐        ┌──────────────────┐   │
│  │ Public Subnet    │        │ Public Subnet    │   │
│  │ 10.0.1.0/24      │        │ 10.0.3.0/24      │   │
│  │                  │        │                  │   │
│  │ [Web Server A]   │        │ [Web Server B]   │   │
│  │ [NAT Gateway A]  │        │ [NAT Gateway B]  │   │
│  └──────────────────┘        └──────────────────┘   │
│          ↕                           ↕              │
│  ┌──────────────────┐        ┌──────────────────┐   │
│  │ Private Subnet   │        │ Private Subnet   │   │
│  │ 10.0.2.0/24      │        │ 10.0.4.0/24      │   │
│  │                  │        │                  │   │
│  │ [Database A]     │        │ [Database B]     │   │
│  └──────────────────┘        └──────────────────┘   │
│                                                     │
└─────────────────────────────────────────────────────┘

Why this architecture works:

• High availability: Resources are distributed across multiple Availability Zones. If AZ-A experiences a hardware failure, a power outage, or a network issue, AZ-B continues to serve traffic. Your application stays online because it doesn’t depend on any single physical location.

• Security: Databases sit in private subnets with no direct internet access. The only way to reach them is through the web servers (controlled by Security Groups) or via internal networking. This dramatically reduces the attack surface for your most sensitive data.

• Internet access: NAT Gateways in each AZ ensure that private resources can still reach the internet for necessary outbound tasks, operating system patches, third-party API calls, package downloads, without compromising their isolation from inbound internet traffic. Each private subnet routes through the NAT Gateway in its own AZ, so an AZ failure doesn’t cut off internet access for the other AZ’s private resources.

• Scalability: An Application Load Balancer (which would sit in the public subnets) distributes incoming user traffic across web servers in both AZs. As demand grows, you can add more instances behind the load balancer, or use Auto Scaling Groups to add and remove them automatically based on metrics like CPU utilization or request count.

This architecture is often extended with additional subnet tiers. Many organizations add a third tier, sometimes called an “isolated” or “data” tier, for resources that should have no internet access at all, not even outbound. You might also see dedicated subnets for things like Elasticache clusters, internal load balancers, or container orchestration infrastructure. The pattern stays the same; you’re just adding more rooms to the floor plan.

Conclusion

VPCs don’t have to be intimidating. At their core, they’re built from a handful of straightforward concepts: a VPC gives you an isolated network, subnets help you organize and secure your resources, an Internet Gateway connects you to the outside world, route tables direct traffic, NAT Gateways let private resources reach the internet safely, and Security Groups and NACLs act as your gatekeepers.

Once you understand how these pieces snap together, you’re not just following tutorials, you’re making informed decisions about how your infrastructure should work. You’ll understand why a database should live in a private subnet, why a route table needs a specific entry, and why Security Groups reference each other instead of hard-coded IP addresses.

Here’s what I’d recommend as your next steps:

• Get hands-on. Create a VPC from scratch in the AWS Console (not the default one). Set up a public subnet, a private subnet, an Internet Gateway, and a route table. Launch an EC2 instance in the public subnet and verify you can SSH into it. Then launch one in the private subnet and observe that you can’t. Break things on purpose, remove the route to the IGW and see what happens. Remove the Security Group rule for SSH and watch the connection fail. These small experiments will teach you more than reading ever could.

• Start simple. You don’t need multi-AZ NAT Gateways on day one. Build the basic architecture first, one public subnet, one private subnet, one AZ. Get comfortable with how traffic flows. Then layer in high availability by duplicating the setup across a second AZ. Add a load balancer. Add a NAT Gateway. Each addition will make more sense because you understand the foundation it’s building on.

• Explore Infrastructure as Code. Once you’re comfortable building VPCs manually, try recreating the same setup with CloudFormation or Terraform. Defining your VPC in code forces you to understand every dependency and every relationship between components, you can’t click “next” and let the console fill in defaults. It’ll solidify your understanding and make your infrastructure repeatable, version-controlled, and shareable with your team.

• Learn about VPC connectivity options. Once your single-VPC architecture is solid, start exploring how VPCs connect to each other and to the outside world. VPC Peering lets two VPCs communicate directly. Transit Gateway simplifies networking when you have many VPCs. VPN connections and AWS Direct Connect link your VPC to on-premises data centers. VPC Endpoints let your private resources access AWS services like S3 and DynamoDB without traversing the internet at all. Each of these builds directly on the concepts you’ve learned here.

The production-ready architecture we walked through above isn’t just a diagram, it’s the foundation that most real-world AWS applications are built on. Every load balancer, container cluster, and serverless application you’ll work with in the future sits inside a VPC. By understanding these fundamentals now, you’re setting yourself up to build cloud infrastructure that’s secure, scalable, and resilient from the start.

This article walks you through the complete flow of deploying a containerized application using Amazon ECS with Fargate. No servers to manage. No cluster capacity to worry about. Just your application running in containers.

By the end, you will understand each component and how they connect together.

What Are ECS and Fargate?

Amazon ECS

Elastic Container Service (ECS) is a container orchestration platform from AWS. It handles the scheduling, deployment, and management of your containers. Think of it as the brain that decides where and how your containers run.

AWS Fargate

Fargate is a serverless compute engine for containers. Instead of provisioning EC2 instances and managing their capacity, you simply tell AWS how much CPU and memory your container needs. Fargate handles the underlying infrastructure.

When you combine ECS with Fargate, you get container orchestration without server management.

Architecture Overview

Before diving into the steps, let us look at the components involved.

The Complete Flow

Step 1: Prepare Your Application for Containerization

Start with your application. Whether it is a web API, a backend service, or a worker process, you need to package it into a container image.

Create a Dockerfile in your project root. This file contains instructions for building your container image. Define the base image, copy your application files, install dependencies, and specify the command to run your application.

Keep images small. Use multi-stage builds if needed. Smaller images mean faster deployments and lower costs.

Step 2: Create an ECR Repository

Amazon Elastic Container Registry stores your container images. Before pushing images, you need a repository.

Navigate to the ECR console and create a new private repository. Choose a meaningful name that reflects your application. Enable image scanning to automatically check for vulnerabilities when images are pushed.

Configure lifecycle policies to automatically clean up old images. This prevents storage costs from growing indefinitely.

Step 3: Build and Push Your Image

Build your container image locally using Docker. Tag the image with your ECR repository URI. The tag should include a version identifier such as a git commit hash or semantic version number.

Authenticate Docker with ECR using the AWS CLI. This generates temporary credentials that allow Docker to push images.

Push the tagged image to your ECR repository. Verify the push succeeded by checking the repository in the console.

Step 4: Set Up the Network Infrastructure

Your containers need a network to run in. Create a VPC or use an existing one.

Design your subnets carefully. Place your Fargate tasks in private subnets. They do not need direct internet access. Place the Application Load Balancer in public subnets so it can receive traffic from the internet.

Create a NAT Gateway in a public subnet. Your tasks in private subnets need this to pull images from ECR and access other AWS services.

Configure security groups. Create one for the load balancer that allows inbound traffic on your application port. Create another for the Fargate tasks that only allows traffic from the load balancer security group.

Step 5: Create IAM Roles

ECS requires two types of IAM roles.

The task execution role allows ECS to pull images from ECR, send logs to CloudWatch, and retrieve secrets from Secrets Manager or Parameter Store. AWS provides a managed policy called AmazonECSTaskExecutionRolePolicy that covers most use cases.

The task role is what your application uses at runtime. Attach policies based on what AWS services your application needs to access. If your app reads from S3, add S3 read permissions. If it writes to DynamoDB, add those permissions. Follow the principle of least privilege.

Step 6: Create an ECS Cluster

The cluster is a logical grouping for your services and tasks. Navigate to the ECS console and create a new cluster.

Give it a descriptive name. Enable Container Insights if you want detailed metrics and logs. This adds cost but provides valuable observability.

With Fargate, the cluster is essentially just a namespace. There are no EC2 instances to manage.

Step 7: Define Your Task Definition

The task definition is a blueprint for your container. It describes how your container should run.

Specify the following:

Family name: A unique identifier for your task definition. New revisions will share this name.

Launch type: Select Fargate.

CPU and memory: Choose appropriate values based on your application requirements. Fargate has specific combinations available.

Container definition: Provide the ECR image URI, container port mappings, environment variables, and log configuration.

Networking mode: Use awsvpc mode. This is required for Fargate and gives each task its own elastic network interface.

Log configuration: Send logs to CloudWatch Logs. Create a log group beforehand or let ECS create one automatically.

Step 8: Create an Application Load Balancer

The load balancer distributes traffic across your tasks and provides a stable endpoint.

Create an Application Load Balancer in your public subnets. Configure listeners for HTTP on port 80 or HTTPS on port 443. For production, always use HTTPS with an ACM certificate.

Create a target group with the target type set to IP. This is required for Fargate. Configure health checks to verify your application is responding correctly.

Set the health check path to an endpoint your application exposes. Configure appropriate thresholds and intervals based on how quickly your application starts.

Step 9: Create the ECS Service

The service maintains the desired number of tasks and integrates with the load balancer.

Navigate to your cluster and create a new service. Select the task definition you created earlier.

Configure the following:

Launch type: Fargate.

Desired count: The number of tasks you want running. Start with two for high availability.

Deployment configuration: Use rolling updates. Set minimum healthy percent to 100 and maximum percent to 200. This ensures zero downtime during deployments.

Network configuration: Select your VPC, private subnets, and the security group for tasks. Enable auto-assign public IP only if tasks are in public subnets.

Load balancing: Select the Application Load Balancer and target group you created.

Service discovery: Optionally enable Cloud Map integration for internal service-to-service communication.

Step 10: Configure Auto Scaling

Your application should scale based on demand. ECS Service Auto Scaling adjusts the desired count automatically.

Configure target tracking scaling policies. Common metrics include:

CPU utilization: Scale when average CPU across tasks exceeds a threshold.

Memory utilization: Scale when memory usage grows.

Request count per target: Scale based on how many requests each task handles.

Set minimum and maximum task counts. The minimum ensures you always have capacity. The maximum prevents runaway scaling and unexpected costs.

Step 11: Set Up Logging and Monitoring

Observability is critical for production workloads.

Your tasks should already send logs to CloudWatch Logs based on the task definition configuration. Create CloudWatch alarms for key metrics such as CPU utilization, memory utilization, and running task count.

Enable Container Insights on your cluster for enhanced metrics. This provides task-level and container-level visibility.

Set up CloudWatch dashboards to visualize your application health at a glance.

Step 12: Verify the Deployment

Once the service is running, verify everything works correctly.

Check the ECS console. Your service should show the desired number of running tasks. If tasks are failing, check the stopped tasks for error messages.

Check the target group health. All registered targets should be healthy. If not, verify security group rules and health check configuration.

Access your application through the load balancer DNS name. Verify it responds as expected.

Deployment Flow for Updates

Once your initial deployment is complete, updating your application follows this flow:

1. Make changes to your application code

2. Build a new container image with a new tag

3. Push the image to ECR

4. Create a new task definition revision pointing to the new image

5. Update the ECS service to use the new task definition

6. ECS performs a rolling deployment automatically

7. Old tasks drain connections and stop

8. New tasks start and register with the load balancer

This process can be automated with CI/CD pipelines using services like CodePipeline, GitHub Actions, or GitLab CI.

Best Practices

Keep Images Lean

Smaller images deploy faster. Use minimal base images. Remove unnecessary files and dependencies.

Use Specific Image Tags

Never use the latest tag in production. Always use specific versions so deployments are predictable and rollbacks are possible.

Implement Health Checks

Define health checks at both the container level and load balancer level. This ensures traffic only routes to healthy tasks.

Store Secrets Securely

Never bake secrets into container images. Use Secrets Manager or Parameter Store. Reference them in your task definition and inject them as environment variables at runtime.

Plan for Failure

Run tasks across multiple availability zones. Set appropriate desired counts. Configure auto scaling to handle load spikes.

Monitor Costs

Fargate pricing is based on CPU and memory. Right-size your task definitions. Use Spot capacity for fault-tolerant workloads to reduce costs significantly.

Common Pitfalls to Avoid

Incorrect security group rules: Tasks cannot pull images or register with load balancers if security groups block traffic.

Missing NAT Gateway: Tasks in private subnets cannot reach ECR or other AWS services without a NAT Gateway or VPC endpoints.

Health check misconfiguration: If the health check path returns errors or times out, tasks will be marked unhealthy and constantly replaced.

Insufficient task role permissions: Your application will fail to access AWS services if the task role lacks required permissions.

Forgetting to update the service: Creating a new task definition revision does not automatically deploy it. You must update the service.

Conclusion

Deploying containers on ECS with Fargate removes the burden of managing servers while giving you full control over your application. The initial setup involves several components, but each serves a clear purpose.

Start with a simple deployment. Get it working end to end. Then iterate by adding auto scaling, improving monitoring, and building CI/CD pipelines.

The serverless nature of Fargate lets you focus on your application rather than infrastructure. You pay only for the resources your containers use, and scaling happens automatically based on your policies.

Now you have a clear roadmap. Pick your application and start building.

Introduction

Building a serverless platform often starts with just a few AWS Lambda functions. Over time, however, as new features are added and the platform evolves, that number can quickly grow into the hundreds. At that scale, managing, deploying, and maintaining Lambda functions becomes increasingly complex.

This is a common challenge organizations face as they scale serverless architectures. As the number of Lambda functions increases, so does the operational overhead. One of the most frequent questions we hear from customers is:

“How should we properly structure and organize a large number of Lambda functions?”

In this article, we present three practical architectural patterns that help teams organize Lambda functions at scale, enabling them to grow serverless applications while keeping complexity under control.

The Starting Point: Single-Purpose Lambda Functions

When organizations first adopt AWS Lambda, they typically follow a straightforward approach: one function per responsibility. We refer to these as single-purpose Lambda functions.

Consider a typical e-commerce architecture:

• GetProduct – Retrieve product details

• AddCart – Add items to a shopping cart

• RemoveCart – Remove items from the cart

• GetCart – View the cart

• SubmitOrder – Submit an order

• ReserveInventory – Reserve inventory

• ProcessPayment – Process payment

• FulfilOrder – Complete the order

Amazon API Gateway acts as the front door, exposing HTTP endpoints and routing requests to the appropriate Lambda functions. Each function persists its data in a dedicated DynamoDB table.

This approach is perfectly valid and widely used. However, as organizations add features and scale their platforms, they often end up with hundreds or even thousands of Lambda functions in a single repository.

At scale, this typically results in:

• A large, monolithic repository

• A single, complex CI/CD pipeline

• High deployment risk, where a failure impacts the entire system

To address these challenges, let’s explore three organizational patterns.

Pattern 1: Microservices

When all Lambda functions reside in a single repository backed by one AWS SAM template, complexity escalates quickly. Deployments become slow and risky, and ownership becomes unclear.

The solution is to apply microservices principles and bounded contexts to your serverless architecture.

Consider the cart-related functions: AddCart, RemoveCart, and GetCart. These functions:

• Operate on the same domain (shopping cart)

• Share the same data model and DynamoDB table

• Are typically owned by the same team

These functions clearly belong together. Instead of managing them independently, group them into a dedicated service, such as a cart-service.

Repeat this process for other domains, including product, order, inventory, and payment. Each domain becomes its own service with:

• A dedicated repository

• Its own AWS SAM template

• An independent CI/CD pipeline

In a true microservices architecture, services expose functionality through APIs rather than sharing infrastructure resources directly. As a result, SAM templates are typically self-contained and do not reference resources across services.

Benefits

This approach enables:

• Independent development and deployment – Teams can ship changes without impacting unrelated services

• Clear ownership – Each service has a well-defined boundary and responsible team

• Reduced coupling – Services only include the dependencies they require

This is the foundation for scaling serverless systems both technically and organizationally.

Pattern 2: Lambda Web Adapter

Even with improved organization, teams may still manage a large number of Lambda functions. In many cases, these functions can be consolidated.

This is where the Lambda Web Adapter pattern becomes valuable. Instead of creating one Lambda function per HTTP endpoint, you run a traditional web framework inside a single Lambda function and handle routing internally.

For example, AddCart and RemoveCart both update the same DynamoDB table and operate within the same domain. These can be combined into a single manage_cart function.

Inside that function, you can use familiar frameworks such Express.js, Next.js, Flask, Django, Spring Boot, ASP.NET, Laravel, and so on. The Lambda Web Adapter makes this possible.

Benefits

This pattern offers several advantages:

• Fewer cold starts – A single function replaces multiple endpoints

• Shared initialization – SDK clients and database connections are initialized once

• Familiar development model – Teams can use established web frameworks

• Simpler testing – Routing and logic can be tested locally without mocking Lambda events

A Word of Caution

Consolidation should be applied carefully. Overuse can result in a monolithic Lambda function that negates the benefits of serverless design.

Keep functions aligned to a bounded context, and continuously monitor:

• Function size

• Memory usage

• Execution time

Remember that a failure in a consolidated function can impact multiple operations.

When to Consolidate Functions

Consolidation is appropriate when functions:

• Share common dependencies or downstream services

• Have similar memory and performance requirements

• Share IAM permissions

• Have comparable initialization costs

If these factors align, consolidation is often beneficial.

Pattern 3: API Gateway Direct Integration

A common anti-pattern in serverless architectures is the use of Lambda functions that simply proxy requests to downstream services without applying any business logic.

For example, the GetCart function that retrieves an item from DynamoDB and returns it without transformation adds little value.

In such cases, the Lambda function can be removed entirely and replaced with an API Gateway direct integration.

With direct integrations, API Gateway communicates directly with AWS services such as DynamoDB or Step Functions, and others, eliminating the need for an intermediate Lambda function.

Benefits

This pattern provides:

• Lower cost – No Lambda invocation charges

• Lower latency – One less hop in the request path

• No cold starts – API Gateway is always available

• Reduced operational overhead – Fewer functions to manage

When to Use This Pattern

Use direct integrations when:

• Performing simple CRUD operations

• No business logic or complex validation is required

• The goal is to minimize Lambda usage

Avoid this pattern when:

• Complex transformations are needed

• Business logic or orchestration is involved

• Advanced error handling is required

Recap

To organize Lambda functions effectively at scale, consider the following patterns:

1. Microservices Organization – Group related functions by domain into independent services and repositories

2. Lambda Web Adapter – Consolidate related functions inside a single Lambda function

3. API Gateway Direct Integration – Eliminate unnecessary Lambda functions for simple operations

Applying these patterns allows teams to move from:

• A single repository with scattered Lambda functions

• To a domain-driven, multi-repository architecture

• To fewer, more meaningful Lambda functions

• And, where appropriate, to no Lambda functions at all

Conclusion

Organizing Lambda functions at scale does not need to be overwhelming. By grouping functions by domain, consolidating where appropriate, and leveraging API Gateway direct integrations, you can transform an unmanageable serverless environment into a clean, scalable, and maintainable architecture.

Start by reviewing your existing Lambda landscape. Identify shared domains, look for consolidation opportunities, and evaluate where direct integrations can reduce unnecessary compute. These incremental changes can significantly improve both developer productivity and operational efficiency.