AWS Lambda durable functions change that. Launched at re:Invent 2025, durable functions extend the familiar Lambda programming model with built-in capabilities to checkpoint progress, automatically recover from failures, and suspend execution for up to one year, all without incurring compute charges during waits.

In this post, I’ll walk you through building a real multi-step application using Lambda durable functions. We’ll build a customer onboarding workflow that validates user data, sends a verification email, waits for the user to confirm, and then provisions their account. By the end, you’ll understand the core concepts and have working code you can adapt for your own use cases.

What Are Lambda Durable Functions?

At their core, durable functions are regular Lambda functions. Same event handler, same integrations, same deployment tools. The difference? When you enable durable execution on a function, you get access to a set of durable operations, primitives like step(), wait(), and waitForCallback(), that automatically handle checkpointing and replay.

Here’s the key mental model:

1. Your function executes step by step

2. Each durable operation creates a checkpoint and the result is persisted automatically

3. If a failure occurs, Lambda re-invokes your function from the beginning

4. During replay, completed steps are skipped and their stored results are returned instantly

5. Execution resumes from exactly where it left off

This means you write sequential, readable code while the runtime handles all the complexity of state management and failure recovery underneath.

The Use Case: Customer Onboarding

Let’s build something practical. Our customer onboarding workflow has the following steps:

1. Validate the incoming registration data

2. Create a user profile in our database

3. Send a verification email with a confirmation link

4. Wait for the user to click the link (up to 24 hours)

5. Provision the user’s account (or expire the registration)

6. Send a welcome email

This is a perfect fit for durable functions because it involves:

• Multiple sequential steps that depend on each other

• A long wait for an external event (email confirmation)

• Error handling at each stage

• The need to resume reliably after the wait

Without durable functions, you’d need DynamoDB to store state, a separate mechanism to handle the callback, retry logic for each step, and idempotency guards. With durable functions, it’s just code.

Writing the Workflow

Let’s write the actual onboarding logic. This is where durable functions shine. The code reads like a simple script, but it’s fully fault-tolerant.

from aws_durable_execution_sdk_python import (
    DurableContext,
    StepContext,
    durable_execution,
    durable_step,
)
from aws_durable_execution_sdk_python.config import (
    CallbackConfig,
    Duration,
    StepConfig,
)
from aws_durable_execution_sdk_python.retries import (
    RetryStrategyConfig,
    create_retry_strategy,
)

import boto3
import uuid

dynamodb = boto3.resource("dynamodb")
ses = boto3.client("ses")
users_table = dynamodb.Table("Users")


@durable_step
def validate_registration(ctx: StepContext, event: dict) -> dict:
    """Validate incoming registration data."""
    email = event.get("email")
    name = event.get("name")

    if not email or "@" not in email:
        raise ValueError(f"Invalid email: {email}")
    if not name or len(name) < 2:
        raise ValueError(f"Invalid name: {name}")

    ctx.logger.info(f"Registration validated for {email}")
    return {"email": email, "name": name, "user_id": str(uuid.uuid4())}


@durable_step
def create_user_profile(ctx: StepContext, user: dict) -> dict:
    """Create user profile in DynamoDB."""
    users_table.put_item(
        Item={
            "user_id": user["user_id"],
            "email": user["email"],
            "name": user["name"],
            "status": "pending_verification",
        }
    )
    ctx.logger.info(f"Profile created for user {user['user_id']}")
    return user


@durable_step
def send_verification_email(
    ctx: StepContext, callback_id: str, user: dict
) -> dict:
    """Send verification email with the callback link."""
    verification_link = (
        f"https://api.example.com/verify?callback_id={callback_id}"
    )
    ses.send_email(
        Source="noreply@example.com",
        Destination={"ToAddresses": [user["email"]]},
        Message={
            "Subject": {"Data": "Verify your email"},
            "Body": {
                "Html": {
                    "Data": f"<p>Hi {user['name']},</p>"
                    f"<p>Click <a href='{verification_link}'>here</a> "
                    f"to verify your email.</p>"
                }
            },
        },
    )
    ctx.logger.info(f"Verification email sent to {user['email']}")
    return {"email_sent": True}


@durable_step
def provision_account(ctx: StepContext, user: dict) -> dict:
    """Provision the user's account after verification."""
    users_table.update_item(
        Key={"user_id": user["user_id"]},
        UpdateExpression="SET #s = :s",
        ExpressionAttributeNames={"#s": "status"},
        ExpressionAttributeValues={":s": "active"},
    )
    ctx.logger.info(f"Account provisioned for {user['user_id']}")
    return {**user, "status": "active"}


@durable_step
def send_welcome_email(ctx: StepContext, user: dict) -> None:
    """Send welcome email to the newly verified user."""
    ses.send_email(
        Source="noreply@example.com",
        Destination={"ToAddresses": [user["email"]]},
        Message={
            "Subject": {"Data": f"Welcome, {user['name']}!"},
            "Body": {
                "Html": {
                    "Data": f"<p>Hi {user['name']},</p>"
                    f"<p>Your account is now active. Welcome aboard!</p>"
                }
            },
        },
    )
    ctx.logger.info(f"Welcome email sent to {user['email']}")


@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    try:
        # Step 1: Validate the registration
        user = context.step(validate_registration(event))
        context.logger.info(f"User validated: {user['email']}")

        # Step 2: Create user profile
        retry_config = RetryStrategyConfig(max_attempts=3, backoff_rate=2.0)
        user = context.step(
            create_user_profile(user),
            config=StepConfig(
                retry_strategy=create_retry_strategy(retry_config)
            ),
        )

        # Step 3: Create a callback and send the verification email
        callback = context.create_callback(
            name="email-verification",
            config=CallbackConfig(timeout=Duration.from_hours(24)),
        )
        context.step(
            send_verification_email(callback.callback_id, user)
        )

        # Step 4: Wait for the user to click the verification link
        # Execution suspends here — no compute charges while waiting
        verification_result = callback.result()
        context.logger.info(f"Callback received: {verification_result}")

        if not verification_result or not verification_result.get("verified"):
            return {
                "user_id": user["user_id"],
                "status": "verification_failed",
            }

        # Step 5: Provision the account
        active_user = context.step(
            provision_account(user),
            config=StepConfig(
                retry_strategy=create_retry_strategy(retry_config)
            ),
        )

        # Step 6: Send welcome email
        context.step(send_welcome_email(active_user))

        return {
            "user_id": active_user["user_id"],
            "status": "active",
            "email": active_user["email"],
        }

    except ValueError as e:
        context.logger.error(f"Validation error: {e}")
        return {"status": "validation_failed", "error": str(e)}
    except Exception as e:
        context.logger.error(f"Onboarding failed: {e}")
        raise

Let’s break down what’s happening:

1. Each step is decorated with @durable_step. This tells the SDK to checkpoint the result. If the function is replayed, completed steps return their stored result instantly.

2. The @durable_execution decorator wraps the main handler and provides the DurableContext. This context is your gateway to all durable operations.

3. create_callback() creates a callback token with a 24-hour timeout. We pass the callback_id into the verification email as a link parameter. When the user clicks the link, our API Gateway endpoint calls SendDurableExecutionCallbackSuccess with the callback ID, and execution resumes.

4. callback.result() is where execution suspends. The function terminates, no compute charges accumulate, and Lambda waits for the callback signal. This could take minutes or hours.

5. Retry strategies are configured per step. If create_user_profile or provision_account fails due to a transient DynamoDB error, the step retries automatically with exponential backoff.

6. Error handling distinguishes between terminal errors (invalid registration data → immediate failure) and transient errors (DynamoDB throttling → automatic retry within the step).

Handling the Callback

When the user clicks the verification link, you need an API Gateway endpoint that sends the callback signal to Lambda. Here’s what that looks like:

import boto3
import json

lambda_client = boto3.client("lambda")


def verification_handler(event, context):
    """API Gateway handler for the email verification link."""
    callback_id = event["queryStringParameters"]["callback_id"]

    lambda_client.send_durable_execution_callback_success(
        CallbackId=callback_id,
        Result=json.dumps({"verified": True}).encode(),
    )

    return {
        "statusCode": 200,
        "body": json.dumps({"message": "Email verified successfully!"}),
    }

That’s it. One API call resumes the entire onboarding workflow from exactly where it left off.

Best Practices

After building several durable function workflows, here are the patterns I’d recommend:

1. Always Use Lambda Versions in Production

