I’ve conducted hundreds of interviews at AWS, so I know firsthand what companies look for when hiring Cloud Engineers and Cloud Architects.

In this article, I’ll break down the 4 key skills you need to focus on to stand out and succeed in your next Cloud interview.

Read more

The idea is simple: instead of forcing a web application into the traditional Lambda handler model, you can now run a standard Node.js HTTP server directly on Lambda. Express, Hono, Fastify, and other frameworks can run without Lambda-specific adapters or wrappers.

For web developers, that distinction matters.

Traditional Lambda vs. Web Functions

Traditional Lambda functions, now referred to as Lambda Event Functions, are fundamentally event-driven. AWS invokes your handler with an event, your code processes it, and the invocation finishes.

That model is excellent for workloads such as S3 events, SQS consumers, EventBridge automation, scheduled jobs, and asynchronous processing.

But building a traditional web application on Lambda often means adapting your application to that execution model.

Lambda Web Functions flip the model around.

Your application behaves like a normal web server: it listens on a port and handles HTTP requests. Lambda manages the infrastructure underneath it.

The other major difference is concurrency. Traditional Lambda execution is centered around individual invocations, while a Web Function execution environment can handle multiple HTTP requests concurrently. AWS says an environment can handle up to 128 concurrent requests, depending on workload and configuration.

That has an important consequence: a warm environment can serve many requests instead of requiring a separate execution environment for every request.

The billing model is different too

Traditional Lambda uses wall-clock execution time for billing.

Web Functions introduce active CPU billing. If your application is waiting on a database query or downstream API, it isn’t consuming CPU at the same rate, so you’re not paying for that waiting time as active CPU. Memory, requests, and data transfer are still billed.

For I/O-heavy APIs, this could make the economics particularly interesting.

Where Web Functions fit

This isn’t a replacement for traditional Lambda. It’s another tool in the serverless toolbox.

Use Event Functions when your workload is fundamentally event-driven.

Use Web Functions when you’re building HTTP-native workloads: REST or GraphQL APIs, server-side rendered applications, microservices, streaming endpoints, and AI inference APIs. Web Functions also support native HTTP streaming and can scale down to zero.

There’s another intriguing feature: multi-Region deployment. AWS can replicate a Web Function across selected Regions and use latency-based routing to send users to the closest deployment.

The Bigger Picture

For years, serverless developers have had to choose between the simplicity of Lambda and the programming model of a traditional web server.

Lambda Web Functions blur that boundary.

You get the familiar Node.js server model, but without managing servers, load balancers, or scaling infrastructure. For teams already building modern JavaScript applications, that could make Lambda considerably more attractive.

The key question now isn’t “Can I run my web app on Lambda?” It’s “Why wouldn’t I?”

To see Lambda Web Functions in action, see the AWS News Blog announcement.

Whether you are interviewing for a Cloud Engineer, Solutions Architect, DevOps Engineer, Software Engineer, Cloud Architect, or Site Reliability Engineer role, interviewers want to understand whether you can reason about real systems.

They want to know whether you understand how cloud services fit together, how architectural decisions affect reliability, scalability, security, and cost, and what you would actually do when something breaks at 2 a.m.

That is why the strongest interview answers usually follow a simple pattern:

Explain the concept. Explain why it matters. Give a practical example. Mention the trade-off.

Based on the interviews I conduct every week, here are 10 cloud interview questions that come up frequently, a…

Read more

So if you’re designing a new workload today, you’ll probably ask yourself: should this be a Lambda function or a MicroVM? In this post I’ll cover how each one works, where they differ, and a simple way to choose between them.

The Shared Foundation: Firecracker

The two services have more in common than you might expect. Every Lambda function invocation already runs inside a Firecracker microVM. That’s the lightweight virtualization technology AWS open-sourced, and it gives you hardware-level isolation with very fast startup. Lambda SnapStart then used Firecracker’s snapshotting to restore pre-initialized environments instead of booting …

Read more

The agent is fast, but if it doesn’t have the right information, it’s still guessing. And when you’re working with AWS infrastructure, those guesses can get expensive.

I ran into this recently while working with the Agent Toolkit for AWS. It gives coding agents access to current AWS documentation, predefined workflows, and controls around how they interact with AWS.

In this post, I’ll explain what the toolkit does, how the different pieces fit together, and how I used it to build a small serverless project in a few minutes.

Why Your Agent Needs a Toolkit

Most coding agents can create the b…

Read more

In this article, I’ll walk you through what the Solutions Architect role at AWS actually looks like.

1. The Majority of Time Is With Customers

The single biggest thing to understand is that most of my time is spent with customers. Not designing in isolation, but in the room (or on the call) with the people who actually run the business. That means nurturing relationships across the whole spectrum: earning the trust of C-level executives who care about outcomes, cost, and risk, and building deep credibility with the technical teams who will live with whatever we design.

A lot of that work is deceptively simple: asking the right questions. It’s tempting, especially early on, to hear “we want to build a data lake” and immediately start sketching S3 buckets and Glue jobs. But the good SAs slow down and ask why. What business outcome are they chasing? What does success look like in six months? What’s the team’s actual skill level? Everything a Solutions Architect does starts and ends with the customer’s problem. AWS has this deeply ingrained principle of “working backwards” from the customer, and as an SA you live it every single day.

From there, the days fill up with the fun stuff: sketching architectures on the whiteboard, putting together demos, spinning up proofs of concept to de-risk a big decision, and running workshops to level up a customer’s team. One morning I might be helping a fintech startup process payments at scale without falling over on Black Friday; that same afternoon I could be walking a CTO through a multi-year migration strategy. No two days look the same.

Travel is a real part of the mix, too. Meeting customers where they are has taken me to London, Munich, Berlin, Barcelona, Amsterdam, Latvia, Las Vegas, Seattle, and plenty of places in between. There’s a lot you can accomplish over a video call, but nothing replaces sitting across a table from a team, sketching on their whiteboard, and building the kind of trust that only happens face to face.

Read more

That’s where the circuit breaker pattern comes in. Let me break down what it is, why it matters, and how you can implement it elegantly with AWS Step Functions.

What Is a Circuit Breaker, Really?

Think of a circuit breaker in your home’s electrical panel. When there’s a surge, it trips and cuts the power to protect your appliances from frying. Once things are safe again, you flip it back on. The software version works exactly the same way.

When a downstream service starts failing, a soft…

Read more

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 …

Read more

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…

Read more

“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” underst…

Read more

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.

Read more

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…

Read more

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…

Read more

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 mec…

Read more

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 weake…

Read more

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…

Read more

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…

Read more

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…

Read more

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…

Read more