When you deploy a durable function, use explicit versions (not $LATEST). If an execution is suspended waiting for a callback, and you deploy a code update, the replayed invocation will use the version that started the execution. This ensures deterministic replay and prevents inconsistencies.

2. Keep Steps Focused and Idempotent

Each step should do one thing. If a step is retried, it runs the same code again, make sure that’s safe. For example, use conditional writes in DynamoDB (attribute_not_exists) to avoid creating duplicate records.

3. Use Retry Strategies Wisely

Not every step needs retries. Validation steps should fail fast. Steps that call external APIs or databases should have retries with exponential backoff. Configure these per-step:

retry_config = RetryStrategyConfig(
    max_attempts=5,
    backoff_rate=2.0,
)
context.step(
    my_step(data),
    config=StepConfig(retry_strategy=create_retry_strategy(retry_config)),
)

4. Use context.logger for Logging

The durable context logger suppresses duplicate logs during replay. If you use print() or a standard logger, you’ll see duplicate log entries every time the function is replayed.

5. Design for Replay

Your code runs from the beginning on every replay. Avoid side effects outside of durable steps, anything not wrapped in context.step() will execute again on every replay. This includes things like incrementing counters, publishing messages, or writing to databases.

When to Use Durable Functions vs. Step Functions

This is the question everyone asks. Here’s my take:

Choose durable functions when:

• Your workflow orchestrates Lambda functions (not other AWS services directly)

• You want to write and test workflows in your programming language

• You have long waits (hours/days) and want zero-cost suspension

• Your team is already comfortable with Lambda tooling (SAM, CDK)

Choose Step Functions when:

• Your workflow integrates multiple AWS services directly (DynamoDB, SQS, ECS, etc.) via native SDK integrations

• You need visual debugging and the execution console for production observability

• Non-engineers need to understand and review the workflow

• You need the compliance audit trail that Step Functions execution history provides

They’re not mutually exclusive. Many architectures use both: durable functions for code-heavy Lambda chains, Step Functions for multi-service orchestration.

Wrapping Up

Lambda durable functions bring a refreshing simplicity to building multi-step applications. You write sequential code in your preferred language, and the runtime handles checkpointing, retries, and suspension transparently. No external state stores, no retry libraries, no orchestration services to manage.

The customer onboarding workflow we built in this post is a common pattern, but the same approach applies to order processing, payment flows, AI agent orchestration, approval workflows, and any multi-step process that needs to be resilient.

If you want to dive deeper, here are some resources:

• Lambda Durable Functions Documentation

• AWS Durable Execution SDK Developer Guide

• Building Fault-Tolerant Applications with Lambda Durable Functions

• Best Practices for Lambda Durable Functions

Happy building!

A year ago, AI coding assistants were autocomplete on steroids. You’d type a function signature, and the tool would guess the body. Useful but fundamentally passive.

That era is over.

The tools available today are agents. They don’t wait for you to type. They read your project, reason about what needs to happen, make a plan, write the code, run the tests, fix the failures, and come back with a working result. Some of them do this in cloud sandboxes while you’re reviewing a different feature.

If you’re building cloud projects, for example deploying infrastructure, writing Lambda functions, building APIs, configuring services, these tools don’t just save time. They change the kind of projects you can take on alone.

Here are five worth knowing, how they differ, and the protocol that connects them all.

1. Claude Code

What it is: Anthropic’s agentic coding tool, available as a CLI, a VS Code extension, a JetBrains plugin, and a standalone desktop app.

Why it matters for cloud projects: Claude Code isn’t just an editor feature but a layered agentic system. It separates memory, hooks, skills, subagents, and MCP into distinct layers, each changing what the model can see or do.

When you’re building a serverless API, you don’t just ask Claude Code to “write a Lambda function.” You give it a goal: “build an API Gateway endpoint that takes a PDF, extracts text with Textract, summarizes it with Bedrock, and stores the result in DynamoDB” and it plans the approach, writes the handler, generates the IAM policy, creates the SAM template, and runs sam build to verify it compiles.

The subagent capability is where it gets powerful for larger projects. You can spin up multiple Claude Code agents working on different parts of your stack in parallel, one on the frontend, one on the backend, one on the infrastructure, each with its own context window and working memory.

Standout feature: Skills: reusable instruction sets you can create and share. Write a skill that encodes your team’s CDK patterns, IAM guardrails, or naming conventions, and every future Claude Code session follows them automatically. It’s institutional knowledge made executable.

2. Kiro

What it is: Amazon’s agentic IDE, built on top of VS Code with Bedrock models powering the agents.

Why it matters for cloud projects: Kiro takes a fundamentally different approach from every other tool on this list. Where others start with code, Kiro starts with specs.

When you describe a feature, Kiro doesn’t immediately generate code. It first writes a requirements document, then a technical design, then breaks everything into a numbered task list. Only then does it start writing code, and it does so against the spec, not just the prompt. This spec-driven development means the agent can implement more complex features in fewer shots because it has explicit documentation of what it’s building and why.

For cloud projects, this changes the game. Instead of “write me a Step Functions workflow,” you describe the business requirement (”process incoming invoices, classify them, route high-value ones for approval”). Kiro generates the spec, designs the architecture (which Step Functions states, which Lambda functions, what DynamoDB schema), and then implements each task in sequence.

Standout feature: Parallel agents with specs: Kiro can run multiple agents simultaneously, each working on a different task from the spec. Property-based tests catch edge cases that unit tests miss. The spec acts as the contract between agents, so they don’t step on each other.

3. Cursor

What it is: An AI-native IDE (forked from VS Code) that made “agent mode” mainstream.

Why it matters for cloud projects: Cursor pioneered the idea that your IDE should have an agent window alongside your file tree. Since Cursor 3.0, the Agents Window lets you launch multiple agents, each in its own worktree, each with its own model and mode. One agent can be planning a refactor with Opus while another implements a different feature in parallel.

The Cloud Agents feature (Cursor 3.5) is the headline for cloud builders. These agents run in isolated cloud VMs with full terminal, browser, and desktop access. They can work across multiple repos in parallel and report results back to your IDE asynchronously. This means you can kick off an agent to set up a complete CI/CD pipeline in one repo, deploy a CloudFormation stack in another, and review both results when they’re done, without your local machine doing any of the work.

Standout feature: Background agents in cloud VMs: fire off complex infrastructure tasks (Terraform plans, CDK deployments, integration test suites) and they run in the cloud while you keep coding locally. You review the output when it’s ready.

4. Codex

What it is: OpenAI’s coding agent, now powered by GPT-5.2-Codex and running as both an in-IDE tool and a standalone app.

Why it matters for cloud projects: Codex has evolved from a code completion model into a full autonomous agent. The latest version can operate your computer alongside you, meaning it doesn’t just write code, it interacts with terminals, browsers, and cloud consoles.

For cloud builders, the most relevant capability is long-horizon work. Codex is optimized for tasks that span many files and many steps, exactly what cloud projects demand. A migration from one database to another, a refactor of a monolith into microservices, converting CloudFormation templates to CDK, these are multi-hour, multi-file tasks that Codex can handle with its context compaction and improved handling of large code changes.

The Codex app supports coordinating teams of agents across the full lifecycle: designing, building, shipping, and maintaining software. You can assign one agent to write the Lambda functions, another to write the tests, and a third to configure the deployment pipeline, and they coordinate through shared context.

Standout feature: Full lifecycle coordination: from design to deployment to maintenance, with agents that can learn from previous actions and remember your preferences across sessions.

5. GitHub Copilot

What it is: GitHub’s AI pair programmer, now with full agent mode and deep GitHub integration.

Why it matters for cloud projects: Copilot’s advantage isn’t just the model, it’s the platform integration. Copilot lives inside the GitHub ecosystem: pull requests, issues, code review, Actions workflows, and the security graph. When you ask Copilot to work in agent mode, it can create branches, open PRs, run CI checks, and iterate on failures, all within the GitHub flow your team already uses.

The agent mode is genuinely agentic: it executes multi-step workflows independently, chooses appropriate tools based on context, and iterates based on feedback and results. For cloud projects, this means you can describe an infrastructure change, Copilot writes the Terraform, opens a PR, the CI pipeline runs terraform plan, Copilot reads the plan output, and fixes any issues, all before you review.

Standout feature: Agent Skills: reusable, domain-specific bundles of knowledge and tool usage that Copilot loads automatically when relevant. You can create skills for your team’s AWS patterns, security policies, or deployment conventions. Skills compose with MCP servers, so a skill can both encode prompting logic and call external tools.

The Thread That Connects Them: MCP and Skills

You’ve probably noticed two terms recurring across all five tools: MCP and Skills. This isn’t a coincidence, they represent the two layers that are standardizing how AI coding agents work.

MCP — Model Context Protocol

MCP is an open protocol that lets any AI agent connect to any external tool through a single standardized interface. Think of it as USB-C for AI: instead of writing a custom integration for every tool your agent needs to talk to, you expose the tool once as an MCP server, and any MCP-aware agent can use it.

For cloud builders, this is transformative. An MCP server for AWS means your coding agent can query CloudWatch logs, read DynamoDB tables, check deployment status, or fetch secrets from Secrets Manager, all through the same protocol, regardless of whether you’re using Claude Code, Kiro, Cursor, Codex, or Copilot.

MCP servers are already available for AWS services, databases, monitoring tools, and CI/CD platforms. The ecosystem is growing fast because the investment is write-once: build an MCP server for your internal tool, and every AI coding agent your team uses can immediately access it.

Skills — Portable Knowledge

Skills take different forms across tools (Claude Code calls them “skills,” Copilot calls them “agent skills,” Kiro uses “specs”), but the concept is the same: reusable instruction sets that encode how your team builds software.

A skill might encode:

• Your team’s CDK patterns and naming conventions

• Security guardrails (no wildcard IAM policies, encryption at rest required)

• Architecture preferences (EventBridge over SNS for event routing, DynamoDB over RDS for session storage)

• Deployment standards (blue-green only, canary for Lambda)

Skills are the bridge between “AI that writes code” and “AI that writes code the way your team writes code.” Without skills, every agent session starts from zero. With skills, institutional knowledge persists.

The Bottom Line

These five tools aren’t competing to be the best autocomplete. They’re competing to be the best engineering partner, one that understands your cloud architecture, follows your team’s standards, connects to your infrastructure, and works autonomously on complex tasks while you focus on the decisions that matter.

The advice? Don’t pick one and ignore the rest. Try them on a real project. The cloud space moves fast, and the tool that fits your workflow today might not be the one you expected.

Start building. The agents are ready.

“I have three AWS certifications, but I keep getting rejected. What am I doing wrong?”

Here’s the hard truth nobody tells you: certifications get you noticed, but they don’t get you hired. Recruiters and hiring managers have seen thousands of certified candidates who freeze the moment you ask them to design a real system or explain a decision they actually made.

What separates the people who get offers from the people who get ghosted isn’t another badge. It’s real-world experience — proof that you can take a problem, build a solution, and make it production-ready.

The good news? You don’t need a job to build that experience. You can manufacture it yourself. And you only need to follow three steps.

Step 1: Learn the Cloud Fundamentals

Before you build anything, you need a strong foundation. Not a surface-level “I watched a course once” understanding — a genuine working grasp of the core building blocks that every cloud system is made of:

• Compute — how and where your code runs (EC2, Lambda, containers)

• Networking — VPCs, subnets, routing, load balancing, how traffic actually flows

• Security — encryption, security groups, the shared responsibility model

• Storage — object vs. block vs. file, and when to use each (S3, EBS, EFS)

• Databases — relational vs. NoSQL, and the trade-offs (RDS, DynamoDB)

• Identity & Access Management — IAM roles, policies, and least-privilege access

Here’s something most people don’t realize:

Only 10 AWS services account for roughly 90% of all interview questions.

You don’t need to learn all 200+ AWS services. You need to go deep on the handful that come up again and again — compute, storage, networking, databases, IAM, and a few messaging and monitoring services. Master those, and you’ve covered the vast majority of what any interviewer will throw at you.

Depth beats breadth. Every time.

Step 2: Build Projects That Solve Real Problems

This is where most people go wrong. They follow a tutorial, deploy a “Hello World” app, and call it a project. Recruiters see straight through that.

Instead: identify a real problem, then apply your fundamentals to solve it.

The problem doesn’t have to be huge. It just has to be real:

• A small business that needs a way to collect and process customer feedback

• A personal expense tracker that ingests bank exports and visualizes spending

• An image-processing pipeline that resizes and tags photos automatically

• A URL shortener that has to scale and stay cheap

Then build it end-to-end using the fundamental services from Step 1 — compute, storage, a database, IAM, and the networking to tie it together.

Why does this matter so much?

Interviewers look for impact, not just technical knowledge.

When you can say “I built a system that solved X problem for Y users, and here’s the decision I made and why,” you’re speaking the language hiring managers care about. You’re no longer a candidate reciting service names — you’re an engineer who ships.

And here’s the multiplier:

One impactful, real-world project can elevate your profile above the entire competition.

While everyone else lists certifications, you’ll have a working system, a GitHub repo, an architecture diagram, and a story. That’s what gets you remembered.

Step 3: Optimize With Well-Architected Principles

A working project is good. A well-architected project is what makes recruiters lean in.

Once your solution works, take it further. Improve it across the five pillars of the AWS Well-Architected Framework:

• Operational Excellence — automate deployments, add monitoring and logging

• Security — tighten IAM to least privilege, encrypt data at rest and in transit

• Reliability — handle failures gracefully, add retries, remove single points of failure

• Performance Efficiency — right-size resources, add caching, choose the right compute

• Cost Optimization — cut waste, use the right pricing model, make it cheap to run

This step is what transforms a hobby project into something that looks like it belongs in production. When you can walk an interviewer through how you made your solution more scalable, secure, reliable, performant, and cost-efficient — and explain the trade-offs you weighed — you demonstrate exactly the kind of judgment companies pay senior salaries for.

That’s the difference between “I can use AWS” and “I can architect on AWS.”

Putting It All Together

Real-world experience isn’t something you have to wait for a job to give you. You build it yourself, in three steps:

1. Learn the fundamentals — go deep on the core services that actually matter.

2. Build projects that solve real problems — and lead with impact, not tech.

3. Optimize with Well-Architected principles — turn your project into production-grade proof.

Do this, and you stop looking like “another certified candidate” and start looking like an engineer who’s already doing the job.

Here’s a story every serverless team eventually lives through. You ship a Lambda-based system, it works beautifully, and you feel great. Then the monthly bill arrives and there’s a line item that makes you squint: CloudWatch. Sometimes it’s bigger than the Lambda compute it’s supposed to be observing.

Observability is non-negotiable. You cannot run a distributed serverless system blind. But in serverless, the very thing that gives you visibility is metered, and the defaults are quietly expensive. The goal isn’t to log less and fly blind. It’s to be deliberate: capture what you need, drop what you don’t, and design your observability the same way you design everything else, with cost as a first-class constraint.

Let’s break down the three pillars — logs, metrics, and traces — where each one silently runs up the bill, and how to get production-grade visibility without the shock.

Why Serverless Observability Is Different

In a traditional server, you SSH in, tail a log, and watch. In serverless, there’s nothing to SSH into. Your system is dozens of ephemeral functions, queues, and managed services, each emitting its own telemetry. Visibility has to be designed in, not bolted on.

And every signal has a price:

• Logs are billed for ingestion and storage and Lambda makes it trivially easy to emit enormous volumes.

• Metrics are cheap by default but get expensive the moment you reach for high-cardinality custom metrics.

• Traces are sampled for a reason trace everything at scale and the cost climbs fast.

The three pillars are your toolkit. Knowing when to reach for each, and when not to, is the whole game.

Pillar 1: Logs — Where the Bill Usually Hides

Logs are the number one source of surprise CloudWatch bills. The culprit is almost always volume: verbose logging left on in production, giant payloads dumped into logs, and infinite retention.

Three habits fix most of it:

1. Log structured JSON, not strings. Structured logs are queryable, filterable, and far more useful per byte. One rich JSON line beats ten print statements.

2. Log at the right level. DEBUG is for development. In production, log INFO for the meaningful events and ERROR for failures and make the level configurable per environment so you’re not redeploying to change it.

3. Set a retention policy. Always. By default, CloudWatch Logs keep your data forever and you pay for that storage forever. Almost no one needs 90-day-old function logs. Set retention to something sane (7, 14, 30 days) on every log group.

A structured log line looks like this — one line, fully queryable in CloudWatch Logs Insights:

{
  "level": "INFO",
  "event": "cv_enhanced",
  "requestId": "abc-123",
  "durationMs": 842,
  "inputTokens": 310,
  "outputTokens": 190
}

The single highest-leverage change most teams can make: turn off debug logging in production and set log retention. That one afternoon of work often cuts the CloudWatch bill more than any other single action.

Pillar 2: Metrics — Cheap by Default, Expensive When Careless

Metrics answer “how is the system behaving overall?” such as invocation counts, error rates, duration, throttles. The good news: Lambda emits the essential ones for free, and they’re your first line of defense.

Where cost sneaks in is custom metrics, and specifically cardinality. Every unique combination of dimensions on a custom metric is billed separately. Add a customerId dimension to a metric and you don’t have one metric but one per customer. That’s how a “small” custom metric becomes a four-figure line item.

Keep metrics affordable:

1. Lean on the free built-ins first. Errors, duration, throttles, and concurrency are already there. Build your core dashboards and alarms on these before adding anything custom.

2. Guard your cardinality. Never put unbounded values (user IDs, request IDs, email addresses) into metric dimensions. Those belong in logs, not metrics.

3. Emit metrics from logs where you can. Deriving metrics from structured log fields avoids a separate metric-publishing cost and keeps your telemetry in one place.

Metrics tell you that something is wrong. For why, you need the third pillar.

Pillar 3: Traces — Powerful, and Worth Sampling

A trace follows a single request across every hop: API Gateway → Lambda → Bedrock → DynamoDB and shows you exactly where the time (or the failure) went. In an async, event-driven system, this is the difference between “it’s slow somewhere” and “it’s this DynamoDB call, right here.”

Tracing tools (like AWS X-Ray) are indispensable for debugging distributed flows. But tracing every single request at high volume gets expensive and rarely adds insight.

Use tracing wisely:

1. Sample, don’t capture everything. A small percentage of requests is usually enough to understand behavior and catch anomalies. Reserve full capture for when you’re actively hunting a problem.

2. Propagate a correlation ID. Pass a single request ID through every hop, including across queues and events, and log it everywhere. This is the cheapest, highest-value tracing habit, and it works even where full tracing doesn’t reach.

3. Trace the boundaries that matter. Focus tracing on the hops most likely to hurt: external API calls, model invocations, and database access. Those are where latency and failures actually live.

A Practical, Cost-Aware Setup

If you want a default posture that gives strong visibility on a small budget, start here:

1. Structured JSON logging at INFO in production, DEBUG only in dev.

2. Log retention set explicitly on every log group (7–30 days).

3. Dashboards and alarms built on the free Lambda metrics — errors, duration (p95, not just average), and throttles.

4. Custom metrics only for a handful of true business KPIs, with strict low cardinality.

5. Tracing enabled with sampling, plus a correlation ID threaded through every function and event.

6. A billing alarm on CloudWatch spend itself so your observability can never surprise you again.

That setup catches real problems fast and keeps the observability bill proportional to the value it delivers.

Conclusion

Observability isn’t optional in serverless. You’re operating a distributed system, and you need to see it. But “see everything, forever, at full fidelity” is a choice that quietly wrecks your bill without making you meaningfully wiser. The fundamentals hold here just like everywhere else: capture what matters, drop what doesn’t, and treat cost as a design constraint from the start.

Solutions Architect might be the most misunderstood title in tech. Ask ten engineers what an SA does and you’ll get ten answers: “they draw diagrams,” “they’re pre-sales,” “they’re just senior engineers who stopped coding.” None of these are quite right, and the gap between the perception and the reality is exactly why so many talented engineers either avoid the role or struggle when they step into it.

I’ve spent four years as a Solutions Architect at AWS, working alongside hundreds of customers. Before that, I was a Software Engineer building and shipping production systems. So I’ve lived on both sides of the whiteboard. This article is the honest breakdown I wish someone had given me: what the role actually involves, the skills that matter, and a practical path to get there.

What a Solutions Architect Actually Does

Strip away the title and an SA does one thing: translates business problems into technical solutions, and technical realities into business decisions. You sit at the intersection.

On a typical week, that looks like:

• Discovery. Sitting with a customer or team to understand what they’re actually trying to achieve. The best SAs are relentless about the “why” behind the “what.”

• Design. Producing an architecture that balances the four forces you’re always juggling: scalability, performance, cost, and operational simplicity. There’s rarely a “correct” answer, only trade-offs you can defend.

• Communication. Writing the doc. Presenting to stakeholders who range from hands-on engineers to VPs who just want to know the risk and the cost. Translating up and down the stack.

• Enablement. Helping teams build the thing by reviewing their approach, unblocking them, and handing off enough context that they own it after you leave.

Notice what’s not on that list: writing production code all day. That surprises people. Which brings us to the biggest misconceptions.

The Misconceptions, Corrected

“SAs don’t code.” False. You may not ship production features, but you build proofs of concept, reference implementations, and demos constantly. If you can’t open an editor and prove an idea works, your credibility evaporates. The coding shifts from building the product to proving the pattern.

“It’s just a senior engineer role.” Not quite. Seniority in engineering rewards depth, going deep on a system and owning it. SA work rewards breadth and translation, being conversant across many services, and turning ambiguity into a defensible design others can execute. Different muscle.

“It’s a sales job.” In a vendor context (like AWS), there’s a commercial dimension. You’re helping customers succeed, which supports adoption. But the technical bar is real; you can’t hand-wave. And plenty of SA roles exist entirely inside product companies with zero sales involvement.

The Skills That Actually Matter

Here’s where I’d tell my younger self to invest. In order of how much they move the needle:

1. Communication, especially writing. This is the single most underrated skill in the role. If you can write a crisp one-pager that a VP and a staff engineer both understand, you will outperform architects with deeper technical knowledge who can’t. Learn to write.

2. Trade-off reasoning. Anyone can list AWS services. The value is in knowing when not to use one. “Do we even need Lambda here, or is a direct API Gateway integration cleaner?” That instinct, reaching for the simplest thing that works, is the core of the job.

3. Breadth over depth. You need working knowledge across compute, storage, networking, data, security, and cost. But have two or three areas where you go genuinely deep. Breadth earns you the conversation; depth earns you trust.

4. Cost fluency. Being able to reason about what an architecture costs, and redesign it when the bill doesn’t justify the elegance, separates architects who get invited back from those who don’t.

5. Empathy and listening. The best design is worthless if it solves the wrong problem. Discovery is a listening skill before it’s a technical one.

Solutions Architect vs. Senior Engineer: Which Path Is Yours?

Both are excellent, senior, well-compensated paths. The question is what energizes you.

Lean Solutions Architect if you:

• Enjoy variety like new problems, new domains, new people, constantly

• Like the moment a diagram makes a room go “oh, now I get it”

• Are energized by ambiguity and translation, not annoyed by it

• Want breadth across the stack more than mastery of one system

Lean Senior/Staff Engineer if you:

• Get satisfaction from owning and perfecting a system over time

• Prefer depth and craft over breadth and context-switching

• Want your primary output to be shipped, running code

• Find long meetings and stakeholder management draining rather than fun

Neither is “more technical” or “more senior.” They’re different shapes of the same seniority.

A Practical Path to Get There

If the role sounds like you, here’s how to move toward it from an engineering seat — starting today, without waiting for a title change:

1. Start architecting where you are. Volunteer for the design docs. Own the “how should we build this?” conversation on your team. You don’t need permission to think like an architect.

2. Write in public and internally. Publish design write-ups, share trade-off analyses, document decisions. This builds the exact muscle the role demands and creates visible evidence you can do it.

3. Go broad deliberately. If you’re a backend engineer, spend a quarter getting genuinely comfortable with networking or data. Fill the gaps in your T-shape.

4. Get in front of stakeholders. Ask to present your team’s design to another team or to leadership. Reps at translating technical detail to a mixed audience are gold.

5. Build reference implementations. Take a common pattern and build a clean, well-documented example. This is exactly the kind of artifact SAs produce — and a portfolio piece that proves the skill.

6. Certifications help as a floor, not a ceiling. The AWS Solutions Architect certifications signal breadth and are worth having. But they get you considered, not hired. The design thinking and communication get you hired.

Conclusion

Being a Solutions Architect isn’t about knowing every service or drawing the prettiest diagram. It’s about turning ambiguous business problems into defensible technical solutions and being able to explain those solutions to anyone in the room. The fundamentals are the same ones that make any great engineer: reach for simplicity, understand the trade-offs, and always design for the real problem, not the fun one.

Everyone tells you to “build projects” to stand out. But most portfolio projects are the same tired to-do app or a static site that says nothing about you as an engineer. In 2026, a fast way to make a hiring manager stop scrolling is to show you can ship a real-world project, like the serverless GenAI application we'll build in this article.

The good news: you don’t need a GPU cluster, an ML degree, or months of work. With AWS Lambda and Amazon Bedrock, you can build a genuinely useful GenAI app in an afternoon which is fully serverless, pay-per-request, and free-tier friendly.

So let’s design one. We’ll build a tool that enhances your CV. You give it a job description and your rough resume bullets, and the app rewrites them into sharp, tailored, results-oriented bullet points using a foundation model. It’s useful, it’s self-referential, and it demonstrates the full serverless-GenAI stack.

This article is about the thinking behind the project, the architecture, the decisions, and the career payoff. No code walls, just the blueprint you need to go build it.

The Idea: A Serverless AI CV Enhancer

The concept is simple. A user pastes in two things:

1. The job description they’re targeting.

2. Their current resume bullets rough, honest, unpolished.

The app sends both to a foundation model with a carefully written instruction: rewrite these bullets to be sharp, quantified, and tailored to this specific role. Seconds later, the user gets back stronger bullets they can drop straight into their CV.

Why this project works so well as a portfolio piece:

• It’s genuinely useful. You’ll actually use it. That authenticity comes through when you talk about it.

• It’s self-referential. “I built the tool that wrote the bullet point describing this tool” is a hook interviewers remember.

• It touches the whole modern stack. API, compute, a foundation model, and a database — the complete shape of a real GenAI application, in miniature.

The Architecture

We’re keeping this deliberately simple. Four managed building blocks, all serverless, nothing to patch or babysit:

Client  →  API Gateway  →  Lambda  →  Amazon Bedrock
                              │
                              └──────→  DynamoDB (history)

• Amazon API Gateway: the front door. It exposes a single endpoint your app (or a curl command) can call.

• AWS Lambda: the brain. It receives the request, assembles the instruction for the model, calls Bedrock, and stores the result. It runs only when called, and you pay only for those milliseconds.

• Amazon Bedrock: the intelligence. This is AWS’s managed gateway to foundation models (like Claude). You call an API; AWS handles the model hosting, scaling, and infrastructure entirely.

• Amazon DynamoDB: the memory. It stores each enhancement so users have a history and so you have a reason to talk about data modeling in interviews.

The beauty of this design is what’s absent: no servers, no containers, no idle cost, nothing to keep patched. When no one’s using it, you pay essentially nothing.

The Real Product Is the Prompt

Here’s the insight that separates a good GenAI project from a toy: most of the quality lives in how you instruct the model, not in the plumbing.

The plumbing like API, function, database is standard serverless work. What makes this app good is a well-structured instruction to the model: telling it to act as an expert resume writer, to use strong action verbs, to quantify impact where plausible, to tailor to the target role, and to return clean output. That instruction is your product. Iterating on it, testing it against real job descriptions, tightening the wording, is where you’ll spend your most valuable time.

This is worth internalizing, because it reframes what “AI engineering” often means in practice: it’s less about training models and more about integrating them well and instructing them precisely.

See It In Action

Once you build and deploy the application, using it is as simple as sending your target role and your rough bullets. Feed it something honest and unpolished like:

• Worked on the payments service

• Helped with the migration to Lambda

• Fixed bugs in the API

...and it returns something tailored and sharp:

• Architected and shipped a payments service processing millions of daily transactions on AWS

• Led migration of the core API to a serverless Lambda architecture, cutting infrastructure cost significantly

• Improved reliability by resolving critical API defects and adding integration test coverage

Same you but sharper story. A quick note on integrity: use this to articulate real work more effectively, not to invent it. The goal is to describe what you genuinely did in the strongest honest terms.

How to Level It Up (and Talk About It)

The base project is enough to ship. But each of these additions gives you another thing to discuss in an interview, pick based on what you want to signal:

1. Add a simple frontend. A one-page static site that calls your API turns this into a full-stack demo you can link to from your CV.

2. Add streaming responses. Have the enhanced bullets appear word by word instead of all at once. It signals you care about user experience, not just the happy path.

3. Add observability. Structured logging and request tracing across the whole flow. This is the difference between a demo and something production-minded.

4. Add richer history. Let users query their past enhancements by date. A clean excuse to demonstrate access-pattern-first data modeling in DynamoDB.

What This Project Actually Signals

When this lands on your CV as “Built a serverless GenAI application on AWS (Lambda, Bedrock, API Gateway, DynamoDB),” here’s what a hiring manager reads between the lines:

• You can integrate foundation models into real applications a high demand skill of the moment.

• You understand serverless architecture and event-driven design, not just in theory.

• You can ship end to end, from idea to API to persistence.

That’s a lot of signal from an afternoon of work.

Conclusion

The barrier to building with GenAI has never been lower. A managed function, a Bedrock call, and a simple database are enough to build something genuinely useful and genuinely impressive on a CV. The fundamentals still apply: keep it simple, scope your permissions tightly, watch your cost, and design around the real problem.

So this weekend, don’t build another to-do app. Design and ship the CV enhancer, then put it on the very CV it enhances. Then tell me how it goes.

Here’s a career truth that took me too long to learn: being good at your job is necessary, but it isn’t enough to advance quickly. The engineers who move fastest aren’t always the most technically brilliant, they’re the ones whose work is visible. And the single highest-leverage way to make your work visible is to write about it in public.

I know, because it changed my trajectory. Writing this newsletter, publishing what I learn, and sharing it openly opened doors I didn’t know existed, such as speaking opportunities, connections with people I admired, and a reputation that arrives in the room before I do. This article is the practical case for doing the same, and a no-excuses playbook to start.

Why Writing in Public Works (The Mechanics)

This isn’t motivational fluff. There are concrete, compounding mechanisms at play:

• It compounds while you sleep. A good article you wrote two years ago is still working for you today — being read, shared, and building your reputation. Almost nothing else in a career compounds like published work.

• It forces clarity. You don’t truly understand something until you can explain it simply. Writing exposes the gaps in your knowledge and closes them. You learn the topic twice — once to do it, once to explain it.

• It builds a surface area for luck. Opportunities can’t find you if you’re invisible. Every article is another door people can knock on. Jobs, collaborations, and invitations find people who are findable.

• It’s proof of skill that outlasts any résumé. “I understand event-driven architectures” is a claim. A clear article explaining a real trade-off is evidence. Evidence wins.

The Objections (And Why They’re Wrong)

Almost everyone talks themselves out of starting. Let’s kill the four excuses head-on:

“I’m not an expert.” You don’t need to be. You need to be one step ahead of your reader. The person who learned something last month explains it better to a beginner than the expert who forgot what confusion feels like. Write from where you are.

“It’s all been written already.” It hasn’t been written by you, with your examples, in your voice. Your specific angle like the mistake you made, the trade-off you hit in production is what makes it worth reading.

“I don’t have time.” You don’t need much. A useful post can be 400 words about one thing you figured out this week. Consistency at small scale beats a heroic effort you never repeat.

“What if I’m wrong?” You will be, occasionally. That’s fine becayse the internet corrects you, you learn, you get better. The cost of a public mistake is far lower than the cost of staying invisible for years.

How to Actually Start

Here’s the playbook how to start:

1. Pick a lane, loosely. Write about the thing you’re already doing at work. For me it’s cloud and serverless. You don’t need a grand content strategy but a topic you touch every day so you never run out of material.

2. Start with what you just learned. The best first article is “here’s a problem I hit this week and how I solved it.” It’s authentic, it’s useful, and you already have the material in your head.

3. Choose the lowest-friction platform. Don’t build a custom blog first, that’s procrastination in disguise. Start where writing is free and distribution is built in: a newsletter platform like LinkedIn, Medium, or Dev.to. Reduce every barrier between you and publish.

4. Commit to a cadence you can actually keep. I write every Wednesday. The specific rhythm matters less than the promise you keep to yourself. Weekly is great; even monthly beats sporadic. The cadence is what turns one article into a body of work.

5. Write like you talk. Drop the corporate voice. Explain it the way you’d explain it to a colleague at lunch. Clarity and personality beat polish.

6. Ship before it’s perfect. Your first posts will make you cringe later and that’s a sign you’ve grown, not a reason to have waited. Hit publish. Iterate in public.

What to Expect (A Realistic Timeline)

Let me set honest expectations, because unrealistic ones are why people quit:

• Weeks 1–4: Almost no one reads it. This is normal. You’re building the habit, not the audience yet.

• Months 2–3: You get better and faster at writing. The occasional comment or share appears. The compounding hasn’t kicked in so keep going.

• Months 4–12: A back catalog accumulates. Search and shares start bringing readers you never reached directly. People begin to recognize your name.

• Beyond a year: This is where the doors open — speaking invitations, inbound opportunities, conversations with people you respect. Not because you got lucky, but because you became findable and stayed consistent.

The engineers who win at this aren’t more talented. They just didn’t quit in month two.

Conclusion

Writing in public is the rare career move with almost no downside and enormous, compounding upside. It sharpens your thinking, builds your reputation while you sleep, and turns your everyday work into a body of evidence that advances your career on your behalf.

You don’t need to be an expert. You don’t need a perfect platform. You don’t need much time. You need one topic, a cadence you can keep, and the willingness to hit publish before you feel ready.

Start this week. Write 400 words about one thing you figured out. Your future career will thank you. I promise mine did.

The first time I saw a DynamoDB single-table design, I closed the tab.

One table holding users, orders, products, and reviews. All mixed together, with cryptic keys like USER#123 and ORDER#456 sitting in the same partition? It looked insane.

It looked insane because I was thinking in relational terms. Once I flipped the mental model, design for access patterns, not entities, it clicked. Here’s the version of this pattern I wish someone had shown me on day one.

Why We Fear It: The Relational Hangover

SQL trains us to normalize. One table per entity, JOINs at query time, let the database figure out the rest. It’s a beautiful model and it’s the exact instinct that makes single-table design feel wrong.

DynamoDB has no JOINs. Every relationship you’d resolve with a JOIN in SQL becomes either multiple round-trips or a modeling decision you make up front. The fear isn’t irrational. It’s a paradigm mismatch. Name it, and it stops being scary.

The One Rule That Changes Everything: Access Patterns First

Here’s the shift: you list your queries before you design your table.

In SQL you model the data and figure out queries later. In DynamoDB you do the opposite. Take a simple e-commerce app and write down what it needs:

1. Get a user by ID

2. Get all orders for a user

3. Get a single order with its line items

4. Get all products in a category

If you can’t list your access patterns, you’re not ready to model. That discipline is exactly what scares people but it’s also the superpower. You design for what your app actually does, nothing more.

PK, SK, and the Item Collection

Two concepts do most of the work:

• Partition Key (PK): determines where an item lives.

• Sort Key (SK): orders items within a partition.

The key insight: items sharing the same PK form an “item collection” and are stored together. One query can retrieve the whole collection. That’s how you replace a JOIN, you co-locate related data on purpose.

A Worked Example

Here’s an actual single-table layout for the e-commerce app:

Now watch the access patterns fall out:

• Get user 123:
  PK = USER#123 AND SK = PROFILE

• Get all orders for user 123:
  PK = USER#123 AND begins_with(SK, "ORDER#")
One query, no JOIN, no second round-trip.

• Get order 555 with its items:
  PK = ORDER#555
The order and every line item come back together.

The cryptic keys aren’t chaos. They’re a query language you designed on purpose.

GSI Overloading: The Advanced Bit, Made Simple

Some queries go against the grain of your PK/SK like “get all orders with status SHIPPED.” Your main keys can’t answer that.

The solution is a Global Secondary Index built on generic attributes (GSI1PK, GSI1SK) that you reuse across entities. Point GSI1PK at the status, and one index can serve several “sideways” queries. Don’t worry about mastering this on day one, it’s the last 20% you grow into once the basics feel natural.

When NOT to Use Single-Table Design

I draw boundaries, because the pattern isn’t free:

• Evolving access patterns. Early-stage products whose queries change weekly, multiple tables are easier to refactor.

• Ad-hoc analytics. DynamoDB is for known patterns. Offload analytics to S3 + Athena.

• Small apps. Sometimes the operational simplicity of separate tables beats query efficiency.

• Team unfamiliarity. The real cost is the learning curve, not the technology.

The Cost & Performance Payoff

This is where it earns its place in a scalable, cost-efficient stack:

• Fewer tables to provision, monitor, and pay for.

• One query instead of N round-trips means lower latency and fewer read capacity units consumed.

• Item collections keep related data on one partition, giving you predictable single-digit-millisecond reads at scale.

Where to Start

Don’t boil the ocean. Pick one feature in your app. List its queries. Model just that as a single table. Once you’ve watched a JOIN disappear into a single Query call, the fear is gone for good, and you’ll never look at those USER#123 keys the same way again.

If you’ve ever walked out of a cloud engineering interview thinking “I answered everything correctly… so why didn’t I get the offer?” then this article is for you.

Over the past few months, I spoke with 20 hiring managers across startups, scale-ups, and large enterprises who regularly interview for Cloud Engineer, DevOps, SRE, and Solutions Architect roles. I asked them a simple question: “When two candidates have the same technical skills, what makes you say yes to one and no to the other?”

The answers were remarkably consistent. And almost none of them were about knowing more AWS services.

Here’s what they’re actually looking for.

The #1 theme: candidates who tell stories, not spec sheets

Nineteen of the twenty managers used some version of the same phrase: “I want to understand how they think.”

The weakest candidates answer questions like they’re reciting documentation. Ask them how they’d design a highly available system and you get a list: “Multi-AZ, Auto Scaling, load balancer, RDS with a read replica.” All correct. All forgettable.

The strongest candidates answer with a story that has a shape:

• Context: what was the situation and the constraint?

• Decision: what did you choose, and critically, what did you choose not to do?

• Impact: what changed as a result, measured in numbers?

Managers don’t just want to know that you can use CloudFront. They want to know that you understood why it was the right call over the three other options you considered, and what it did for the business.

“Anyone can list services. I’m hiring the person who can tell me why they picked one over another and what it cost them when they got it wrong.” — Engineering Manager, fintech scale-up

Why storytelling wins (even for deeply technical questions)

There’s a misconception that storytelling is only for behavioural rounds. It isn’t. The best technical answers are also stories, because storytelling is really just structured reasoning made visible.

When you narrate your thinking as a story, you demonstrate four things at once that a bullet-point answer never can:

1. Judgment: you weighed trade-offs, not just memorized the “right” answer.

2. Ownership: you were close enough to the outcome to know what actually happened.

3. Communication: you can explain a complex system to a stakeholder who isn’t in the weeds.

4. Self-awareness: you know where it went wrong and what you learned.

Those four qualities are exactly what separates a mid-level engineer from a senior one. And they’re impossible to fake with a list of services.

Impact is the word that closes the interview

The second theme was even blunter. When I asked what makes an answer land, managers kept coming back to one word: impact.

Engineers love to talk about what they built. Hiring managers want to know what changed because you built it.

Compare these two answers to “Tell me about a system you optimized.”

❌ Without impact:

“I migrated our batch jobs from EC2 to Lambda and set up EventBridge to trigger them on a schedule.”

✅ With impact:

“Our nightly batch jobs were running on a fleet of always-on EC2 instances that cost us about $4,000/month but were only active two hours a day. I moved them to Lambda triggered by EventBridge on a schedule. That cut the compute bill for that workload by roughly 80%, around $38k/year, and eliminated the on-call pages we used to get when an instance failed overnight.”

Same technical work. Completely different signal. The second answer tells the manager: this person understands that engineering exists to serve the business.

A simple rule: every technical story you tell should end with a number, a saved hour, or a problem that stopped happening.

A worked example: how to turn a flat answer into a winning one

Let’s take a classic cloud interview question and walk through the transformation.

The question: “Tell me about a time you improved the reliability of a system.”

The flat answer (what most candidates say)

“We were having downtime issues, so I added a load balancer and put the service across multiple Availability Zones. After that it was more reliable.”

It’s not wrong. But it has no context, no trade-off, and no measurable outcome. The manager learns almost nothing about how you think.

The storytelling + impact answer (using Context → Decision → Impact)

Context: “We ran a customer-facing checkout API on a single EC2 instance in one Availability Zone. It was fine until we had two outages in one quarter, once from an AZ disruption and once from a bad deploy, and each one took checkout down for about 40 minutes. For an e-commerce product, that’s direct lost revenue, and it was eroding trust with the business team.

Decision: “I proposed moving to an Auto Scaling group across three AZs behind an Application Load Balancer, with health checks that pulled unhealthy instances out automatically. I deliberately didn’t go straight to containers or a full EKS setup, even though it was tempting, the team had no Kubernetes experience, and I didn’t want to trade one reliability risk for a bigger operational one. The ALB-plus-ASG approach solved 90% of the problem with 10% of the complexity.

Impact: “After the change, we went from two multi-outage quarters to zero customer-facing checkout outages over the next nine months. Deploys became safe because we could roll instances one at a time. And because Auto Scaling replaced failed instances automatically, our overnight on-call pages for that service dropped to essentially zero, which the on-call team definitely noticed.”

Notice what that answer does:

• It quantifies the pain before the fix (two outages, 40 minutes each, lost revenue).

• It shows a deliberate trade-off (ALB + ASG instead of Kubernetes), proof of judgment.

• It closes with measurable impact across three dimensions: reliability, deploy safety, and team quality of life.

That’s the difference between “I know the services” and “I know how to use the services to move the needle.”

How to prepare before your next interview

You don’t need to memorize more services. You need to package what you already know into stories. Here’s a practical drill:

1. List your last 5–6 real projects. Anything you touched like a migration, a cost cut, an incident, a pipeline.

2. For each, write three lines: the Context (the constraint), the Decision (and the road not taken), and the Impact (with a number).

3. Attach a metric to every story. Dollars saved, latency reduced, deploy frequency increased, incidents eliminated. If you don’t know the exact number, estimate it honestly (”roughly”, “about”) as managers value the instinct to measure.

4. Practice the trade-off out loud. For each story, be ready to answer: “What else did you consider, and why didn’t you pick it?” This is where senior candidates separate themselves.

Do this for six stories and you’ll have a toolkit that covers almost any technical or behavioural question they throw at you.

The takeaway

Twenty hiring managers, one message: technical skill gets you into the room, but storytelling and impact get you the offer.

The candidates who win aren’t the ones who know the most services. They’re the ones who can take a real problem, walk you through how they thought about it, name the trade-offs they made, and show with numbers what changed because of it.

Next time you prep, don’t ask “Do I know enough AWS?” Ask “Can I tell the story of what I built, and prove it mattered?”

That’s the answer hiring managers are actually waiting for.

For years, there’s been one pushback against Lambda that never fully went away: “It gets expensive at scale.”

And honestly? For steady, high-volume workloads, that criticism held up. Standard Lambda gives you one request per execution environment. So a function that spends most of its time waiting on a database or downstream API is burning paid execution time doing nothing, and at thousands of requests per second, per-invocation billing adds up fast.

That’s exactly the gap AWS Lambda Managed Instances (announced at re:Invent 2025) is built to close. Let’s break down what it actually changes, and more importantly when you should reach for it.

What it actually is

You keep the Lambda programming model. Same handler, same event source mappings, same IAM roles, same CloudWatch. But instead of running on Lambda’s shared fleet, your function runs on EC2 instances in your own account and AWS still manages them for you: OS patching, load balancing, auto-scaling, instance lifecycle. You never touch an ASG.

Three things change the game:

1. Multi-concurrency. One execution environment can now handle many concurrent requests instead of one. For IO-heavy workloads, AWS lets you run up to 64 concurrent requests per vCPU. That’s a completely different mental model as concurrency now means more work per environment, not just more environments.

2. EC2 pricing. You pay standard EC2 instance charges plus a 15% management fee, not per-request duration. Your Compute Savings Plans and Reserved Instances apply to the EC2 portion (up to 72% off on-demand). For a steady baseline, this can be dramatically cheaper.

3. No cold starts. Requests route to pre-provisioned environments. You also get access to specialized hardware like Graviton4 and high-bandwidth networking.

The catch: this is not a free upgrade

Here’s where teams will get burned. It still says “Lambda,” but it behaves like a small service process.

• Thread safety is now your problem. Global state, connection pools, mutable singletons, writes to /tmp — anything that quietly relied on “one request at a time” needs an audit before you flip the switch. Concurrency-unsafe code doesn’t just underperform; it breaks.

• No scale-to-zero. Managed Instances scale to the minimum environments you configure, even at 3am with zero traffic. You’re deliberately paying for a capacity floor.

• Scaling is asynchronous. It scales on CPU and concurrency saturation, sized to absorb roughly a 50% spike before adding capacity (new instances in tens of seconds). If your traffic goes from near-zero to a massive spike in seconds, standard Lambda still has the better shape.

The decision framework

Reach for Lambda Managed Instances when most of these are true:

• Traffic is steady or predictable as the service does real work most of the day

• A minimum warm footprint is acceptable (you don’t need scale-to-zero)

• Your code is thread-safe under concurrent load

• The workload is IO-heavy, so multiple requests per environment boost throughput

• You want EC2 purchase options or specific hardware (Graviton4, high networking)

The textbook fit: an API that loads a model, vector index, or ruleset into memory at init, then serves lots of read-heavy requests. On standard Lambda you’d push that state to an external store and pay the latency tax on every call.

Stick with standard Lambda for bursty, spiky, event-driven functions where scale-to-zero matters.

Stick with Fargate when you need full container semantics — sidecars, background daemons, EFS mounts, long-running processes, or task-definition control.

Getting started

The new primitive is the capacity provider (VPC, scaling mode, instance requirements):

aws lambda create-capacity-provider \
  --capacity-provider-name app-api-managed \
  --vpc-config SubnetIds=subnet-123,subnet-456,SecurityGroupIds=sg-789 \
  --instance-requirements Architectures=arm64 \
  --capacity-provider-scaling-config ScalingMode=Auto

Attach a function to it, publish an active version, and you’re serving traffic on EC2-backed capacity with the same code.

The bottom line

AWS didn’t make Lambda more magical here. It made it more honest about the workloads people were already forcing into it. Standard Lambda is still king for spiky event-driven functions. Managed Instances is the new answer for predictable, high-throughput, Lambda-shaped services, as long as your code is ready for concurrency.

Steady traffic? Do the math. It might be time to give your functions a permanent home.

Ten years ago, I discovered Serverless and AWS Lambda, and it changed the way I build software forever.

What started as curiosity quickly turned into conviction. Over the past decade, I’ve designed and shipped production systems entirely on Serverless. I even built a startup from scratch, on a fully Serverless stack and took it to production in just 10 months.

In my four years at AWS, I’ve worked alongside hundreds of customers on their Serverless journeys, from first Lambda functions to complex event-driven architectures. Along the way, I distilled everything I’ve learned into my book, Mastering Event-Driven Microservices in AWS.

Last month, Lee Gilmore, an AWS Hero, reached out and featured me in his Serverless Advocate newsletter, where he posed three thought-provoking questions about the state of Serverless. I’m sharing my answers here, because they touch on things I think every Serverless engineer should be thinking about.

Q1: What is one common mistake you see teams making when building their solutions, and how can they avoid it?

A common mistake is that companies think serverless is all about AWS Lambda, and as a result, they become overly concerned about cold starts.

In reality, serverless is much broader than Lambda. Many use cases can be solved without Lambdas at all. For example, by using direct integrations with Amazon API Gateway or orchestrating workflows with AWS Step Functions.

The key is to step back and evaluate whether Lambda is actually needed. If it’s only being used to move data from one service to another, it’s often unnecessary.

That said, when you do need Lambda, you should know how to optimise it properly.

Three of the most effective techniques are:

1. Optimise memory: Use the AWS Lambda Power Tuning tool to find the optimal memory configuration. Since memory allocation also scales CPU, the right balance can significantly reduce both execution time and cost.

2. Minimise deployment size: Smaller packages lead to faster cold starts, so remove unused dependencies and keep artefacts lean.

3. Use SnapStart: Especially for Java workloads, SnapStart can dramatically reduce cold start latency by initialising functions ahead of time.

By using Lambda intentionally and optimising it when needed, you can avoid unnecessary complexity and get the best out of serverless.

Q2: Which tool, package, or AWS service are you most excited about right now, and why?

Right now, I’m most excited about AWS Lambda durable functions. This is something the ecosystem has needed for a long time, bringing orchestration closer to the application layer. Previously, you could achieve similar outcomes with AWS Step Functions, but local development, testing, and debugging were often cumbersome.

Although this may seem similar to Step Functions, the trade-offs are important:

Use Lambda durable functions when:

• Your team prefers standard programming languages and familiar development tools

• Your application logic primarily lives inside Lambda functions

• You’re building Lambda-centric systems with tight coupling between workflow and business logic

Use Step Functions when:

• You need a visual workflow representation for cross-team visibility

• You’re orchestrating multiple AWS services and want native integrations without writing custom SDK code

• You want zero-maintenance infrastructure (no patching or runtime concerns)

Durable functions make it much easier to build complex, long-running workflows directly in code, opening the door to more advanced use cases like multi-step processes and agent-style orchestration, without sacrificing developer experience.

Q3: What is your favourite trick or tip that the readers may find interesting?

A common anti-pattern I see is treating AWS Lambda as “one service = one function.” This often leads to architectures with hundreds of tiny Lambda functions, which quickly become difficult to manage, deploy, and reason about.

Instead, treat your Lambdas as microservices within a bounded context. It’s perfectly fine, and often preferable, to group related functionality together. For example, within a “users” domain, you can have both ‘createUser’ and ‘deleteUser’ handled by the same Lambda.

When deciding how to group your functions, consider these factors:

• Bounded contexts

• Team organisation

• Scoped IAM permissions

• Common code dependencies

• Common downstream dependencies

• Initialisation time (cold start impact)

• Memory configuration

A powerful way to implement this approach is the Lambda Web Adapter pattern. Instead of creating one Lambda per HTTP endpoint, you run a traditional web framework inside a single Lambda and handle routing internally. This allows you to use familiar frameworks like Express.js, Flask, Django, Spring Boot, or ASP.NET.

The result is a more maintainable system that aligns with real domain boundaries, without losing the benefits of serverless.

Conclusion

Serverless has matured enormously over the past decade, but the fundamentals remain the same: build only what matters, let the cloud handle the rest, and always optimize for simplicity. Whether it’s choosing the right tool for the job, embracing new capabilities like Lambda durable functions, or structuring your Lambdas around real domain boundaries, the goal is to ship faster with less operational burden. If you want to go deeper on event-driven architectures, my book Mastering Event-Driven Microservices in AWS covers these patterns and many more in detail.

You went serverless. API Gateway in front of Lambda, clean architecture, no servers to manage. It felt great at 10,000 requests a day. Then your product grew, and now you’re staring at a $2,000/month API Gateway bill wondering what happened.

Here’s the uncomfortable truth: API Gateway’s pricing model has a scaling cliff that nobody talks about during the honeymoon phase.

The Math That Changes Everything

API Gateway REST APIs charge $3.50 per million requests (after the first 333 million/month, it drops slightly). Sounds cheap in isolation. Let’s do the math for a moderately successful API:

• 50 million requests/month

• API Gateway cost: ~$175/month

Now the same traffic through an Application Load Balancer:

• ALB fixed cost: ~$22/month (base + LCUs)

• Per-request component: negligible at this scale

That’s already an 8x difference, and it only gets worse as you scale. At 500 million requests/month, you’re looking at $1,750 for API Gateway vs. roughly $50–80 for an ALB. The gap becomes a canyon.

“But API Gateway Gives Me More Features”

This is the argument that keeps teams locked in. And it’s partially true. REST APIs give you usage plans, API keys, request validation, and caching built in.

But ask yourself honestly: how many of those features are you actually using?

Most production APIs I’ve seen use API Gateway as a glorified proxy. The Lambda function does all the validation, auth happens in a middleware layer or authorizer, and nobody configured the built-in caching. If that sounds like your setup, you’re paying a premium for a feature set you’re not consuming.

HTTP APIs: The Middle Ground Nobody Considers

In 2019, AWS launched HTTP APIs, a stripped-down API Gateway variant at $1.00 per million requests. That’s a 70% discount over REST APIs for the same basic function: route a request to Lambda.

HTTP APIs support JWT authorizers, CORS configuration, path parameters, and Lambda proxy integration. For most CRUD APIs, that’s the complete feature set you need.

If you’re running REST APIs today and not using usage plans, API key management, or request/response transformation at the gateway level, you’re overpaying by 3.5x for no reason.

When ALB + Lambda Actually Wins

ALB can invoke Lambda directly. No API Gateway in the path at all. You lose the API management features entirely, but you gain:

• Predictable pricing that barely moves with traffic volume

• Health checks and target group routing baked in

• gRPC support if you need it

• No 29-second timeout ceiling

The trade-off: you manage SSL certificates, you don’t get built-in throttling, and monitoring requires more CloudWatch configuration. But for high-throughput internal APIs or backend-to-backend communication, ALB is dramatically cheaper.

The Decision Framework

Here’s how I think about it:

Stay on API Gateway REST APIs if you genuinely use usage plans, per-client throttling, API key quotas, or request transformation templates. These are legitimate features with no ALB equivalent.

Switch to HTTP APIs if your Gateway is a passthrough proxy with JWT or Lambda authorizer. Same developer experience, 70% cost reduction.

Switch to ALB if you’re processing more than 100M requests/month, your APIs are internal or don’t need API management features, or you’re hitting the 29-second timeout limit.

The Takeaway

API Gateway is not expensive. API Gateway at scale without using its premium features is expensive. The mistake isn’t choosing API Gateway on day one — it’s never re-evaluating as your traffic grows.

Check your current monthly request count. Run the math against HTTP APIs and ALB. The five minutes of arithmetic might save you more than your last week of performance optimization work.

Proof of concepts shouldn’t take weeks. At AWS, we build many POCs for customers. Quick, focused prototypes that validate an idea, demonstrate feasibility to stakeholders, and inform the path forward. Whether it’s a new integration pattern, an AI-powered workflow, or a migration proof point, the goal is always the same: show, don’t tell.

Claude Code has become a genuine accelerator for this kind of work. Paired with AWS serverless services — Lambda, API Gateway, DynamoDB, Step Functions — it helps me go from idea to working prototype in hours rather than days. The boilerplate disappears. The IAM headaches shrink. The iteration cycles get tighter.

But here’s what I’ve learned the hard way: speed without structure creates risk.

The Problem with Moving Too Fast

I’ve seen it in my own POCs and in customer engagements. Claude Code scaffolds an entire API in minutes, but then you realise the permissions are too broad, the error handling is inconsistent, or the generated code drifts from your intended architecture. For a throwaway prototype, maybe that’s fine. But the moment a POC starts to look promising — the moment a stakeholder says “let’s run with this” — those shortcuts become technical debt.

The issue isn’t Claude Code itself. It’s that most of us treat it as a raw accelerator without building the harness around it: the specs, constraints, tests, and guardrails that keep agent behaviour reliable and predictable.

Harness Engineering: The Missing Piece

This is exactly why I’m excited about an upcoming workshop that tackles this head-on: Hands-On: Harness Engineering with Claude, hosted by Packt Publishing on Thursday, August 6, 2025 (9:00–11:30 AM EDT).

The workshop teaches harness engineering — the practical discipline of building the surrounding system that makes Claude Code’s behaviour more reliable, testable, constrained, and trustworthy. Instead of relying on prompting alone, you learn how to combine:

• Specs and instructions — turning requirements into executable guidance that steers Claude Code’s output

• Permissions and hooks — constraining what the agent can and cannot do

• Tests and verification — validating outputs against acceptance criteria automatically

• Logging and observability — understanding what the agent actually did and why

This is the difference between “Claude Code wrote something that looks right” and “Claude Code produced a verified, reviewable output within defined boundaries.”

Why This Matters for Serverless POCs

When I build serverless POCs with Claude Code, the harness is what lets me move fast and stay confident. A well-written spec means the generated Lambda functions match the architecture I intended. Permission hooks prevent the agent from creating overly permissive IAM policies. Tests validate that the API actually handles edge cases before I demo it to a customer.

The result: I keep the speed advantage — POCs in hours, costs in pennies — without the anxiety of shipping something I haven’t properly reviewed.

Who Should Attend

If you’re using Claude Code (or any AI coding agent) for real work — whether that’s serverless POCs, infrastructure automation, or application development — this workshop fills a critical gap. It’s not about prompting tricks. It’s about building an engineering framework that optimises for trust, predictability, and production readiness.

Event details:

• 📅 Thursday, August 6 | 9:00–11:30 AM EDT

• 💻 Online — join from anywhere

• 🎟️ Register on Eventbrite

Speed is table stakes now. Reliability is the differentiator. Learn how to build both into your Claude Code workflows.

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.