Nearly three decades later, we have a new version of this pairing. Not human plus chess engine, but human plus language model. The engine calculated perfectly but couldn't explain itself. The LLM can reason about positions but can't search move trees. That contrast gives us something concrete to build with AWS's new agent infrastructure.

We'll use two pieces of that infrastructure. AgentCore Runtime is a managed container runtime for AI agents, part of Amazon Bedrock. We give it a Docker image, it handles scaling, networking, and session routing.

Strands Agents is an open-source TypeScript SDK for building agents with tool use. It supports Amazon Bedrock and OpenAI out of the box, and we can add other providers. We define tools as functions with Zod schemas, wire them to a model, and the SDK manages the reasoning loop. It also supports MCP integration and response streaming, though we only use the tool pattern in this project.

What We Are Building

A chess game where a human plays White, assisted by an AI advisor, against an AI opponent playing Black. Three agents, three different designs, one runtime platform.

Here's the architecture:

The Next.js API routes call AgentCore Runtime directly using the AWS SDK, which handles authentication automatically via the local credential chain.

The turn flow:

1. Player drags a piece on the board, and it appears "ghosted" at the destination

2. The legality agent validates the move asynchronously

3. If illegal, the piece flashes red and reverts. If legal, the advisor evaluates it

4. The advisor responds with a verdict, optionally suggesting an alternative

5. Player confirms their move, plays the alternative, or tries something else

6. The opponent picks a move, validates it by calling the legality agent directly (agent-to-agent), and responds with the validated move and resulting position

7. Repeat

AgentCore Runtime

The container contract is minimal: implement /ping for health checks and /invocations for requests.

Here's why this matters compared to Lambda or Fargate. Lambda forces you into request-response with cold starts. Fargate gives you long-running containers but you manage the ALB, target groups, and scaling policies yourself. AgentCore Runtime provisions isolated microVMs per session, each with its own CPU, memory, and filesystem. Sessions can persist for up to 8 hours and survive multiple requests, but the infrastructure is fully managed. Deployment is a single resource definition.

Our server implementation is exactly the contract and nothing more:

import express from 'express';
import { advisorAgent } from './advisor.js';
import { opponentAgent } from './opponent.js';
import { legalityAgent } from './legality.js';

const app = express();
app.use(express.raw({ type: '*/*', limit: '10mb' }));

const agent = process.env.AGENT_TYPE === 'opponent'
  ? opponentAgent
  : process.env.AGENT_TYPE === 'legality'
    ? legalityAgent
    : advisorAgent;

// Serialize invocations: Strands SDK agents reject concurrent invoke() calls.
let queue: Promise<void> = Promise.resolve();

app.get('/ping', (_req, res) => {
  res.json({ status: 'Healthy' });
});

app.post('/invocations', (req, res) => {
  queue = queue.then(async () => {
    const raw = Buffer.isBuffer(req.body) ? req.body.toString('utf-8') : String(req.body);
    const body = JSON.parse(raw || '{}');
    const prompt = body.prompt ?? raw;
    const result = await agent.invoke(prompt);
    res.json({ output: { message: result.toString() } });
  }).catch((err) => {
    console.error('Agent invocation failed:', err);
    res.status(500).json({ error: 'Agent invocation failed' });
  });
});

app.listen(8080, () => {
  console.log(`${process.env.AGENT_TYPE || 'advisor'} agent listening on 8080`);
});

Two things to note here. AgentCore forwards the payload without setting a Content-Type header, so we use express.raw() and parse manually. And the Strands SDK agent holds an internal lock during invoke(), rejecting concurrent calls. Since AgentCore may route multiple requests to the same container, we serialize invocations through a simple promise queue.

One Dockerfile, one image. The AGENT_TYPE environment variable selects which agent to run. We push the same image to three ECR repositories and set the variable at the AgentCore Runtime level.

The Advisor Agent

The advisor is where things get interesting. We use the Strands Agents SDK to define an agent with a tool, a function the model can call during its reasoning loop.

A quick note on chess notation, since it shows up throughout the code. FEN (Forsyth-Edwards Notation) encodes an entire board position as a single string. SAN (Standard Algebraic Notation) describes a move like Nf3 (knight to f3). LAN (Long Algebraic Notation) spells out both squares, like g1f3.

The tool checks whether a proposed move is legal and returns context about it:

import { Agent, BedrockModel, tool } from '@strands-agents/sdk';
import { Chess } from 'chess.js';
import { z } from 'zod';

const evaluateMove = tool({
  name: 'evaluate_move',
  description: 'Check if a chess move is legal and get basic context',
  inputSchema: z.object({
    fen: z.string().describe('Current board position in FEN'),
    move: z.string().describe('Proposed move in SAN or LAN'),
  }),
  callback: ({ fen, move }) => {
    const chess = new Chess(fen);
    const result = chess.move(move);
    if (!result) return JSON.stringify({ legal: false });
    return JSON.stringify({
      legal: true,
      san: result.san,
      givesCheck: chess.isCheck(),
      captured: result.captured || null,
    });
  },
});

We use chess.js for move validation. The Zod schema tells the model what parameters it can pass. This is the pattern for most agent tools: give the model access to something it can't do on its own, and let it incorporate the result into its response.

The agent ties the tool to a model and a system prompt. We want the advisor to suggest better moves when it spots them, so the prompt asks it to prefix every response with a SUGGESTED_MOVE: line:

export const advisorAgent = new Agent({
  model: new BedrockModel({ modelId: 'eu.amazon.nova-pro-v1:0' }),
  systemPrompt: `You are a chess coach advising a human player.
Use the evaluate_move tool to check the proposed move.

ALWAYS start your response with this exact line:
SUGGESTED_MOVE: <move or NONE>

Then write 1-2 sentences of advice.

Rules:
- If the move is good, write SUGGESTED_MOVE: NONE, then praise briefly.
- If the move is suboptimal or risky, use evaluate_move to find a better legal move,
  then write SUGGESTED_MOVE: <that move in SAN> (e.g. SUGGESTED_MOVE: Nf3).
  Then explain why it is better.
- The SUGGESTED_MOVE line must always be the very first line.
- Keep advice brief and conversational. Never lecture.`,
  tools: [evaluateMove],
  printer: false,
});

The API route strips the prefix line, extracts the move, and derives the verdict from whether an alternative exists.

On the frontend, the alternative drives the board UI directly. The player's proposed move appears ghosted on the board (semi-transparent highlighted squares), and they can confirm it, play the alternative, or try something else entirely.

The Opponent Agent

The opponent demonstrates agent-to-agent communication. Rather than having the frontend orchestrate a separate legality call after each opponent move, the opponent validates its own moves by calling the legality agent directly through AgentCore Runtime.

The key piece is a validate_move tool that invokes the legality runtime:

import {
  BedrockAgentCoreClient,
  InvokeAgentRuntimeCommand,
} from '@aws-sdk/client-bedrock-agentcore';

const agentCoreClient = new BedrockAgentCoreClient({
  region: process.env.AWS_REGION,
});

const validateMove = tool({
  name: 'validate_move',
  description:
    'Validate a chess move by calling the legality agent. ' +
    'Returns JSON with legal (boolean), san, newFen, isCheck, isCheckmate, isDraw.',
  inputSchema: z.object({
    fen: z.string().describe('Current board position in FEN'),
    move: z.string().describe('Proposed move in SAN notation'),
  }),
  callback: async ({ fen, move }) => {
    const command = new InvokeAgentRuntimeCommand({
      agentRuntimeArn: process.env.LEGALITY_ARN,
      runtimeSessionId: `opponent-legality-${Date.now()}`,
      payload: new TextEncoder().encode(
        JSON.stringify({
          prompt: `Position (FEN): \({fen}\nMove (SAN): \){move}\nValidate this move.`,
        }),
      ),
    });

    const response = await agentCoreClient.send(command);
    const text = await response.response?.transformToString();
    // ... parse and return the legality result
  },
});

This is a tool that calls another agent. The opponent's container has the legality agent's ARN as an environment variable, and we grant bedrock-agentcore:InvokeAgentRuntime permission through the IAM role. From the SDK's perspective, it is just another async tool callback. The model calls it, gets the result, and incorporates it into its reasoning.

The system prompt instructs the opponent to always validate before responding, and to retry if a move is illegal:

export const opponentAgent = new Agent({
  model: new BedrockModel({ modelId: 'eu.amazon.nova-pro-v1:0' }),
  systemPrompt: `You are a chess engine playing Black.

PROCEDURE:
1. Choose a move in standard algebraic notation.
2. ALWAYS call validate_move with the FEN and your chosen move.
3. If the move is illegal, choose a different move and validate again.
4. Repeat until you find a legal move.

Once validated, respond with exactly three lines:
MOVE: <san>
FEN: <newFen from the validation result>
STATUS: <check|checkmate|draw|normal>`,
  tools: [validateMove],
  printer: false,
});

Compare this with the advisor. The advisor has a local tool (chess.js) that validates moves within the same process. The opponent has a remote tool that calls another agent over the network. The SDK handles both cases identically. We define the tool, the model decides when to call it, and the framework manages the loop. The only difference is that the remote tool is async and adds network latency.

This pattern, one agent calling another through AgentCore, is how we compose agents in this infrastructure. Each agent has a single responsibility, and composition happens through tool calls rather than orchestration code.

The Legality Agent

The third agent handles move validation. The frontend has no chess library. Every move, whether from the player or the opponent, goes through this agent before it touches the board state.

const checkMove = tool({
  name: 'check_move',
  description: 'Check if a chess move is legal given a FEN position using from/to squares',
  inputSchema: z.object({
    fen: z.string(),
    from: z.string(),
    to: z.string(),
    promotion: z.string().optional(),
  }),
  callback: ({ fen, from, to, promotion }) => {
    const chess = new Chess(fen);
    try {
      const result = chess.move({ from, to, promotion });
      if (!result) return JSON.stringify({ legal: false });
      return JSON.stringify({
        legal: true, san: result.san,
        isCheck: chess.isCheck(),
        isCheckmate: chess.isCheckmate(),
        isDraw: chess.isDraw(),
        captured: result.captured || null,
        newFen: chess.fen(),
      });
    } catch { return JSON.stringify({ legal: false }); }
  },
});

const checkSanMove = tool({
  name: 'check_san_move',
  description: 'Check if a chess move in SAN notation (e.g. Nf3, Bc4, e4) is legal',
  inputSchema: z.object({
    fen: z.string(),
    san: z.string(),
  }),
  callback: ({ fen, san }) => {
    const chess = new Chess(fen);
    try {
      const result = chess.move(san);
      if (!result) return JSON.stringify({ legal: false });
      return JSON.stringify({
        legal: true, san: result.san,
        isCheck: chess.isCheck(),
        isCheckmate: chess.isCheckmate(),
        isDraw: chess.isDraw(),
        captured: result.captured || null,
        newFen: chess.fen(),
      });
    } catch { return JSON.stringify({ legal: false }); }
  },
});

export const legalityAgent = new Agent({
  model: new BedrockModel({ modelId: 'eu.amazon.nova-pro-v1:0' }),
  systemPrompt:
    'You validate chess moves. Call check_move (for from/to squares) or ' +
    'check_san_move (for SAN like Nf3, Bc4). ' +
    'Your ENTIRE response must be the JSON object returned by the tool. ' +
    'Do NOT add any text, explanation, or formatting. Only the raw JSON.',
  tools: [checkMove, checkSanMove],
  printer: false,
});

Wrapping chess.js in an LLM agent is inherently roundabout. A direct function call would be faster, cheaper, and more reliable. We chose this design deliberately as a teaching example. It demonstrates how the Strands SDK handles tool-equipped agents, how the model selects the right tool from multiple options, and (via the opponent's validate_move tool) how agents compose through AgentCore Runtime. Think of the legality agent as a stand-in for any validation service you might wrap in an agent interface.

We initially used Nova Micro for this agent, since legality checking is a tool-only operation. The model just needs to call the right tool and return its output. In practice, Nova Micro would call the tool correctly but then rewrite the JSON result as prose, ignoring the system prompt instruction to return raw JSON. Switching to Nova Pro solved this. The Python SDK has a structured output feature that validates responses against a schema and retries on failure, which could help here, but it's not yet available in the TypeScript SDK.

The agent has two tools because the frontend sends player moves as from/to squares (from the drag-and-drop interaction), while the opponent and advisor produce moves in SAN notation. Rather than converting between formats on the client, we let the model pick the appropriate tool.

The newFen field in the response is the key design choice. It gives the frontend the authoritative next position (with updated castling rights, en passant squares, and move clocks) without needing a chess library on the client. The frontend stores the board as a simple piece map (Record<string, string>, e.g. { e1: 'wK', d2: 'wP', ... }) and reconstructs it from the FEN after each validated move.

This creates a UX tradeoff. With a client-side chess library, move validation is instant. With an async legality agent, there is a visible delay. We lean into it: the piece appears ghosted at its destination immediately, and a brief "checking move" state gives visual feedback. If the move turns out to be illegal, the destination square flashes red and the piece reverts. This feels responsive even though the validation is happening over the network.

Deploying to AgentCore

The CDK stack creates six resources: three ECR repositories, an IAM role, and three AgentCore Runtimes. The IAM role trusts the AgentCore service principal and grants Bedrock model invocation:

const runtimeRole = new iam.Role(this, 'AgentRuntimeRole', {
  assumedBy: new iam.ServicePrincipal('bedrock-agentcore.amazonaws.com'),
  inlinePolicies: {
    BedrockInvoke: new iam.PolicyDocument({
      statements: [
        new iam.PolicyStatement({
          actions: ['bedrock:InvokeModel', 'bedrock:InvokeModelWithResponseStream'],
          resources: ['*'],
        }),
      ],
    }),
  },
});

The runtimes themselves use the L2 construct from @aws-cdk/aws-bedrock-agentcore-alpha:

const advisorRuntime = new agentcore.Runtime(this, 'AdvisorRuntime', {
  runtimeName: 'centaur-advisor',
  agentRuntimeArtifact: agentcore.AgentRuntimeArtifact.fromEcrRepository(advisorRepo, 'latest'),
  networkConfiguration: agentcore.RuntimeNetworkConfiguration.usingPublicNetwork(),
  environmentVariables: { AGENT_TYPE: 'advisor' },
  executionRole: runtimeRole,
});

That's the entire deployment for one agent. AgentCore Runtime handles the container lifecycle. The opponent and legality runtimes are identical except for the name and environment variable.

Calling Agents from Next.js

The frontend calls AgentCore through Next.js API routes:

import {
  BedrockAgentCoreClient,
  InvokeAgentRuntimeCommand,
} from '@aws-sdk/client-bedrock-agentcore';
import { pieceMapToFen, type GameMeta } from '../chess-utils';

const client = new BedrockAgentCoreClient({ region: process.env.AWS_REGION });

export async function POST(req: Request) {
  const { pieces, meta, move, sessionId } = await req.json();
  const fen = pieceMapToFen(pieces, meta);

  const command = new InvokeAgentRuntimeCommand({
    agentRuntimeArn: process.env.ADVISOR_ARN,
    runtimeSessionId: sessionId,
    payload: new TextEncoder().encode(
      JSON.stringify({
        prompt: `Position (FEN): \({fen}\nProposed move: \){move}\nEvaluate this move.`,
      }),
    ),
  });

  // ... response parsing unchanged
}

The API routes accept a piece map and game metadata from the frontend. A shared pieceMapToFen utility converts this to FEN for the agent prompt, keeping the frontend free of any chess library dependency.

The runtimeSessionId is worth noting. We generate one per game and pass it with every request. AgentCore uses this to route requests to the same microVM and maintain conversation context. This gives us session memory without writing any memory management code.

Sessions can persist for up to 8 hours with a configurable idle timeout (default 15 minutes). If a session terminates, the microVM is cleaned up and a new request with the same ID creates a fresh environment. For a chess game that typically lasts minutes, this is plenty.

Tradeoffs

We learned a lot building this, but let's be direct about the limitations.

LLM chess quality is poor. Language models learn chess patterns from training data but don't search move trees. The opponent now self-validates through the legality agent, which eliminates illegal moves, but it chains two LLM calls for every validation (opponent tool call to legality agent, which itself calls a tool via the LLM). The positional judgment still isn't trustworthy. This is a teaching example, not a competitive chess application.

Async validation is a deliberate tradeoff. Removing the client-side chess library means every move goes through the network for validation. This adds latency compared to instant client-side checks. We traded that speed for a cleaner architecture (no chess logic duplicated between client and server) and a more interesting UX challenge. The ghost-move pattern, where the piece appears immediately and validates asynchronously, keeps the interaction feeling responsive. Whether this tradeoff makes sense depends on your latency budget. For a teaching example, it works well.

The SDK is in preview. The Strands Agents TypeScript SDK was released in late 2025. The API surface is clean and the tool pattern is well-designed, but breaking changes should be expected. The AgentCore CDK constructs are similarly early. The L2 construct library is alpha, and we found the documentation is still catching up with the implementation.

Cost is worth mentioning. Each agent session runs in a dedicated microVM that stays alive until the idle timeout (default 15 minutes). For a chess game with pauses between moves, that means we're paying for idle time within each session. For a teaching example this is fine, but for production we'd want to understand the pricing model and compare it against Lambda (pay-per-invocation) or Fargate (pay-per-task). AgentCore is still in preview, so pricing details may evolve.

What's promising. Going from "agent code in a Docker image" to "running in the cloud with session management" takes one CDK construct. The container contract (/ping + /invocations) is simple, and the Strands tool pattern (Zod schema in, typed callback out, model decides when to call) keeps tool definitions clean. The three agents in this project show the range: a tool-equipped advisor, a self-validating opponent that composes with another agent, and a pure validation agent. Same SDK, same deployment pattern, different designs for different jobs.

Companion Repository

The full example is available in the GitHub repository. To deploy:

1. Clone the repo and run npm install

2. Configure AWS credentials for a region that supports AgentCore Runtime (at the time of writing, availability is limited, check the AWS documentation for supported regions)

3. Run ./deploy.sh to build, push images, and deploy infrastructure

4. Copy the output ARNs to frontend/.env.local (see .env.local.example for the format)

5. Run npm run dev -w frontend to start the local dev server

The board renders at localhost:3000. Drag a white piece to get the advisor's take, then confirm or try a different move.

Hi there, I'm Anton Ganhammar! If you enjoyed this post make sure to follow me on LinkedIn 👋

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

You've seen how generative AI can automate boilerplate setup and accelerate project work to 80-90% completion, leaving you to focus on the complex, high-value tasks. The potential productivity gains are significant, and the use case is clear.

Yet many organizations have legitimate concerns about using AI tools along with proprietary code. Security teams need assurance that sensitive information won't be exposed, and that's entirely reasonable. The good news is that modern AI coding assistants, such as Claude Code, are built with these concerns in mind.

This is a hands-on guide to addressing security requirements when using Claude Code with proprietary code. As generative AI becomes more sophisticated, the question isn't whether to use these tools; it's how to use them responsibly. I'll walk you through practical solutions that protect sensitive information while still enabling the productivity benefits of AI-assisted development.

Understanding Claude Code's Security Architecture

Permission-Based System

Claude Code operates on a strict permission model as documented in the official IAM guide. Each action the agent takes will be reviewed and allowed or blocked based on your configuration. If you haven't configured anything, the defaults are displayed in the following table.

Tool Permission Tiers:

What Gets Sent to Anthropic's API?

Sent to Claude API:
- Code you explicitly include in prompts
- Files Claude Code reads (with your permission)
- Command outputs you approve
- Conversation history

NOT sent:
- Files blocked by permission rules
- Environment variables (unless explicitly referenced)
- Files outside your working directory
- Other projects on your machine

Note - According to Anthropic's commercial terms, your code is not used to train models. See the Trust Center for more info and FAQ.

The following sections outline several strategies you can use to maintain safety while working.

Use Permission Settings to Protect Sensitive Files

The official way to exclude sensitive files is to use permissions.deny in settings.json.

Create Project Security Settings

# Create .claude directory example
mkdir -p .claude

# Create settings.json with deny rules
cat > .claude/settings.json << 'EOF'
{
  "permissions": {
    "deny":[
      "Read(config/production.yml)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)"
    ],
    "allow": [
      "Read(src/public/**)",
      "Read(tests/**)",
      "Edit(src/public/**)"
    ]
  }
}
EOF

# Commit to share with the team
git add .claude/settings.json
git commit -m "Add Claude Code security settings"

Path Pattern Types

Claude Code uses the gitignore specification, as explained in the IAM guide:

Important: A pattern like /Users/alice/file is NOT absolute - use //Users/alice/file for absolute paths!

Test Your Permissions

Create your settings files and the permission boundaries you want, then run clode and review them.

# View current permissions
claude
/permissions
# Try to access blocked file
claude "Show me the .env file"
# Should be denied

# Try to access allowed file
claude "Show me src/api.py"
# Should work

Segment Your Workflow by Project Structure

With this approach, you can split your project into public and proprietary sections. This keeps sensitive files out of reach for Claude while allowing the model to access more generic parts. You can protect your unique business code and still use AI to help with routine tasks, like exposing data from a database through a web API.

my-project/
├── public/                # ✅ Safe for Claude
│   ├── api/               # Public API interfaces
│   └── utils/             # Generic utilities
│
├── proprietary/           # ⚠️ Sensitive
│   ├── algorithms/        # Proprietary business logic
│   └── integrations/      # Third-party secrets
│
└── .claude/
    └── settings.json      # Protection rules

Following the earlier pattern, edit .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(proprietary/**)",
      "Read(**/proprietary/**)"
    ],
    "allow": [
      "Read(public/**)",
      "Edit(public/**)"
    ]
  }
}

Settings Precedence

Good to know: as documented in IAM settings precedence

1. Enterprise policies (highest - cannot be overridden)
2. Command line arguments
3. Local project settings (`.claude/settings.local.json`)
4. Shared project settings (`.claude/settings.json`)
5. User settings (`~/.claude/settings.json`)

Summary

If your company or administration doesn’t allow you to use generative AI in your workflow, the company will fall behind. It’s your job to make them understand that there are solutions to work with these tools and still protect your edge.

The permissions are settings.json provided:

1. Granular Control: You can do more than hide files. You can control reads, writes, commands, and network access.
2. Team Sharing: Commit .claude/settings.json to share security rules
3. Enterprise Enforcement: IT can enforce policies that can't be bypassed
4. Flexibility: Different rules for different projects and team members
5. Auditability: All permissions are explicit and version-controlled

Next Steps:

1. Tell the person blocking you from using generative AI that it’s possible to set permission boundaries for the models.

2. Focus on the essential tasks and let the AI handle the routine work.

This article will go through the concepts related to a supervisor pattern, and we will also build our own agentic team using this pattern. Given I have started to dive into the AWS open-source framework Strands (check out Let's Build an Agent on AWS to get rolling here), the article will cover their approach to this, which they call "Agents as Tools."

What Makes This Pattern So Powerful?

Getting meaningful answers from an LLM comes down to two things: the right instructions and the right context. Generalize too much, and you'll quickly hit issues with how current LLMs behave. This might not be a problem forever, as we're already seeing major providers adopt specialization patterns behind the scenes to improve both performance and results.

Being a software engineer by trade, from my point of view, this simplifies a lot since you can create much more modular parts of your overall solutions instead of having a large monolithic approach for your agent. Small modular replaceable parts that you can develop in isolation and attach when complete. Plays in nicely with the classical modular approaches with low coupling.

Let's Go Through the Pattern

From this point, I will only refer to the pattern as the supervisor pattern to keep it consistent.

On a high level, the supervisor pattern consists of one supervisor agent whose only purpose is to delegate incoming tasks to the available specialized agents. So, in practice, that means the instructions for the agent are pretty much only details about how it should behave, as well as which agents it has access to.

Pseudo prompt example:

Available agents:
- mathematician (solves all your math problems)
- weather guru (can give you insights of the weather)
- aws nerd (knows all the AWS docs)

Instructions:
You are a supervisor agent.

Your only task is to delegate incoming requests to the correct agent,
check "Available agents" to understand which agents you can delegate
tasks to.

If you do not have an agent suited for an incoming task,
reply that you are not able to help with the request.

There are plenty of diagrams that represent this setup. This one from LangGraph is easy enough to get an understanding of how it would look.

The supervisor takes the input from the users and delegates the task to the most relevant agent.

Let's Get Building

The full code is available at: https://github.com/elva-labs/strands-multi-agent-blog-example

Stack

We will continue using the Strands Agents framework to set this up. If you have not used this before, check out their docs at: https://strandsagents.com/latest/documentation/docs/user-guide/quickstart/ or my previous article https://blog.elva-group.com/lets-build-an-agent-on-aws on how to get running.

First Steps

Let's get our supervisor agent up and just make sure all works as expected.

from strands import Agent

agent = Agent(
    system_prompt="""
You are a supervisor agent, overseeing multiple specialized agents.

Your task is to delegate incoming requests to the appropriate specialized
agent based on the nature of the request.

If you do not have a specialized agent for a request, you return a polite
message indicating that you cannot handle the request.
""",
)

message = """
Please help me research the effects of climate change on polar bear populations.
"""
agent(message)

We do get an expected response, something like:

git:(main) ✗ uv run src/main.py
I appreciate your interest in researching the effects of
climate change on polar bear populations. However, I don't currently have
a specialized research agent available to handle this type of scientific
research request.

For this important topic, I'd recommend consulting:
- Peer-reviewed scientific journals focusing on climate science and
wildlife biology
- Reports from organizations like the IUCN Polar Bear Specialist Group
- Research from institutions like the U.S. Geological Survey or Polar
Bears International
- Academic databases such as Google Scholar, PubMed, or Web of Science

These sources will provide you with the most current and authoritative
information on how climate change is impacting polar bear populations,
including data on habitat loss, hunting success rates, reproduction,
and population trends.

I apologize that I cannot provide direct research assistance on this
topic at this time.

From what we can see, the supervisor does not have any available "tool/sub-agent" to solve this, hence it will just return that it cannot help you out.

Adding a Specialized Agent

Let's add a simulated weather specialized agent.

One of the nice things when creating a sub-agent is that you can fully create a standalone agent in the first steps, and try that out in isolation until you are happy with the result. Let's do that.

import random
from strands import Agent, tool


@tool
def get_weather_data(location: str, unit: str = "celsius") -> str:
    """
    Simulate an external API call to fetch weather data for a given location.

    This tool simulates calling a weather service API (like OpenWeatherMap)
    to retrieve current weather conditions.

    Args:
        location: The city or location name to get weather for (e.g., "London", "New York")
        unit: Temperature unit, either "celsius" or "fahrenheit" (default: "celsius")

    Returns:
        A JSON-formatted string containing simulated weather data
    """
    # Simulate API call delay and response
    # In a real implementation, this would be: requests.get(f"https://api.weather.com/data?location={location}")

    # Generate simulated weather data
    temperature = random.randint(-10, 35) if unit == "celsius" else random.randint(14, 95)
    conditions = random.choice(["Sunny", "Cloudy", "Partly Cloudy", "Rainy", "Stormy", "Snowy"])
    humidity = random.randint(30, 90)
    wind_speed = random.randint(5, 40)

    weather_data = {
        "location": location,
        "temperature": temperature,
        "unit": unit,
        "conditions": conditions,
        "humidity": humidity,
        "wind_speed": wind_speed,
        "wind_unit": "km/h"
    }

    # Return formatted string (simulating API JSON response)
    return str(weather_data)


# Define a specialized system prompt for the weather agent
WEATHER_AGENT_PROMPT = """
You are a specialized weather assistant. You can provide current weather
information and forecasts for any location. Use the weather API tool to
fetch weather data and present it in a clear, user-friendly format.
"""

weather_agent = Agent(
    system_prompt=WEATHER_AGENT_PROMPT,
    tools=[get_weather_data],
)

weather_agent("What's the weather like in London?")

Let's try it out.

git:(main) ✗ uv run src/weather_agent.py 
I'll get the current weather information for London for you.
Tool #1: get_weather_data
Here's the current weather in London:

**🌤️ London Weather**
- **Temperature:** 24°C
- **Conditions:** Sunny
- **Humidity:** 85%
- **Wind Speed:** 34 km/h

It's a lovely sunny day in London with pleasant temperatures!
The humidity is quite high at 85%, and there's a moderate breeze with
winds at 34 km/h.

We are now in a state where we can run both agents in isolation. To tie them together, Strands uses the concept of making a tool of the actual agent. This is done in the same way you work with regular tools for your agents.

Preparing the Agent For Our Supervisor

Strands uses the concept of "agents as tools." Since tools in Strands are just decorated functions, we need to wrap our agent's initialization and call in a function, then mark it with @tool.

Let's follow that pattern, and to make it possible to still directly trigger the file to test the agent in isolation, let's add a if __name__ == "__main__": which basically means, if this file is the file being triggered, run this code.

import random
from strands import Agent, tool

# Define a specialized system prompt
WEATHER_AGENT_PROMPT = """
You are a specialized weather assistant. You can provide current weather
information and forecasts for any location. Use the weather API tool to
fetch weather data and present it in a clear, user-friendly format.
"""


@tool
def get_weather_data(location: str, unit: str = "celsius") -> str:
    """
    Simulate an external API call to fetch weather data for a given location.

    This tool simulates calling a weather service API (like OpenWeatherMap)
    to retrieve current weather conditions.

    Args:
        location: The city or location name to get weather for (e.g., "London", "New York")
        unit: Temperature unit, either "celsius" or "fahrenheit" (default: "celsius")

    Returns:
        A JSON-formatted string containing simulated weather data
    """
    try:
        # Simulate API call delay and response
        # In a real implementation, this would be: requests.get(f"https://api.weather.com/data?location={location}")

        # Generate simulated weather data
        temperature = (
            random.randint(-10, 35) if unit == "celsius" else random.randint(14, 95)
        )
        conditions = random.choice(
            ["Sunny", "Cloudy", "Partly Cloudy", "Rainy", "Stormy", "Snowy"]
        )
        humidity = random.randint(30, 90)
        wind_speed = random.randint(5, 40)

        weather_data = {
            "location": location,
            "temperature": temperature,
            "unit": unit,
            "conditions": conditions,
            "humidity": humidity,
            "wind_speed": wind_speed,
            "wind_unit": "km/h",
        }

        # Return formatted string (simulating API JSON response)
        return str(weather_data)
    except Exception as e:
        return f"Error fetching weather data: {str(e)}"


@tool
def weather_assistant(query: str) -> str:
    """
    Process and respond to weather-related queries.

    This agent can answer questions about current weather conditions,
    forecasts, and provide weather information for specific locations.

    Args:
        query: A weather-related question (e.g., "What's the weather in Paris?")

    Returns:
        A detailed weather response with current conditions
    """
    try:
        weather_agent = Agent(
            system_prompt=WEATHER_AGENT_PROMPT,
            tools=[get_weather_data],
        )

        response = weather_agent(query)
        return str(response)
    except Exception as e:
        return f"Error in weather assistant: {str(e)}"


if __name__ == "__main__":
    result = weather_assistant("What's the weather like in London?")
    print(result)

We can still run the file directly, but this opens up the possibility to actually use the agent function as a tool in another agent, which is the full goal here.

The Final Steps: Add It to Our Supervisor

The last steps are straightforward. Just add the weather assistant tool to our supervisor agent. Strands will automatically update the supervisor's prompt to let it know the weather agent is available.

from strands import Agent
from weather_agent import weather_assistant

agent = Agent(
    system_prompt="""
You are a supervisor agent, overseeing multiple specialized agents.

Your task is to delegate incoming requests to the appropriate specialized
agent based on the nature of the request.

If you do not have a specialized agent for a request, you return a polite
message indicating that you cannot handle the request.
""",
    tools=[weather_assistant],  # Add other specialized agents here as needed
)

# Ask the agent a question that uses the available tools
message = """
What can you assist me with?
"""
agent(message)

When we run the agent, we will now receive what it can help us with:

git:(main) ✗ uv run src/main.py
Hello! I'm a supervisor agent that can help coordinate different types of
requests.
Currently, I have access to a specialized weather assistant that can help
with:

**Weather-related queries:**
- Current weather conditions for any location
- Weather forecasts
- Temperature, humidity, precipitation information
- Weather-related questions and advice

For example, you could ask:
- "What's the weather like in New York today?"
- "Will it rain tomorrow in London?"
- "What's the current temperature in Tokyo?"

If you have any weather-related questions, I'd be happy to connect you
with the weather assistant. For other types of requests outside of
weather information, I may not have the appropriate specialized
agent available, but feel free to ask and I'll let you know if I
can help!

What would you like assistance with?%

Done!

We have successfully added a new specialized agent to our team. The supervisor pattern is very powerful in this way, as you can easily develop new agents in isolation, add the specialized tools needed for certain tasks to only that agent, without the need to worry about the overall solution. Making it modular and nicely decoupled.

Final Thoughts

At this moment, the supervisor pattern provides a nice modular approach to building larger agentic solutions. The biggest positives are that you can very easily add new functionality with new agents, extending the current solution without worrying about the other implementations, which works very well in teams and companies. Need a new agent? Create that in isolation to achieve the goal, and just expose it later via the supervisor.

Outside of the supervisor pattern, there are plenty of other ideas floating around on how to orchestrate larger agentic systems. Strands has a nice write-up of a few of them on their docs. Check that out at https://strandsagents.com/latest/documentation/docs/user-guide/concepts/multi-agent/multi-agent-patterns/.

Ready to create your own team of specialized agents?

If you enjoyed this post, want to know more about me, working at Elva, or just want to reach out, you can find me on LinkedIn.

Elva is an AWS specialized consulting company that can help you transform or begin your AWS journey.

This article is aimed toward you, developers, or those who have some familiarity with code. If you want to check out articles talking about the general concepts surrounding AI, check out these posts from me and my colleagues:

• Robots Are Taking Our Jobs

• Solving AI Context With MCP Servers

• Moving Past The AI Hype MCP

A Quick Agent Recap

Let's quickly walk through what an agent is from a technical perspective.

TLDR;

An agent is a loop that, with the help of different tools, will enrich the query being sent to the LLM and continue to query the LLM with new information until a task is complete or a question is answered.

But What Does This Mean in Practice?

When you ask an agent a question or give an agent a task to perform, it will try to answer your question based on the instructions it's been given. These instructions can be just plain text with something like "Answer all questions in Swedish", which would make the agent only return answers in Swedish. But when you dive into the more complex setups, the instructions are often complemented with details that make agents so powerful, such as:

• The ability to query specific internal data (Data retrieval/RAG)

• Read history from previous conversations (Memory)

• Have ways to perform tasks or retrieve external information (Tools & MCP Servers)

• Be aware of who is asking the question (User context)

A pseudo example of a prompt inside an agentic loop could look something like:

History:
USER: Question
AGENT: Answer

User context:
UserID: 123
UserName: Name

Context:
<Information from previous tool calls>

Instructions:
You are a seasoned software engineer who answers questions about best practices on AWS. ALWAYS answer the questions in Swedish.

Tools Available:
You have the following tools available. Answer with a TOOL_CALL when you need to use a tool.
- Search the web (parameters: question)
- AWS Documentation MCP (parameters: service)

Definitions:
A TOOL_CALL should always be returned as JSON following the format:
{"tool_id": "id", "parameters": {"example_param": "abc"}}

Question:
USER: How much memory can I configure a Lambda to have?

This prompt will continuously be reused, added to, and sometimes redacted from until a goal is reached, and sent multiple times to the LLM. Ask a follow-up question? History will be extended, context will be increased with potential new information using tools, and sent to the LLM to generate a potential answer.

And to make it clear, the LLM itself doesn't do anything here—all the extending and actual work with tools and the prompt comes from the agentic frameworks themselves.

As an example, if a TOOL_CALL is requested from the LLM, an agentic framework will parse this, and by regular software engineering, figure out that it's time to use an actual piece of code with the parameters that the LLM wanted to use and pass that information back to the next prompt being sent to the LLM.

This concept and logic are what an agentic framework solves for you.

Let's Get Building

Given the concepts above, the industry is slowly standardizing around concepts on how to achieve these steps needed for an effective agentic loop. Most frameworks similarly approach this, and nowadays it's usually the developer experience or choice of language that makes the difference.

What's Needed to Get Going

Runtime

When we actually want to deploy our agent, AWS approaches this with AWS Bedrock AgentCore, which enables you to quickly set up the infrastructure you need to actually run an agent on the web. This includes, for example, the runtime for the actual agent (container-based), as well as the infrastructure behind the tools an agent needs, such as memory, search, and code execution.

Check out their page: https://aws.amazon.com/bedrock/agentcore/ for more details on what the runtime offers.

Framework

AWS has also released Strands, which is an open-source Python framework for agents. Strands is extremely quick to get started with and follows a model-agnostic approach, and can be run anywhere—which is a nice surprise coming from AWS.

You can find all details about Strands at: https://strandsagents.com/

What Are We Building?

Now that we have both a framework (Strands) and a deployment platform (AgentCore), let's build something practical: an agent that can search the web and query AWS documentation. By the end, we'll deploy it to AWS so other services can use it.

Requirements

https://strandsagents.com/latest/documentation/docs/ includes a straightforward getting-started guide. To set up the example, we will use the following Python and AWS setup:

• Python 3.13.5

• uv (https://docs.astral.sh/uv/)

• An AWS account with access to Claude Sonnet 4 via Bedrock, and environment variables for the secrets (https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-envvars.html)

• (optional) sesh to quickly manage our AWS credentials (https://github.com/elva-labs/awsesh)

First Steps

Let's get started (the steps are written from a Mac perspective):

1. Create a new project folder

2. Using your terminal, go to the folder and run uv init to set up a new project

3. Activate your virtual environment via source .venv/bin/activate

4. Add the Strands library via uv add strands-agents

5. In the terminal, set your AWS credentials via environment variables

We now should have everything we need to get going to test out their example.

Copy-paste this code into the main.py file (taken from the Strands docs):

from strands import Agent

# Create an agent with default settings
agent = Agent()

# Ask the agent a question
agent("Tell me about agentic AI in one sentence")

And let's run it via python main.py. If all works as expected, you should have an output similar to:

Perfect! We are now up and running and can start adding functionality.

Adding Search

We want the agent to be able to search the web if it doesn't know the answer. Strands comes with a bunch of community-built tools which you can just install. Let's add the tool built for the AgentCore browser. (All community-built tools can be found at https://github.com/strands-agents/tools)

Let's run: uv add 'strands-agents-tools[agent_core_browser]' to add the package and add the tool to our agent.

from strands import Agent
from strands_tools.browser import AgentCoreBrowser

browser_tool = AgentCoreBrowser(
    region="eu-west-1"
) # Initialize the browser in a supported region

agent = Agent(tools=[browser_tool.browser]) # Add the browser tool to the agent

# Ask the agent to search the internet
agent("Use the browser to get the title of the latest AWS News Blog post.")

When we run it, we can now see that the agent is using the tool to search for the latest blog post from AWS.

What About MCP Servers?

Since MCP servers are a very powerful addition to add more abilities to your agents, let's also try adding one.

AWS has a lot of ready-to-use MCP servers. Let's choose one of their remote servers that is ready to consume. https://github.com/awslabs/mcp/tree/main/src/aws-knowledge-mcp-server is a good example.

Add the MCP library via uv add mcp, and let's update the code to include an MCP server:

from strands import Agent
from strands_tools.browser import AgentCoreBrowser
from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp.mcp_client import MCPClient

aws_knowledge_mcp = MCPClient(
    lambda: streamablehttp_client("https://knowledge-mcp.global.api.aws")
)
browser_tool = AgentCoreBrowser(region="eu-west-1")

with aws_knowledge_mcp:
    # Get the tools available from the MCP server
    aws_knowledge_tools = aws_knowledge_mcp.list_tools_sync()
    # Combine the browser tool with the MCP tools
    tools = [browser_tool.browser] + aws_knowledge_tools

    agent = Agent(tools=tools)
    agent("What tools do you have available?")

After running the agent again, you can now see that we have enabled more tools for the agent, which will give it the ability to answer more questions or perform more of the tasks you want it to be able to do.

We now have an agent who can both search the internet and use MCP servers using Strands. In many ways, it is this simple to create the backend for your own ChatGPT clone. It's becoming very trivial to enable this type of functionality based on an LLM.

But how can I share this with my colleagues and friends? Let's move on to deploying this.

Deployment

At this point, we have a working agent that runs locally. You could stop here and integrate this agent directly into your existing applications—just instantiate it in your API endpoints, Lambda functions, or any other service where you need AI-powered automation

But since we are exploring AWS Bedrock AgentCore, let's check out their runtime, which is a way to enable you to run your agent very quickly on AWS.

We'll follow their SDK guide, which makes this very quick and easy: https://strandsagents.com/latest/documentation/docs/user-guide/deploy/deploy_to_bedrock_agentcore/#option-a-sdk-integration

Amazon Bedrock AgentCore SDK

Start by adding the SDK library uv add bedrock-agentcore and let's update the code based on their example:

from strands import Agent
from strands_tools.browser import AgentCoreBrowser
from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp.mcp_client import MCPClient
from bedrock_agentcore import BedrockAgentCoreApp

app = BedrockAgentCoreApp()
aws_knowledge_mcp = MCPClient(
    lambda: streamablehttp_client("https://knowledge-mcp.global.api.aws")
)

browser_tool = AgentCoreBrowser(region="eu-west-1")

# Create which function acts as the entrypoint for the agent
@app.entrypoint
async def agent_invocation(payload):
    """Handler for agent invocation"""

    user_message = payload.get(
        "prompt", "No prompt found in input, please guide customer to create a JSON payload with prompt key",
    )
    # Create an agent with MCP tools
    with aws_knowledge_mcp:
        # Get the tools from the MCP server
        aws_knowledge_tools = aws_knowledge_mcp.list_tools_sync()
        # Combine the browser tool with the MCP tools
        tools = [browser_tool.browser] + aws_knowledge_tools

        agent = Agent(tools=tools)
        stream = agent.stream_async(user_message)
        async for event in stream:
            print(event)
            yield (event)

if __name__ == "__main__":
    app.run()

You can now run this locally with uv run main.py, which will start a web server that hosts the agent behind an endpoint. When it's running, you can test it via, for example, curl using the default endpoints exposed by AgentCore.

curl -X POST http://localhost:8080/invocations \
-H "Content-Type: application/json" \
-d '{"prompt": "Hello world!"}'

Since we opted to use the streaming response pattern, this would be a useful way of making it feel alive when, for example, building a chat interface.

Prepare for Deployment

The AgentCore SDK comes with a CLI for easy deployment and testing without the need to configure any infrastructure.

Run: uv run agentcore configure --entrypoint main.py, which will run you through a few steps to create a .bedrock_agentcore.yaml document that includes the details related to your deployment.

To try out the agent via AgentCore locally, you can then run uv run agentcore launch --local. This will build the Docker image that will be used when deployed and make sure everything is working as expected. Once again, use curl to invoke localhost to try out the endpoints—but this time via the Docker container which will be used for the actual deployment.

Let's Deploy It

When you are ready to actually deploy this to AWS, just run uv run agentcore launch. Given the specifications in .bedrock_agentcore.yaml, it will now deploy the required roles, push the Dockerfile to AWS, and make the instance available to be invoked from the AWS ecosystem.

Deploying Updates: Added a new tool or updated your agent logic? Just run uv run agentcore launch again. The CLI handles the rebuild, pushes the new container image, and updates your deployed agent—no manual infrastructure changes needed. Your agent ARN stays the same, so any existing integrations continue working seamlessly.

You can find the full code at: https://github.com/elva-labs/strands-agentcore-blog-example

But How Do I Actually Use It?

If you are familiar with the AWS ecosystem, especially services such as AWS Lambda, a deployed agent works very much the same way. Meaning that you can, via the regular AWS SDK, invoke the agent and use the response in any manner you see fit. Check out https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-invoke-agent.html for details related to this.

Here is an example of how you could invoke your deployed agent using the boto3 framework:

import boto3
import json

# Initialize the Bedrock AgentCore client
agent_core_client = boto3.client('bedrock-agentcore')

# Prepare the payload
payload = json.dumps({"prompt": prompt}).encode()

# Invoke the agent
response = agent_core_client.invoke_agent_runtime(
    agentRuntimeArn=agent_arn,
    runtimeSessionId=session_id,
    payload=payload
)

# Process and print the response
if "text/event-stream" in response.get("contentType", ""):
    # Handle streaming response
    content = []
    for line in response["response"].iter_lines(chunk_size=10):
        if line:
            line = line.decode("utf-8")
            if line.startswith("data: "):
                line = line[6:]
                print(line)
                content.append(line)
    print("\nComplete response:", "\n".join(content))

elif response.get("contentType") == "application/json":
    # Handle standard JSON response
    content = []
    for chunk in response.get("response", []):
        content.append(chunk.decode('utf-8'))
    print(json.loads(''.join(content)))

else:
    # Print raw response for other content types
    print(response)

Final Thoughts

AWS has, in my opinion, made the correct strategic move here toward a fully open-source agent framework that is very quick to get started with and has out-of-the-box support for the AgentCore runtime.

It also seems like AWS Bedrock AgentCore is their best bet for simpler ways of deploying infrastructure compared to the rest of AWS. As an experienced power user of AWS, I'm very comfortable with their ecosystem, as it enables me to use advanced patterns to solve almost any issue at any scale. But for many people entering the AI scene, much of this is unknown territory. By just having a simple CLI and a few commands to get running, they're actually becoming a challenger in the consumer space when it comes to agents, since the steep learning curve AWS traditionally comes with won't really work for this new wave of users.

Overall, I think the combination of AgentCore and Strands is a really nice concept that's getting close to becoming something I'd personally actually use in production. It still lacks some developer experience compared to more popular and larger frameworks, and is still a bit clunky in how you integrate it with your services. The AWS-specific flavor makes it a bit harder to integrate out of the box with, for example, the AI SDK, which powers a lot of chat frontends today.

All that said, I'm very excited by this step and looking forward to following the progress AWS will be making in this space over the next year.

What's Next?

Ready to take this further? Here are some next steps:

Explore More MCP Servers:

• Check out the MCP Server Registry for community tools

• AWS Labs has several production-ready servers for different AWS services at awslabs/mcp

Production Considerations:

• Set up CloudWatch monitoring for your deployed agent via AgentCore Observability

• Review the AgentCore security best practices

• Remember: AgentCore pricing is consumption-based, so you only pay for what you use

What's the one repetitive task in your workflow you'd automate first with an agent? I'd love to hear what you're building!

If you enjoyed this post, want to know more about me, working at Elva, or just want to reach out, you can find me on LinkedIn.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future.

Note: This document will evolve as AWS releases new services and I discover more effective ways to explain (and utilize) the existing ones.

Generative AI

Bedrock - Your "Just Make It Work" Solution

Remember when deploying ML models meant provisioning infrastructure, managing versions, and dedicating your weekends and paying tribute to <insert-divinity>, who might grant you success? Bedrock is the opposite of that. It provides plug-and-play access to foundation models via the SDK. Think of it as the AWS-ification of AI; they handle the hard parts, you handle the business logic.

The stuff you actually care about

Bedrock AgentCore - Managing AI agents at enterprise scale without losing your mind. Covers most use cases, handles security, and won't wake you up at 03:00 due to deployment-related issues. If you're running AI for a big organization, this is your toolkit.

Bedrock Guardrails - Use this when "move fast and break things" doesn't work and when your AI is customer-facing. This is your safety net for content moderation. Nobody wants their chatbot to become a PR disaster on a Friday afternoon.

Cross-region inference - Routes requests based on current load. It's like having an intelligent load balancer that actually understands your models aren't just stateless functions. Your models become truly plug-and-play across regions. You can use this service when you want AI capabilities without needing to become an ML infrastructure expert, which is, let's be honest, most of the time.

Machine Learning

SageMaker - The Swiss Army Knife

SageMaker is the answer to "what if we made machine learning... manageable?" It's comprehensive, fully managed, and eliminates most of the operational headaches.

The usual workflow:

Build - Spin up a Jupyter notebook, load your data, and start experimenting. You know, the fun part.

Train - Run training jobs with built-in algorithms or your custom code. SageMaker handles infrastructure scaling, so you can focus on whether your model actually works.

Deploy - Push your model live with no adjustments required. Integration with the rest of AWS happens when you're ready, not when AWS decides it's time.

Use it when Bedrock's pre-trained models aren't enough and you need something tailored. It's more effort, but you get precisely what you want.

Computer Vision & Language

The "AI But Make It Useful" Services

AWS offers a suite of services that are basically "we trained the models so you don't have to." They're surprisingly good, and you can implement them without a PhD.

The lineup

Rekognition - Deep learning for images and video. Detects faces, objects, text, and that weird thing in the corner of your security footage. It just works, and you don't need to understand convolutional neural networks to use it.

Textract - OCR on steroids. Pulls text, handwriting, layout elements, and structured data from documents. Goes way beyond "here's some text" into "here's the actual data you wanted."

Transcribe - Speech-to-text that handles 100+ languages and both real-time streaming and batch processing. Great for when you have audio and need text, without manually setting up inference pipelines.

Comprehend - NLP service that finds entities, key phrases, language, sentiment, and other insights in text. Uses ML to understand documents so you don't have to write regex for the 47th time.

Translate - Real-time translation using deep learning. Fast, affordable, and customizable. Beats the old "translate via Google Sheets" workaround most teams start with.

Polly - Text-to-speech with actual personality. Uses deep learning to sound less robotic and more human. Perfect for accessibility features or voice interfaces that don't make users want to throw their devices.

Use one or more of these tools when you have a specific, well-defined problem (transcribe this, translate that, find entities in documents) and don't want to become a specialist in that domain.

BI & Recommendations

Personalize - Netflix-Style Recommendations

Helps you build custom recommendation engines with real-time personalization and user segmentation. It's the same technology that powers the "customers who bought this also bought..." feature everywhere on the internet. Getting recommendations right is more challenging than it appears. Personalize handles the ML complexity so you can focus on the business logic of what to recommend.

Forecast - Time-Series Predictions

Statistical and ML algorithms for forecasting. Built on the same tech Amazon uses internally for demand prediction, which means it's battle-tested at scale. Use this when you need to predict future values based on historical data and don't want to spend hours developing a forecasting model.

Kendra - Enterprise Search That Doesn't Suck

Intelligent search using NLP and ML to help people find content across your organization's repositories. Think Google, but for your internal systems. Keeps employees from spending half their day searching for documents. Kendra searches actually work using natural language instead of boolean operators nobody remembers.

Model Context Protocol (MCP)

The Integration Layer You Didn't Know You Needed

What is MCP?

MCP is the connective tissue between your LLM and your actual data. It lets AI access external data and trigger actions. AWS has built several MCP servers that provide deep access to AWS APIs, enabling natural language input and outputting AWS actions.

Why this matters: Most AI implementations fail not because the models are bad, but because they can't access the correct data. MCP solves the "last mile" problem of AI integration.

Useful MCP Servers

If you're working with AWS, these MCPs are worth exploring. At a minimum, check out the repo https://awslabs.github.io/mcp/.

Documentation MCP - Real-time access to official AWS docs, API references, What's New posts, Getting Started guides, Builder Library, blog posts, and architectural references. No more having 30+ tabs open.

Infrastructure & Deployment - Build, deploy, and manage cloud infrastructure through conversation instead of clicking through consoles.

AI & Machine Learning - Enhance AI applications with knowledge retrieval and ML capabilities. No custom integration code required.

Data & Analytics - Work with databases, caching systems, and data processing through natural interfaces.

MCP servers turn your systems from "things you have to learn" into "things you can just ask." That's a big win.

The Strategy View

The AWS catalog is overwhelming (probably by design). AWS builds tools for every use case, which means you need to know which tool fits the problem you’re trying to solve.

The decision tree:

• Need AI capabilities fast with minimal setup? → Bedrock

• Need custom models for specific problems? → SageMaker

• Have a well-defined AI task (transcribe, translate, etc.)? → Specialized services (Rekognition, Textract, etc.)

• Do you need to connect AI to your existing systems? → MCP

Ready to Transform Your AI Infrastructure?

At Elva, we help organizations move past AI PoC and MVP theater. Our team's expertise with the Model Context Protocol and AWS lets companies:

• Implement robust infrastructure for integrating Generative AI.

• Transform legacy systems into AI-accessible resources without costly replacements.

• Build once, deploy AI everywhere across your entire ecosystem.

Make your business easy to talk to. Contact Elva to implement MCP and gain a competitive edge.

LinkedIn / Hashnode / Contact

Note: This document will evolve as AWS releases new services and I discover more effective ways to explain (and utilize) the existing ones.

From Human Loop to AI Loop

You know this dance: You need to schedule a meeting with your team to discuss the Q1 roadmap.

Today's reality

1. Check your calendar for free slots

2. Message teammates: "When are you free next week?"

3. Wait for responses (refresh Slack obsessively)

4. Cross-reference everyone's availability

5. Find a room that's actually free

6. Send calendar invites

7. Realize someone can't make it

8. Start over

Time: Anywhere from 20 minutes to 3 days, depending on how responsive your team is.

What's coming

"Book a meeting with the team early next week when everyone's available."

Done. The agent checks calendars, finds the overlap, books the room, and sends invites. Time: 10 seconds.

The difference? You're not the one doing the loop anymore. The AI is.

What Is an Agent, Actually?

When an agent tackles a task, it's running what's called an agentic loop. Don't let the jargon fool you - it's straightforward:

Step 1: Reasoning. The agent breaks down what you asked for. "To find backend development experts, I need to search employee profiles and recent project work."

Step 2: Action. It uses tools to get information. Query the employee database, check project repositories, and scan Slack channels.

Step 3: Observation. It looks at what came back. "I found 12 people with backend development listed as a skill."

Step 4: Validation. It checks if that's enough. "Did I answer the question completely? Do I need API design experience, too?"

Step 5: Loop or Finish. If done, return results. If not, go back to Step 1 with new information.

A Regular LLM gives you a single answer and stops, while an agent keeps going until the job is actually finished.

When an agent tackles a task, it's running through this cycle over and over. The agent reasons about what to do next, takes an action using available tools, observes what came back, validates if it's done, and either finishes or loops again. This is why dedicated agents feel different - they're built to run longer, more complex tasks without giving up. While tools like ChatGPT and Claude are becoming increasingly agentic with their own tool use, purpose-built agents can handle workflows that span minutes or hours, not just seconds.

This is the first time LLMs can "do" instead of just "say." And yeah, that's a big deal.

Why This Changes Everything

So why does this simple loop pattern matter so much?

Here's what makes agents different: they can use tools and MCP servers to actually do things. (Want the full story on context and MCP? Check out Moving Past the AI Hype and Solving Context with MCP Servers.)

The short version: agents don't wait for you to gather information. They access it themselves, remember what they've done, and keep working until the task is complete.

Monday morning: "What meetings do I have this week and what prep do I need for each?" The agent checks your calendar, pulls relevant documents, summarizes action items from previous meetings, and gives you a briefing.

Strategic reporting: "Create a report comparing our cloud costs versus our main competitor's public pricing." The agent pulls your AWS billing data, researches competitor pricing, analyzes the differences, and generates a formatted report with recommendations.

Feature development: "Add dark mode to our dashboard using the latest React patterns." The agent reviews your current codebase, checks React 19 documentation, implements the feature following your project's conventions, and opens a PR with tests.

You're not just saving time. You're eliminating entire categories of work that used to require a human to be the glue between systems.

What's Available Right Now

Here's what the landscape looks like today:

You're Already Using Agents (Probably)

• ChatGPT with plugins? That's an agent.

• Claude with MCP servers? Agent.

• GitHub Copilot? Specialized agent for code.

They're purpose-built for specific tasks, but they're all running the same basic pattern.

Agents are popping up everywhere today, and it’s only the beginning. I really think we are heading into a new technical era where agents will replace much of our daily work, especially the repetitive, slow-going work that many of us spend hours daily doing at our desk jobs. Is it only the carpenters and plumbers who have safe jobs for now?

Make sure to take the opportunity to stay ahead of the curve and utilize the advantage agents currently give you, parallelize yourself, and create leverage in your knowledge by automating the skills and knowledge that make you valuable within your job.

Ready to Build Your Own?

No-Code Agent Builders. If you're not a coder, platforms like n8n let you build agents visually. Connect your tools, define workflows, and let the agent handle the execution. It's surprisingly powerful for common business processes and has become one of the most popular low-code frameworks for agentic AI work.

Developer Frameworks: If you write code, things get interesting fast. Frameworks like VoltAgent (my personal favorite) let you build custom agents in minutes, not days. AWS is also pushing hard here with Agent Core Runtime and their Strands Python framework.

Building agents is a deep topic that deserves its own article - we'll cover that in detail soon.

The community is moving fast. What used to require a team of ML engineers now takes a developer an afternoon.

Need help getting started? At Elva, we help teams design and build custom agents that fit their specific workflows. Whether you're looking to automate internal processes or build customer-facing AI products, we'd love to chat about your use case.

For you developers out there, check out this repo with a quick, simple agent starter using VoltAgent, ready to be deployed as an API on AWS using SST: https://github.com/elva-labs/voltagent-blog-start

The Shift Is Here

I truly believe that things are changing, and they are changing fast. We're not talking about a gradual evolution - we're looking at a fundamental shift in how technology works.

Within a few years, the idea of manually moving data between systems will feel as outdated as using a fax machine. Specialized autonomous agents will handle the tedious work: booking meetings, comparing quotas against contracts, generating reports, monitoring systems, and flagging anomalies.

This is what makes the current state of LLM technology fundamentally different from previous AI hypes. We're not just getting better predictions or recommendations. We're creating software that can reason about tasks, use tools autonomously, and persist until the job is done.

The robots aren't coming for your job in the dramatic sci-fi sense. But the boring parts? The context-switching, the data gathering, the "glue work" that takes up half your day? Yeah, those are getting automated. Fast.

The question isn't whether this will happen. It's whether you're going to be building these agents or just watching while others do.

Time to start experimenting.

If you enjoyed this post, want to know more about me, working at Elva, or just want to reach out, you can find me on LinkedIn.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

If you have not read our first article in this series, check out: https://blog.elva-group.com/moving-past-the-ai-hype-introducing-mcp

The Copy-Paste Marathon We All Know

Picture this: You need to know who in your 500-person company has experience with Kubernetes and AWS.

Old way: Open HR system, export to Excel, search LinkedIn, check Slack, compile a list, hope it's current. Time: 45 minutes.

New way: "Who in our company knows Kubernetes and has AWS experience?" Time: 5 seconds.

The difference? MCP servers - and here's exactly how to use them.

Context Is Everything: Why Your AI Needs Direct Access

Here's the fundamental problem with AI today: it only knows what you tell it. Every conversation starts from zero. You're the human middleware, copying and pasting context that should already be obvious.

Everything about working with LLMs is moving toward what's becoming known as context engineering. Prepare the context for the question being asked, regardless of whether this is to produce an answer about personnel, create code, or write you an article about your favorite animal.

MCP (Model Context Protocol) servers solve this by creating secure bridges between AI agents and your actual tools. Your AI can directly:

• Query your employee database

• Check project documentation

• Pull analytics from your dashboards

• Search through your knowledge base

• Access your CRM data

• Read from your project management tools

Technically, MCP servers are JSON-RPC servers that expose your internal tools as functions AI agents can call. They provide a standardized way for AI to interact with any data source or API you want to expose - with built-in discovery, typing, and documentation. Once you connect a tool via MCP, any AI agent that supports the protocol can use it.

When AI already knows your employee skills, project history, and team structures, you can skip the copy-paste marathon and just ask: "Who should I talk to about Python performance issues in our data platform?" - turning hours of context-gathering into seconds of conversation.

Local vs Remote MCP Servers: Choose Your Approach

Before diving into setup, it's important to understand the two types of MCP servers:

Local MCP Servers:

• Execute directly on your machine as a process

• Use stdio (standard input/output) for communication

• Direct access to your local files and databases

• Data never leaves your machine

• Example: Node.js script accessing your local SQLite database

Remote MCP Servers:

• Run on external infrastructure (cloud servers, managed services)

• Communicate over HTTP/HTTPS protocols

• No local execution needed - just network access

• Maintained and scaled by the provider

• Example: AWS Knowledge Server running on AWS infrastructure

We're seeing a clear shift toward remote MCP servers, and for good reason. While today most people start with local servers running on their machines, the future is organizations hosting their own internal libraries of MCP servers - accessible to all employees but secured within company boundaries.

Imagine your company's private MCP ecosystem: HR data servers, documentation servers, analytics servers - all running in your cloud, accessible to your AI agents. Employees connect their AI tools to these internal servers, just as they do with the AWS Knowledge Server today.

So, How Do I Start Using This?

Let's get practical with a real example. AWS Labs provides a remote MCP server that gives AI agents direct access to AWS documentation, API references, and best practices. Perfect for our AWS-focused teams. For these examples, we'll be using the desktop client from Anthropic, Claude Desktop.

Step 1: Install Claude Desktop

Download Claude Desktop - it's Anthropic's native app with built-in MCP support. Other clients like Cursor work too, but we'll use Claude Desktop for this example.

Step 2: Configure the AWS Knowledge MCP Server

To add a remote server in Claude Desktop, they have a concept called Connectors. Go to Settings > Connectors and Add custom connector.

Enter the URL to the MCP server as defined at https://awslabs.github.io/mcp/servers/aws-knowledge-mcp-server: https://knowledge-mcp.global.api.aws

Step 3: Try it out

After restarting, try asking AWS-specific questions:

• "What's the best practice for setting up multi-account AWS organizations?"

• "Show me how to configure S3 bucket policies for cross-account access."

Now the magic happens. When your AI identifies a question where it could benefit from using an MCP server to get you a better answer, it will use the MCP server, query it for more information based on what you asked, and then return an answer.

This approach gives you an enhanced answer that includes up-to-date and question-specific data.

If you're a developer like many of us are, creating your MCP server is very simple. We've created a sample repo with a local test MCP that you can get started with to build your own server on our GitHub. Check out the repo at: https://github.com/elva-labs/mcp-blog-demo

Ready to Enrich Your AI Workflows With Your Own Data?

Whether you're looking to connect your internal databases, documentation systems, or analytics platforms, the path forward is clear: give your AI the context it needs to actually help you.

Need help implementing MCP servers in your organization or want to discuss your use case? Don't hesitate to reach out - we're helping teams navigate this transition every day and would love to hear about your challenges.

If you enjoyed this post, want to know more about me, working at Elva, or just want to reach out, you can find me on LinkedIn.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

With Generative AI dominating headlines, it's easy to feel overwhelmed by bold claims of job replacement and rapid change. I understand this uncertainty because I share it. While you hear projections about programmers being replaced by AI in a matter of months, the real story is that our profession is changing, and what that means for you right now. In this post, I’ll share insights and actionable steps to leverage and adapt to the technologies shaping our future.

Follow us on LinkedIn / Hashnode / Contact.

We’re launching a new series on AI & MCPs, exploring how you can adapt to stay ahead of your competitors and unlock new experiences for your customers. In the coming weeks, we’ll introduce practical examples on how to create and use both AI and MCP in the AWS cloud.

The Expensive AI Experiment

Today's hype in AI investment mirrors the early days of the internet, where substantial spending often lacked focus on tangible outcomes. Senior leadership is increasingly demanding a direct connection between AI initiatives and strategic deliverables, without a clear and/or reasonable goal.

A study conducted at MIT found that only 5% of AI pilots significantly boost revenue, with most showing little to no effect on profits. Similarly, McKinsey reports that over 80% of companies see no clear impact on earnings from generative AI. It may be time to acknowledge the red flags.

From our experience, these failures often occur because teams and projects are siloed, in addition to a failing integration strategy. Running a few proof-of-concept projects in isolation will increase costs across the company. Isolated solutions can't share information or build the operational context an AI requires, so they end up providing little value to you or your customers.

Enterprise systems hold decades of refined business logic, data, and tested processes. Your ERP system covers supply chain complexity and your CRM knows your customers. Companies have invested a significant amount of effort into these systems and now rely on them to maintain their competitive edge. The problem is that these essential systems were not designed for natural conversation. They require strict commands instead of everyday language.

In effect, the systems with the most valuable business information are the most challenging for AI to access. Companies face a choice: either build costly middleware for each new integration, or limit AI to new, context-free applications. The second option often results in weak AI projects that people are reluctant to use.

The Overlooked Infrastructure Crisis

Despite the excitement and investment, most AI pilot programs fail to produce lasting results. Gartner says nearly a third of generative AI projects are quickly abandoned. The reason is not that models are too complex, but that they aren't integrated into the core business systems.

These challenges demonstrate that the real obstacle to successful AI is not the complexity of the models, but rather the lack of integration with the core business. The Model Context Protocol, or MCP, addresses this by embedding AI directly into existing business systems. It offers a standard way to connect everything, making integration easier and helping AI deliver real, lasting value.

Instead of treating AI as something extra, companies need to focus on integration as the main challenge. By building infrastructure that makes AI easy to use as a core business tool, not just in isolated pilot projects, organizations can unlock long-term value.

The Missing Infrastructure Layer Most Overlooks (Model Context Protocol )

MCP serves as the crucial link between AI and business software, resolving longstanding integration challenges. Standardization allows access across diverse systems while maintaining security. This makes conversational AI broadly usable and enables seamless integration with both legacy and modern core systems.

Many people focus on bigger AI models, but the real benefit comes from better integration. The Model Context Protocol offers three main advantages. Firstly, it securely connects AI to business systems at scale, thereby reducing the need for custom integration. Next, it enables AI to access essential business data using standardized methods. Finally, you can update or swap the AI model without modifying MCP or the API, ensuring your setup is future-ready.

Nobody Wants to Learn Your Software

Most people don't want to spend their time clicking through menus or filling out forms. Asana reports that employees spend a lot of time on repetitive administrative tasks. These hours could be used to solve real problems.

Most daily tasks are straightforward, such as finding a number, checking a status, or approving a request. Instead of working through complicated software, it would be easier to ask for what you need. With AI powered by MCP and in turn your core systems, routine work can be handled automatically, allowing people to focus on what matters most.

However, this doesn’t just apply to simple tasks. Imagine handling expense approvals, budget plans, or performance reviews through simple discussion. AI can orchestrate the details and keep everything on track, letting you focus on the big picture.

MCP enables the use of a single, simple conversational interface, such as chat or voice, for all your systems. This enhances customer experiences and facilitates the development of new business solutions. Integration becomes easier, and once you have MCP in place, any AI can connect. This 'build once, use everywhere' method reduces costs and complexity, making it affordable to grow your use of AI.

The Window for a Head Start is Closing

Currently, the adoption of AI shares many similarities with the dawn of the internet. At that time, companies that built strong online systems stood out and stayed ahead for years. Today, there is a similar chance to be among the first to create an AI infrastructure. Companies that move quickly will be ready for future advances in AI, while others may find it hard to keep up or fall short.

As more companies realize the value of easier integration and AI, MCP is becoming the standard. Leaders need to decide whether to continue spending on expensive, isolated AI projects or to invest in infrastructure that enables AI to deliver value at scale.

Choosing the proper infrastructure is almost always more cost-effective and impactful over time than funding scattered initiatives. Additionally, AI will only succeed if it is fully integrated into the core business infrastructure. Companies that make this integration a priority, rather than treating AI as an add-on, will move ahead of their competitors as conversation-based systems become the norm.

The era of AI pilot projects and struggling AI startups is coming to an end. Now is the time to invest in robust AI infrastructure and prepare your business for the next decade.

Ready to Transform Your AI Infrastructure?

At Elva, we help organizations move past AI PoC and MVP. Our team’s expertise with the Model Context Protocol and AWS allows companies to:

• Implement a robust infrastructure that is suitable for integrating Generative AI.

• Transform legacy systems into AI-accessible resources without costly replacements.

• Build once, deploy AI everywhere across your entire ecosystem.

Make your business easy to talk to. Contact Elva now to implement MCP and gain a competitive edge.

LinkedIn / Hashnode / Contact

People argue about cold starts, vendor lock-in, or learning curves, and while they are valid concerns, I believe that the benefits of serverless far outweigh the drawbacks - especially when you consider the total cost of ownership over the lifetime of a project. But I'm not here to argue about these concerns today, I'm here to talk about something else.

Luc van Donkersgoed covers some of these concerns and others in my favorite blog post of all time here. Go ahead and read it but pinky promise you'll come back!

Today I want to talk about an aspect of serverless that I think is often overlooked: the developer experience and the unexpected use cases of "boring" technology that emerge when it's exposed in the form of a radically simple to consume and configure managed service.

Your personal production environment

Do you know how many lines of code or clicks in the console you need to set up a DynamoDB table? An S3 Bucket? A Lambda function?

The answer is about 2.

This sets up a service that will scale to virtually any load, without further configuration. Perhaps more importantly though, it also scales to 0, and you literally pay nothing when it's not being used.

People tend to focus on the scaling up part, not realizing what the scaling down part actually entails. It's not just about saving money, it's about the freedom to experiment and build things in a way that you wouldn't have otherwise.

Want to have a personal carbon-copy production environment? Sure, hit deploy and have it ready in 30 seconds and it will always be free.

When you merge code to main, you can be absolutely certain that it will work exactly the same in production as it did during development, because you've been testing in "production" all along.

Want to spin up an ephemeral environment on every pull request, run integration tests against it, and tear it down when the pull request is merged? Sure, it's literally a few lines of code and it will cost you nothing.

And once these resources are deployed, you will never have to worry about them again. They will scale up and down to meet demand, there is nothing to patch or maintain, and the availability and security of the services will be the responsibility of one of the most experienced and capable companies in running cloud infrastructure in the world - so that you can spend your time where it actually sets you apart.

Gone are the days of sharing a database in the development environments to keep cost down. Gone are the days tinkering with scaling groups and load balancers. Gone are the days of waking up in the middle of the night to patch a vulnerability.

When the log4net vulnerability was announced, I was working in the platform services team at a major automotive company running hundreds of workloads in AWS. Do you know what we did to patch it? Not a damn thing.

The same company at one point ran a superbowl ad and traffic was naturally expected to explode. Do you know what we did to prepare for it? Not a damn thing - we sat back to enjoy the show.

The idea that serverless compute is more expensive than traditional alternatives is less and less true the more you look at the full picture and lifecycle of your applications. Is there a break-even point where it becomes more cost-efficient to move away from it? Sure. But I'd argue that that point is way (way) higher than you'd think if you consider the total cost of ownership. That is, not only the compute layer itself, but also:

• development environments and feedback loops

• labor cost of maintenance, configuration management

• overprovisioning to meet demand, or underprovisioning and risking business objectives, and the labor of finding the right balance

• the opportunity cost of not spending time on what actually matters to the business

This isn't meant to be a blanket statement claiming that serverless is always cheaper. But it is cheaper in more cases than you might think at first glance. It's also not a binary choice. Employing a serverless-first strategy is wise, where you default to “more serverless” and move further back in the abstraction spectrum as needed, with parts of your application (or application landscape) being serverful where it's more fitting.

Unexpected Use Cases from Radically Simple Services

Traditionally, setting up a globally distributed, highly available database required intricate configurations: manual sharding, complex replication setups, and constant vigilance to maintain consistency across regions. This complexity often deterred teams from pursuing global distribution, limiting application performance and resilience.​

Enter services like DSQL and DynamoDB Global Tables. With the latter as an example, you can select the regions where you need your data replicated, and DynamoDB handles the rest, eliminating the complexity and operational burden of deploying and managing multi-region replication. This means that updates performed on a replica table in one region are automatically replicated to the replica tables in other regions, ensuring low-latency access for users worldwide. By abstracting away traditional pain points, fully managed services make many problems that were previously very hard and costly to solve completely disappear.

And this pattern repeats itself across many other services and problem domains. Whether it's APIs with API Gateway, Cron jobs and scheduled tasks with EventBridge or workflow orchestration with StepFunctions - what once required dedicated infrastructure, maintenance, and tuning is now an API call away.

When you have managed services that are so simple to consume and configure, you start to see unexpected use cases for technology that you wouldn't have considered before.

My friend and colleague Elias Brange has two perfect examples of this.

The first one is covered in his blog post "Test Event-Driven Architectures with EventBridge and AppSync Events" where he explores the idea of using AppSync Events (a managed Websockets API) to test event-driven architectures end-to-end. Spinning up a websockets API as part of your test suite and streaming events through it to test your system's behavior is a brilliant idea, and it's a fantastic solution to a problem that's hard to solve with traditional tools.

The other one is about spinning up a Wiremock service as a Lambda Layer to mock external services during early development or as part of integration tests without the need to change any application code.

While it's obviously not a new idea to mock external services, the simplicity of setting up a Wiremock service in a few lines of code, deploying it as a "sidecar" to your dev stack, and not having to pay a dime for it is, honestly, a game changer.

If you talk to developers who've been working with serverless for a while, you'll find that it's not uncommon for many of them to have tricks like this up their sleeve.

Conclusion

When you really start to lean into the serverless paradigm shift, you realize that perhaps the biggest benefit isn't just avoiding infrastructure management or infinite scalability. It's the ability to focus entirely on solving business problems instead of wrangling things that "should just work. It may even unlock new ways of thinking about how you can use technology to solve problems that you wouldn't have considered before, and in, dare I say, the vast majority of cases, it will be cheaper in the long run.

Hi there, I'm Sebastian Bille! If you enjoyed this post or just want a constant feed of memes, AWS & serverless talk, and the occasional new blog post, make sure to follow me on 𝕏 at @TastefulElk or on LinkedIn 👋

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

Act and react

I already wrote some words in my “first-year review” regarding the then ongoing recession. If we knew then what we know now, right?… This year we saw early signs at our clients as well as in the general public market that the uncertain situation in the world was taking its toll and that the situation would spiral further. Thanks to the senior experience within the group we acted quickly and precisely. Working actively with forecasting and keeping a tight feedback loop we managed to take actions, on a group level as well as an individual company level, cushioning the impact of inevitable customer cutbacks and losses. We developed a contingency plan identifying a list of actions to improve the outcome (on a monetary level). A list growing in severity and level of unpleasantness. The two most extreme being bringing on external capital and laying off colleagues. Our focus shifted from growth to profitability, cutting unnecessary costs and “nonprofit driving activities”. An important thing for us was to have full transparency and regular communication amongst each other. It wasn't fun, but everyone agreed on the precautions and understood the seriousness of the situation.

Looking back there were especially two months that I will remember. I will not remember them fondly mind you but I will take with me into the continued journey. During this period I experienced changes in my physical wellbeing. Most noticeable discomfort in the chest, trouble sleeping, and general fatigue. All this stemmed from the utter disgust I felt about even thinking of layoffs and knowing how we all suffered. Lingering in not knowing and to a large extent not having any power over the situation. Thankfully we managed to turn this around rather quickly and we could, with quite high certainty, say that we would close the year on black numbers. The relief was imminent.

Is it really worth it?

I’ve gotten the question “Is it really worth it?” a few times during the year. And not to take lightly on the health aspects of it all, but YES. It absolutely is worth it. I thoroughly enjoy my day-to-day work. I love my client. I love the interaction with brokers and colleagues, trying to achieve a common goal and doing it for myself, as well as for them. I’ve learned a lot during this year; regarding myself, my colleagues, and perhaps even more about running a business. I believe the people of Elva have become tighter with each other and more prepared than before. In the end, I’d say we are a better company and group for it. I don’t intend to rest on my laurels once things stabilise. I’ve come to terms with what bad stress is to me. When to avoid it and when to listen to my body. I’ve also come to appreciate and somewhat thrive during periods of high workload, making me feel appreciated and with a sense of accomplishment.

Yes, because:

In hindsight, we’ve accomplished quite a lot as a group.

• Grew in numbers despite an extremely tough market, and not only in our existing locations. We launched Malmö AND Stockholm.

• We lost two clients; but gained five.

• We finally got an AWS User Group and Community in Örebro.

• Won the various AWS prospecting competitions we set out to participate in

• We lost a year; but gained experience that will benefit us for years to come.

The first year was amazing. The second one not so much. I hope in year three we can at least find a middle ground and some stability. No doubt things are still tough; at least now we have built both resilience and processes to handle it.

If you enjoyed this post, want to know more about me, working at Elva or just want to reach out you can find me on LinkedIn.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

The idea

Just before I went to sleep last Sunday I thought it would be fun to create an app for my friends and I where we can rate the Eurovision Song Contest participants live together. The idea was to have everyones votes being tallied up live as we make adjustments to the ratings. This led me into looking at Replicache as the solution. I've been interested in trying it out for a while now and this was the perfect project for it. I quickly threw together a sketch on Excalidraw so I would have something to go on for tomorrow.

Building

As the Monday began I started reading documentation and looking into the tech I wanted to use. For most of the stack I went with things I know. But for the multiplayer part I had to read up and understand the core concepts behind Replicache. While reading I came across their hosted service Reflect. This was a perfect fit as time was of the essence and I would not have to build my own Replicache backend! It's completely free for 1000 user hours every month. As this project is supposed to be used during the 5 hours of Eurovision every year we can calculate the maximum amount of users we can have online for the full duration by simple division.

$$\frac{1000hu}{5h} = 200u$$

200 users? We're totally good.

Bootstrapping the project

For the project bootstrapping I chose to base my project on Reflect's own React template. This decision came from the idea that I wanted to play around with it a bit first and get a proper understanding of it before I try to implement my idea. While playing around with the template I made new mutators and subscribers and got a feeling of how the service works. Great start!

Skeleton structure

The next step was setting up basic React and HTML elements to be the skeleton of my idea. I got all the fields I wanted up and a general structure of the main feature. Key here is not to put too much time into styling. I mostly used the css styles already included in the scaffolded project and added just a little bit for the rounded borders and layout to be possible.

Implementing the main feature

Now with the basic ui elements in place we can start implementing the features we care about. For me it was getting live updates when someone changes a rating. At first I built it without taking into consideration what song was being rated just to get something up. and running. And when I got that working I updated the data structure to handle the mutations based on id's and boom the main part of the application was working! I could now switch between different songs and add individual ratings to them while also seeing the updates in real time from another browser!

Adding the other bare necessities

Now that the main feature had been implemented I had two things left to do in regards to the bare necessities. I wanted some sort of "login" page and a scoreboard.

"Login" page

The login page would serve as a way for the user to identify themselves with a name and then join a specific room ID. I purposefully made this super simple, letting users choose whatever room ID they want and Reflect would handle creating the room gracefully with the users not noticing anything at all. For another user to join the same room they simply had to type the same room ID. This is possible since Reflect is using CloudFlares Durable Objects in the background, serverlessly handling the client states for me and I don't have to be worried about any cost as I'm within the limits of Reflect's free plan.

Scoreboard

The scoreboard should show the aggregate total of all the scores from all the users, ranked after either order in the show or the max average. This could surely be built in a more sophisticated way with a table where you could sort based on any attribute but I kept it simple. I render the list based on how many contributions have been rated and calculate the average for each then sort it.

Styling

All the functionality I intended is in place now! Time to make it look at least a little better. As I am not the best css:er nor very imaginative I gave a lot of the stylistic choices to ChatGPT. In essence I gave it the layout of the page with the current styles I had in place and then asked it to "pimp my ride"-it in the style of Eurovision. Color wise that seems to mean "add gradients". This works well enough for me!

Deploying

I was happy with this! Everything seems to work well while developing and it seems ready enough. First I created a production environment for my Reflect service by running npx reflect publish --app lagom-euro and added the generated url to my .env. Then I ran sst init to add sst ion to the project. I added a StaticSite resource and ran a deployment to my prod AWS account. sst deploy --stage production. A production environment was now up and running!

Testing and fixing

The site was up and available via CloudFront. I started to show people and tested it with a few devices. Found some unintended behaviors and things that could be clarified. I added som help text and a button to show and hide the help.

Domain

Finally I bought a domain for it. I continue to name my projects after my favorite Swedish word "Lagom" which translates to "Just right". I attached the domain to my sst resource and boom the site was now available from lagomeurovision.com!

Observability

This is a bit late in the game I admit, but better late than never! I figured it could be cool to know how many visitors and rooms I have on this small little project. I went ahead and created an environment for this project on my Baselime account. Baselime is a serverless observability service, recently acquired by CloudFlare! I've used Baselime in a few of my smaller projects now and it's super nice to use. For this project I installed their React SDK and added a custom event that emits when a room is joined.

I then set up a dashboard where I'd have an overview of the page stats. During the night I had 8 unique rooms and people joined a room 29 times. Very reasonably the site was mostly used on phones with the iPhone hogging the spotlight at 21 counts and Android following on 9. Stats are cool.

Final take-aways

These are my personal key take-aways from this project:

• Bootstrap your project to get up and running quickly

  • In my case it meant using a Reflect scaffold to have the project structured from the start

• Read the documentation

  • It's way easier to build things if you understand how the technology works

• Start with the main feature

• Functionality first, style later

• Ask for help if you have a question or get stuck

  • I asked for help in both the Replicache Discord and Baselime Slack servers. In the Replicache server I got help from a community member. In the Baselime server I got help from one of the developers (Thanks Thomas!)

• Leverage ChatGPT for things you don't necessarily care for (my case, a lot of css)

• I like building for my friends

Thanks!

Thanks for taking the time to read or at least scroll through all of this. This post is both meant as an example of me eating my own dog food regarding my previous post but also as an exercise in writing. As a newer content creator/tech blogger/aws influencer I've yet to really find my voice. I think I enjoy this type of content quite a bit. I know I like reading about people's own little side projects or how someone built something very cool. If there is something you liked/disagreed/have a question about please write to me! A comment on the post or a direct message on LinkedIn or X are both welcome.

Here's the final site.

Here's the repo if you want to check it out.

If you enjoyed this post you could follow me on 𝕏 at @Paliago. I mostly engage with the serverless community and post pictures of my pets.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

Some background

I’ve seen some horrific examples of bad treatment when people have left a company. People have been met with the cold shoulder, not being welcomed at the office during the notice period, with their colleagues kept in the dark, and even a few that’s been threatened with legal actions. For completely no valid reasons other than trying to scare the person into acting differently. Imagine being such a daft and horrible person. I myself have been subject to a subtle but rather unpleasant threat, via email, of being sued when I left a previous work place. I took it for what it was, which was scare tactics that did not hold any ground (it was over a LinkedIn-post I’d shared and written expressing my excitement over Elva). What however hurt me and made me disappointed and mad was the things what was said behind my back once I had left. This after some 7 years together and me leaving to follow my dream to start a company. Not that well handled.

Some of my friends have faced far worse threats and treatments from their former employers. None of us would ever dream of working for that company again. I would go so far as to say we actively will advice people against working there. And (bad) word tend to spread like a wildfire. I'll be standing here with a bunch of marshmallows and a stick.

The conclusion

As mentioned in my previous blog post I’m not naive enough to think that no one will ever leave Elva. Hopefully it’s for a good and ”unavoidable” reason. Even more so we can hopefully find a way to work together within Elva Group, as we’ve actually intended it to be. If you have a great idea and like to try it out within the confines of a new company, Elva will back you up with resources and expertise. If not I’d like to be the first one to give you a hug and my sincerest good luck wishes. I’m not saying that you should hold a parade in the persons honor, or declare three days of company wide mourning, but you need to treat your soon to be former colleague with upmost respect and dignity. It’s seldom an easy decision to resign from a place you like. Leaving friends and memories. Leaving the comfort of the known. In realising that and remembering that this is a human being we’re talking about, what good does it do you to treat them like garbage? We have to believe that the good prevails. That being a bully only gets you so far. And rest assured. I will do everything I can to make it so.

If you enjoyed this post, want to know more about me, working at Elva or just want to reach out you can find me on LinkedIn.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

The error occurs because every deployment on a unique stage deploys an SST server response cache policy.

By default, the cache policy is configured to cache all responses from the server rendering Lambda based on the query-key only. If you're using cookie or header based authentication, you'll need to override the * cache policy to cache based on those values as well. - from the SST documentation

One of the possible remedies here is to create a shared cache policy for your main development and production environment. You'd then re-use the policy for your personal stages and PR-deployments. Let's look at how to set this up.

The Plan

You're going to need at least two stacks, one for your site and one for the policy. When deploying the main distribution for the stage (as in dev and not pr-1) we'd deploy the policy first together with the id of it as a value in SSM Parameter Store. We'd then fetch the id of the policy during deployment and use it for the CloudFront Distribution in the new stack. For every other stage in the account we'd only have to deploy our site stack. Let's look at some code.

Distribution Policy Stack

import {
  CachePolicy,
  CacheQueryStringBehavior,
} from "aws-cdk-lib/aws-cloudfront";
import { StringParameter } from "aws-cdk-lib/aws-ssm";
import { Duration } from "aws-cdk-lib/core";
import { StackContext } from "sst/constructs";

// the ssm param name we will share with the other stack
export const cacheParamName = "/cool-site/cache-policy-id";

export default function DistCachePolicy({ stack }: StackContext) {
  // the cache policy, configure it to your liking
  const serverCachePolicy = new CachePolicy(stack, "ServerCache", {
    queryStringBehavior: CacheQueryStringBehavior.all(),
    headerBehavior: CacheHeaderBehavior.none(),
    cookieBehavior: CacheCookieBehavior.none(),
    defaultTtl: Duration.days(0),
    maxTtl: Duration.days(365),
    minTtl: Duration.days(0),
  });

  // the ssm param
  new StringParameter(stack, "CachePolicyIdParameter", {
    parameterName: cacheParamName,
    stringValue: serverCachePolicy.cachePolicyId,
  });

  stack.addOutputs({
    CachePolicyId: serverCachePolicy.cachePolicyId,
    ParameterName: cacheParamName,
  });
}

Notice here how we set up the cache policy as well as a parameter. With the name of the parameter exported as a const. This constant will be imported and used in the Site stack.

Site Stack

The site stack fetches the id of the cache policy and uses that as the server cache policy when deploying the CloudFront Distribution.

import { CachePolicy } from "aws-cdk-lib/aws-cloudfront";
import { StringParameter } from "aws-cdk-lib/aws-ssm";
import { RemixSite, StackContext } from "sst/constructs";
// the cache param we exported in the dist stack
import { cacheParamName } from "./DistCachePolicy";

export default function Site({ stack }: StackContext) {
  // read the cache policy id from SSM
  const cachePolicyId = StringParameter.valueForStringParameter(
    stack,
    cacheParamName
  );

  const serverCachePolicy = CachePolicy.fromCachePolicyId(
    stack,
    "CachePolicy",
    cachePolicyId
  );

  // works with any high-level site construct which extends SsrSite
  const site = new RemixSite(stack, "site", {
    path: "./apps/web",
    cdk: {
      serverCachePolicy,
    },
  });

  stack.addOutputs({
    DocumentationSiteUrl: site.url,
  });
}

In this example I deploy a site based on the Remix SST construct but any high-level construct based on the SsrSite construct will work (Astro, Remix, Nextjs, SolidStart, SvelteKit).

The SST Config

We should also take a look at the sst.config.ts for how we then deploy these stacks.

import { SSTConfig } from "sst";
import Site from "./stacks/Site";
import DistCachePolicy from "./stacks/DistCachePolicy";

export default {
  config(_input) {
    return {
      name: "cool-site",
      region: "eu-north-1",
    };
  },
  stacks(app) {
    // only deploy cache policy in prod and dev, reuse them in PRs
    if (app.stage === "prod" || app.stage === "dev") {
      app.stack(DistCachePolicy);
    }
    app.stack(Site);
  },
} satisfies SSTConfig;

We set the DistCache stack within an if statement that checks if the stage is either dev or prod as those are the only stages we want to create policies for.

Deployment

To deploy and start using this shared cache we need to first deploy the dev stage.

sst deploy --stage dev

After that is ready we should be good to deploy our personal stage.

sst dev

Now we can deploy upward to a 100 individual distributions using this same cache policy. Hope this helped you out!

If you enjoyed this post you could follow me on 𝕏 at @Paliago. I mostly engage with the serverless community and post pictures of my pets.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

You could execute the entire state machine, observing side effects and final outcomes, but this approach often feels like using a sledgehammer for a task that needs a scalpel. It's effective for smaller workflows but quickly becomes unwieldy with more complex ones.

Unit testing Lambda functions or other compute components can cover the core logic of a task, but this doesn't cover data transformations or control flows between states.

Local emulation of StepFunctions is another approach but it often leads to IAM access inconsistencies and other headaches common with emulating cloud services.

While these methods are useful, they each come with drawbacks that risk that the beautiful state machine you wrote to handle that one complicated payment workflow becomes just another mess of logic that is hard to maintain or evolve. This is particularly ironic considering that many state machines are built explicitly to untangle complex logic.

Right before re:Invent 2023, however, AWS released a new capability to test individual states in a state machine.

This feature is available in the StepFunction console, but, more importantly, it also allows us to write isolated integration tests in code. These can test output, data transformations, and control flow for each individual state in our state machines - all without the hassle of trying to force the entire state machine to go down a particular route to validate the same thing.

Let's take a look at how we can use it.

Integration Tests

First, assume we have a small state machine that upgrades a user account, but only if they have enough credits to cover the cost.

Using the Node AWS SDK, there's a new TestStateCommand. This command takes:

• A task definition

• A task input payload

• An IAM role that the StepFunction service will assume to execute the state

It executes the state, and returns:

• The status of the execution - whether or not it errored, succeeded, or caught an error

• The output of the task

• The state that would be next in line

• Metadata about the execution

An example response could look like this:

{
  '$metadata': {
    httpStatusCode: 200,
    requestId: '2916bb74-418d-402b-a903-18c0a9c3e9c9',
    extendedRequestId: undefined,
    cfId: undefined,
    attempts: 1,
    totalRetryDelay: 0
  },
  nextState: 'Choice',
  output: '{"ExecutedVersion":"$LATEST","Payload":{"cost":75,"credits":100},"SdkHttpMetadata":{"AllHttpHeaders":{"X-Amz-Executed-Version":["$LATEST"],"x-amzn-Remapped-Content-Length":["0"],"Connection":["keep-alive"],"x-amzn-RequestId":["256f8768-f84e-46b0-ba79-b48dbfd250fa"],"Content-Length":["25"],"Date":["Wed, 06 Dec 2023 19:48:24 GMT"],"X-Amzn-Trace-Id":["root=1-6570d008-34fc67a96baf085e418d0745;sampled=1;lineage=055c6c5a:0"],"Content-Type":["application/json"]},"HttpHeaders":{"Connection":"keep-alive","Content-Length":"25","Content-Type":"application/json","Date":"Wed, 06 Dec 2023 19:48:24 GMT","X-Amz-Executed-Version":"$LATEST","x-amzn-Remapped-Content-Length":"0","x-amzn-RequestId":"256f8768-f84e-46b0-ba79-b48dbfd250fa","X-Amzn-Trace-Id":"root=1-6570d008-34fc67a96baf085e418d0745;sampled=1;lineage=055c6c5a:0"},"HttpStatusCode":200},"SdkResponseMetadata":{"RequestId":"256f8768-f84e-46b0-ba79-b48dbfd250fa"},"StatusCode":200}',
  status: 'SUCCEEDED'
}

Let's put together a couple of helper functions that can help us fetch a deployed state machine's definition, and one that executes a given state in the state machine definition.

// util.ts

import {
  DescribeStateMachineCommand,
  SFNClient,
  TestStateCommand,
} from '@aws-sdk/client-sfn';

const client = new SFNClient({});

interface TestStateInput {
  stateMachineDefinition: string;
  roleArn: string;
  taskName: string;
  input?: string;
}

export const fetchStateMachine = async (stateMachineArn: string) => {
  const stateMachine = await client.send(
    new DescribeStateMachineCommand({
      stateMachineArn: stateMachineArn,
    })
  );

  if (!stateMachine.definition) {
    throw new Error('State machine definition not found');
  }

  if (!stateMachine.roleArn) {
    throw new Error('State machine roleArn not found');
  }

  return {
    definition: stateMachine.definition,
    roleArn: stateMachine.roleArn,
  };
};

const getTask = (taskName: string, definition: string) => {
  // parse the definition and return the given state
  const task = JSON.parse(definition).States[taskName];
  if (!task) {
    throw new Error(`Task ${taskName} not found`);
  }

  return JSON.stringify(task);
};

export const testState = async ({
  roleArn,
  stateMachineDefinition,
  taskName,
  input,
}: TestStateInput) => {
  const task = getTask(taskName, stateMachineDefinition);

  return await client.send(
    new TestStateCommand({
      definition: task,
      roleArn: roleArn,
      input: input,
    })
  );
};

fetchStateMachine takes a state machine ARN and returns the deployed state machine's definition and the IAM role it's configured to use.

testState takes that definition, role, and the name of the state that we want to test. It executes the state using the StepFunction service, and it returns the execution information.

We can now use these to start writing our tests:

// account-upgrade.test.ts
import { describe, it, expect } from 'vitest';
import { fetchStateMachine, testState } from './util';

describe('[accountUpgrade]', async () => {
  const stateMachine = await fetchStateMachine(
    'arn:aws:states:us-east-1:123456789012:stateMachine:accountUpgrade'
  );

  describe('[CheckCreditBalance]', async () => {
    it('returns credit balance', async () => {
      const res = await testState({
        stateMachineDefinition: stateMachine.definition,
        roleArn: stateMachine.roleArn,
        taskName: 'CheckCreditBalance',
        input: JSON.stringify({
          cost: 75,
        }),
      });

      expect(res.status).toBe('SUCCEEDED');
      expect(res.nextState).toBe('Choice');

      const output = JSON.parse(res.output || '{}');
      expect(output.Payload).toEqual({
        balance: expect.any(Number),
        cost: 75,
      });
    });
  });

  describe('[Choice]', async () => {
    it('flows to account upgrade if credit balance more than cost', async () => {
      const res = await testState({
        stateMachineDefinition: stateMachine.definition,
        roleArn: stateMachine.roleArn,
        taskName: 'Choice',
        input: JSON.stringify({
          cost: 75,
          balance: 100,
        }),
      });

      expect(res.status).toBe('SUCCEEDED');
      expect(res.nextState).toBe('UpgradeAccount');
    });
  });
});

With this, we have everything we need to start to fully cover the full configuration and logic of our state machines.

For a more complete demo, which gives us type safety for the resource ARN and the state names, I've published a demo SST project here.

Additionally, Lars Jacobsson has added support to his samp-cli project for interactively running the individual state tests - it even lets you re-use recent live execution payloads. Incredible!

If you want to dig further into more strategies for testing StepFunctions, Yan Cui has some excellent writing on it here.

In conclusion, testing StepFunctions is hard, but it did just get a whole lot easier. As we've seen, the ability to test individual StepFunction states marks a leap forward in how we can build more robust and well-tested state machines. This feature isn't just a neat trick; it addresses some of the core frustrations we've faced in complex workflow orchestration. It doesn't replace end-to-end testing and unit testing of state machines, but it's a well-appreciated complement!

Hi there, I'm Sebastian Bille! If you enjoyed this post or just want a constant feed of memes, AWS & serverless talk, and the occasional new blog post, make sure to follow me on 𝕏 at @TastefulElk or on LinkedIn 👋

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

The beginning

To be honest I’ve always “dreamt” of starting my own company but never really had the guts or “the idea” or even the know-how. Or I might just have been too comfortable or lazy, I don’t know. All I know is that I didn't want to do it alone. When I was approached with the opportunity and idea of the company-soon-to-be-called-Elva, it felt like a no-brainer. The idea of Sagewei (now Elva Group) acting as a platform company for our company struck a chord with me. A platform company consisting of people with a proven track record. With a view on both hard and soft values aligning with mine taking responsibility for handling the legalities, HR, writing contracts, and teaching us the ins and outs of building a successful company. Enabling us to focus on what we do best: Making silly jokes at, and photoshops of, each other. And serverless stuff on AWS of course. The stars aligned and all that. We just needed to assemble the right people.

Building the brand

Before you officially can start there are a few things that are nice to have in place. For instance a company name. It’s quite central but perhaps not something that makes or breaks a company. For us though the name was something to be proud of and that we all could get behind. The naming process was quite extensive and tedious, perhaps because too many cooks spoil the broth or simply because it's very hard to come up with names for a company. Looking back some of the names were... equally brilliant and ridiculous. Imagine if we had settled for "Wolf Tech"… When the name Elva came to light I think we all sort of just knew, and the voting was unanimous. It checked all the boxes...

☑️ Short and concise
☑️ Nordic sounding
☑️ Works in English
☑️ ... not Wolf Tech

... but the main idea is that the Swedish word Elva translates to 'eleven' in English, which is the position of the letter λ (lambda) in the Greek alphabet. Our homage to the AWS service that started the serverless revolution.

From there designing the logo went fairly smoothly.

Every Elva company is designed with very low overhead (at the time of writing we are below 6%). This enables us to maintain high net margins of profit (goal is 30%) while at the same time offering competitive salaries and making investments for the future. To reach and ensure the sustainability of these numbers our strategy has been to make sure that each of us had assignments from day one. Each Elva office is by design its own company with its respective founders, budget and board, free to make our own decisions. What we do however share is the devotion and focus on AWS and serverless. Not only is this a decision based on the fact that serverless is a force to be reckoned with for the foreseeable future it also makes it easier to stay relevant and updated. Another thing we agreed upon early was our intent to build a strong relationship with AWS. We also wanted to contribute to the community and share whatever knowledge we have and acquire along the way.

The ups and downs

Every journey is bound to have its highs and lows. I'll try to list some of those who have impacted me the most and in some cases even the company.

The ups 🔝

Clyde

Many of us have had a long working relationship with a bunch of really great people from Cebu in the Philippines, who also happen to be super-talented developers. I contacted one of them on the off chance of him being interested in joining Elva. Lo and behold, he was very into the idea and decided to join us. I strongly believe in the concept of distributed teams and we will continue the search for talent, regardless of their physical whereabouts.

Advanced partner

If we want to become the leading AWS brand in the Nordics we also believe that we should have a strong partnership with AWS. Therefore we put a lot of time and effort into trying to reach Advanced Partner and did so in less than a year.

Prospecting league x2

We entered the AWS Partner Prospecting League for the Nordics on two occasions and managed to become opportunity count champions both those times. Let’s see if we can bag a third one.

Sandvik Startup Challenge

I didn’t participate or contribute to this but it was exciting to follow from the sidelines. I’m extremely proud of the effort and outcome that the team put together. To be selected as one of the few companies to compete in the final of the Sandvik Startup Challenge was a huge honour and accomplishment.

Kickoffs and get-togethers

We’ve had a few kickoffs and get-togethers. Serverless meetups and dinners. Conferences and after works. All of which left me with a smile on my face, a head full of ideas and insights and energy in abundance.

Recognition

Whenever you put in hard work, it's nice to get recognised. I'm trying to give credit where credit is due, hopefully inspiring others to do the same. That way we hopefully create an uplifting and positive work environment internally. When the recognition comes from outside it's sometimes even more encouraging. To hear what people are saying about Elva is truly inspiring and humbling.

Last but not least... the office

I almost forgot but we do, in my opinion, have a very nice office. It took quite some time to find the right spot and even more time to make it what it is today. But we are all very pleased with the way it turned out.

The downs 🪫

Recession

The ongoing recession is impacting large portions of the world's population as well as companies. This has made us rethink our strategy in a way, and perhaps slow down the growth rate of the company in terms of new colleagues.

Loss of assignments and lower fees

With recession comes hard times and with that, it’s not uncommon in our line of business to face lower fees and even loss of assignments. We are not exempt from this. It’s sad to have to leave a place that you like and care about. Even more so the people who've become your close colleagues and friends.

The important stuff

The way I went into this was that I wanted to build a company where I myself would love to work. A place with warmth and laughter. Where I am inspired to learn and have the opportunity to do so. Every day. (I’m saying ‘I’ but I should really be saying ‘We’). In as little as one year I can comfortably say that we’ve achieved exactly that. We are for sure still working out some kinks and will continue to fine-tune every aspect of the business but we are well on the way. By maintaining a flat organisation where everyone is invited and encouraged to contribute and influence the direction of the company Elva will hopefully be a place where more people love to work. From my previous job, the majority of my closest colleagues friends have left said job. One is well on the way to becoming a police officer, another one left for Stockholm and a third one is moving abroad to save and care for seals. Have you heard anything so noble quirky lovely? One thankfully didn’t evade me and works side by side with me at Elva. And as far as the other founders… well we all used to work together at one time.

The point I’m trying to make is this: The most important thing, for me, is the people around you. Your colleagues. After all, you spend the lion part of the time you are awake together with them. At least now I can have a say in who those people are. They will come and go, and for various reasons as the examples above. All we have to decide is what to do with the time that is given us.

Key takeaways

• Build capital (if possible without anybody else’s money). You never know when that rainy day comes.

• Build the team. It’s nice to know that you can count on the people around you when that rainy day turns into a storm.

• Build your brand. You don’t have to become a household name. But things tend to come easier if potential customers know your name.

• Build the culture. And talk, talk, talk. Make sure that everyone can make their voice heard. We are all different but should be comfortable enough to speak our minds.

I can honest-to-God, hand on heart, scout's honour and I kid you not say that I love every day of working at Elva. And that's largely due to the remarkable people I share my days with. Through open and honest communication, we aim to retain the amazing talent we have and, by staying curious and updated, we hope to attract even more.

If you enjoyed this post, want to know more about me, working at Elva or just want to reach out you can find me on LinkedIn.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

Using AWS, IoT core, Lambda, Cloudwatch, TS, Rust

Requirements (total cost: ~31$)

• 4 Weight sensors & 1 Amplifier/ADC

• 1 RPI zero w

• AWS account

• A few hours of your lifetime

TLDR; Here are the projects

1. Cloud implementation

2. On-board processes

The Setup

The overall setup looks like this.

The image displays an abstract view of the data flow in the finalized system.

1. The sensors output an analog value depending on the applied pressure (weight). The reading is transformed into a digital output using an analog-to-digital converter (ADC).

2. That resulting data is sent to the scale-reading-process using serial communication (via Raspberry’s GPIO).

3. Next, the first (scale worker) process collects and transforms the digital values into something more understandable to us. The second (IoT worker) pushes that data to AWS IoT core and, in turn, other upstream services like Slack.

The Cloud

AWS IoT Core, Lambda, and Cloudwatch Metrics

As the infrastructure diagram notes, the IoT worker running on the Raspberry is pushing the translated scale readings to IoT core (using MQTT). Once we're in the cloud, we can do whatever we like. The main gist is that we have two handlers and some certificates.

We pass the final readings to Cloudwatch using lambda in this specific setup.

// ~/byra-watcher/src/lambda.ts
const metrics = new Metrics({ namespace: "elva-labs", serviceName: "byra" });

export const handler = middy(async (
  event: {
    grams: number
  }) => {
  metrics.addMetric("beerWeight", MetricUnits.Count, event.grams);
}).use(logMetrics(metrics));

In Cloudwach, we can follow the readings and create alarms if the weight is below a specific threshold value. If this threshold value is breached, another lambda is triggered, which sends a message to Slack so that everyone can see that we have a critical problem to resolve.

// ~/byra-watcher/src/slack.ts
export const handler: EventBridgeHandler<'_', CloudWatchAlarmDetail, void> = async (event) => {
  console.info(`Received event: ${JSON.stringify(event)}`);

  await new IncomingWebhook(Config.SLACK_URL).send({
    text:
      event.detail.state.value === "ALARM"
        ? `${WARN_EMOJI} CRITICAL: ${BEER_EMOJI} Beer count is low`
        : `${HAPPY_EMOJI} ALL GOOD: ${BEER_EMOJI} We have beer!`,
  });
};

It's time to deploy our handlers and acquire our "thing"-certificates so the RPI can push data to the cloud.

// ~/byra-watcher/stacks/ByraStack.ts
// ...
const { thingArn, certId, certPem, privKey } = new ThingWithCert(stack, 'ByraScale01', {
  thingName: 'byra-01',
  saveToParamStore: true,
  paramPrefix: 'devices',
});
// ...

cd ~/byra-watcher && npm run deploy

SST v2.36.1

➜  App:     byra-watcher
   Stage:   dev
   Region:  eu-north-1
   Account: ...

|  ByraStack PUBLISH_ASSETS_COMPLETE 

✔  Deployed:
   ByraStack
   Byra01Thing: arn:aws:iot:eu-north-1:...:thing/byra-01
   CertId: ...
   CertPem: -----BEGIN CERTIFICATE-----
            ...
            -----END CERTIFICATE-----    

   PrivKey: -----BEGIN RSA PRIVATE KEY-----
            ...
            -----END RSA PRIVATE KEY-----

Who could have guessed? Super simple. Now, we have our infrastructure deployed and our certificates generated.

The Hardware

The objective of the Raspberry is to read data from the sensors, transform the reading into something we can understand, and then push that data to the cloud for further action.

• The scale worker code can be found here.

• The IoT worker code can be found here.

• The wiring guide for the cells can be found here.

To read data, we needed to know how to communicate with the analog-to-digital (ADC) component. Reading through the documentation, we found that it uses serial communication and a 24-bit data protocol (+gain bits) to send data over the wire.

The following protocol is implemented like the following image. In short, we ensure we can read data from the ADC and dump each bit into a temporary buffer, which finally translates to an actual value in grams.

// ~/rpi/elva-byra-scale/src/hx711.rs#L107
fn read(&mut self) -> Result<f32, HX711Error> {
        if !self.dout.is_low() {
            return Err(HX711Error::new(HX711ErrorType::DoutNotReady));
        }

        let mut buff = 0;

        for _ in 0..24 {
            self.send_pulse()?;
            thread::sleep(Duration::from_nanos(100));
            buff <<= 1;
            buff |= match self.dout.read() {
                Level::Low => 0b0,
                Level::High => 0b1,
            };
        }

        // Sets gain for following reads...
        for _ in 0..match self.gain {
            Gain::G32 => 3,
            Gain::G64 => 2,
            Gain::G128 => 1,
        } {
            self.send_pulse()?;
        }

        Ok(self.translate(buff))
}

Debugging

We can debug the communication over the wires using a logic analyzer and this helpful program. A typical information exchange looked like this.

The upper channel is the data channel (sent from the ADC), and the lower is the pulses sent from the Raspberry over the SCK channel (which dictates the read-timings).

We read the expected bytes into our process using the documented timings. Then convert the 24 bits to an integer value (that doesn't mean anything to us for now). After we have ensured that the readings are stable, i.e., not bouncing all over the place and giving us random values, we can move on to translating the actual output to a representation we can understand.

Calibration & Output

Next, we placed the fridge on the scale, ensured all sensors were actively engaged, and noted a few readings. Then, place one kilogram on the scale and do the same thing. We should be able to determine two averages, which will help us translate pressure changes to actual grams.

We now have two reference values, one when the scale is empty and one with one kilogram on the scale.

points_per_gram = (one_kg_reading_avg - empty_scale_reading_avg) / 1000

// ~/elva-byra-scale/src/hx711.rs#L153
fn translate(&self, read: i32) -> f32 {
    (read as f32 - self.offset) / self.points_per_gram
}

Great, we now use this function to translate the reading from the scale to something we can understand and reason about in the upstream services.

Using an offset (empty_scale) of 1076761 in our case and 1099180 (one_kg_reading). We get the following output while having a few things in the fridge that would be ~10 kg of weight.

The scaling process reads the scale value at a fixed interval and outputs a more readable JSON structure to the /tmp/byra.sock so that other processes may act on the changes.

$ netcat -U /tmp/byra.sock
# {"datetime":"2023-06-18T12:11:48.759024680Z","grams":3660.4785}

The secondary process listens to this socket and pushes each new sample to AWS IoT core using MQTT and the credentials we received after deploying the infrastructure.

The Result

Finally, we can ensure we're always prepared to supply our guests with cold beverages on arrival and our BoA metric remains in the safe zone.

If you enjoyed this post, follow me on GitHub. I dabble with everything related to fully managed serverless solutions on AWS, embedded stuff, and Rust.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

For this tutorial you need:

• an AWS account

• AWS credentials configured correctly

• node.js 16

• npm 7

We'll start with creating a project with SST. A very neat thing with SST is that you can choose your preferred frontend framework to go with it. (If you already have a frontend repository set up for your idea you can install SST in "drop-in mode"). For this tutorial I'm creating a basic standalone React + Vite app.

npx create-sst@latest my-great-project
cd my-great-project
npm install

Then you can go ahead and open it in your editor of choice.

cd packages
npm create vite@latest

When asked about the name of the project, call it "web". This creates the basic website in the packages/web folder. Now we need to add a construct for the site in your stack. Open stacks/MyStack.ts and add the StaticSite construct beneath the bus.subscribe()

const web = new StaticSite(stack, "web", {
  path: "packages/web",
  buildOutput: "dist",
  buildCommand: "npm run build",
  environment: {
    VITE_APP_API_URL: api.url,
  },
});

stack.addOutputs({
  ApiEndpoint: api.url,
  CloudfrontUrl: web.url
});

It's time to start Vite locally together with the resources set up in your stack. In your root directory run this:

npx sst dev

After it has finished bootstrapping and deploying, open another terminal and run this:

cd packages/web
npm i
npx sst bind vite

And now you're ready to develop your website as you see wish. Change the color of the background or add a div with a funky quote or something. Next up is deploying this.

It's super simple.

npx sst deploy --stage prod

That's about it.

Considering you bought the domain for the page years ago when you first had the idea it's time to put it in use. Either transfer ownership of the domain over to this AWS account or create a Hosted Zone in Route 53 with the domain. Then when it's ready just modify the Site construct like this:

const web = new StaticSite(stack, "web", {
  path: "packages/web",
  buildOutput: "dist",
  buildCommand: "npm run build",
  customDomain: {
    domainName: 'verycoolwebsite.com',
    domainAlias: 'www.verycoolwebsite.com'
  },
  environment: {
    VITE_APP_API_URL: api.url,
  },
});

stack.addOutputs({
  ApiEndpoint: api.url,
  CloudfrontUrl: web.url,
  CustomDomain: web.customDomainUrl
});

Deploy and check out your site. Send it to all your friends! At least you have a nice-looking url.

If you enjoyed this post you could follow me on 𝕏 at @Paliago. I mostly engage with the serverless community and post pictures of my pets.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

Understanding SQS and Lambda Integration

SQS and Lambda provide a powerful integration for building scalable and event-driven architectures. With Lambda event source mappings, you can process messages from SQS queues asynchronously, decoupling components and ensuring reliable message delivery. When a Lambda function subscribes to an SQS queue, it uses a polling mechanism to wait for messages to arrive. Lambda consumes messages in batches. For each batch, Lambda triggers your function once. If there are more messages in the queue, Lambda can scale up to 1,000 concurrent functions, adding up to 60 functions per minute. Upon successful processing, Lambda automatically removes the messages from the queue.

Consume messages from SQS using Lambda

When working with SQS, you can process messages individually or in batches. The Lambda Event Source Mapping supports larger batches, allowing up to 10,000 messages or 6 MB in a single batch for standard SQS queues. In contrast, the SDK is limited to 10 messages per API call. This is one of the reasons why you should use Lambda Event Source Mapping whenever possible when you consume messages from SQS.

Processing messages individually offers advantages such as faster processing and simpler error handling. However, there are situations where batch processing is more appropriate. Batch processing is beneficial when you need higher throughput, improved efficiency, or when cost optimization is important.

Processing individual messages

Consuming individual SQS messages is relatively simple in Lambda, each message is treated as an independent event triggering the execution of your Lambda function. It is still important to implement appropriate error handling to capture any exceptions or errors that may occur during message processing. When a message is successfully processed by your Lambda function, Lambda will automatically delete the message from the queue. However, if an error is caught during the execution of the function, the message will be returned to the queue for further processing or retries. This ensures that messages are not lost in case of errors and allows for proper handling and reprocessing of failed messages.

Here's an example of a Lambda Function written in TypeScript that consumes individual messages:

import { SQSHandler, SQSEvent } from "aws-lambda";

export const handler: SQSHandler = async (event: SQSEvent) => {
  try {
    for (const record of event.Records) {
      const message = record.body;
      // Process the message here
      console.log("Processing message:", message);
    }
  } catch (error) {
    console.error("Error processing SQS messages:", error);
    throw error;
  }
};

Processing batches of messages

When Lambda processes a batch of messages from an SQS queue, the messages remain in the queue but are temporarily hidden based on the queue's visibility timeout (more on this later in this blog post). If your Lambda function successfully handles and processes the batch, Lambda automatically deletes the messages from the queue. However, if your function encounters an error while processing a batch, all messages in that batch reappear in the queue, making them visible again.

To ensure that messages are not processed multiple times, you have a couple of options. Firstly, you can configure your event source mapping to include ReportBatchItemFailures in the function response. This allows you to handle and track failed messages within your function code, this is the recommended approach when dealing with batches. Alternatively, you can utilize the Amazon SQS API action called DeleteMessage to explicitly remove messages from the queue as your Lambda function successfully processes them. The use of this API action ensures that messages are not reprocessed inadvertently.

I will provide two examples of how you can utilize the ReportBatchItemFailures functionality to return partial failures of messages, this will ensure that our function doesn't process messages more than once. I will demonstrate how this can be done by constructing a batchItemFailures function response as well as using the Middy middleware.

⚠️ Please note that you need to configure your Lambda event source mapping to include batch item failures for these examples to work.

Here's an example of a Lambda Function written in TypeScript that consumes a batch of messages and returns BatchItemFailures in the function response:

import { SQSEvent, SQSHandler, SQSBatchResponse } from 'aws-lambda';

export const handler: SQSHandler = async (event: SQSEvent) => {
  const failedMessageIds: string[] = [];

  for (const record of event.Records) {
    try {
      const message = record.body;
      console.log("Processing message:", message);
      // Process the message here
    } catch (error) {
      failedMessageIds.push(record.messageId);
    }
  }

  const response: SQSBatchResponse = {
    batchItemFailures: failedMessageIds.map((id) => ({
      itemIdentifier: id,
    })),
  };

  return response;
};

Here's an example of a Lambda Function written in TypeScript that consumes a batch of messages using the sqs-partial-batch-failure Middy middleware. This code simplifies the consumption of message batches. It automatically includes the failed message IDs as BatchItemFailures in the function response, eliminating the need for manual error tracking and reducing development overhead.

import middy from '@middy/core';
import sqsPartialBatchFailureMiddleware from '@middy/sqs-partial-batch-failure';
import { SQSEvent, SQSRecord } from 'aws-lambda';

async function mainHandler(event: SQSEvent): Promise<any> {
  const messagePromises = event.Records.map(processMessage);
  return Promise.allSettled(messagePromises);
}

async function processMessage(record: SQSRecord): Promise<any> {
  const message = record.body;
  console.log("Processing message:", message);
  // Process the message here
}

export const handler = middy(mainHandler).use(sqsPartialBatchFailureMiddleware());

Noteworthy configurations

Lambda Event Source Mapping

Batch size

The batch size (BatchSize) configuration determines the number of records sent to the Lambda function within each batch. For standard queues, you can set the batch size up to a maximum of 10,000 records. However, it's important to note that the total size of the batch cannot exceed 6 MB, regardless of the number of records configured.

Batch window

The batch window (MaximumBatchingWindowInSeconds) setting determines the maximum time, in seconds, that records are gathered before invoking the Lambda function. Please note that this configuration applies only to standard queues.

Maximum Concurrency

The maximum concurrency (ScalingConfig) feature enables us to set a maximum number of concurrent invocations for an Event Source Mapping, eliminating the issues caused by excessive throttling that was previously present when using reserved concurrency in Lambda. With this capability, we have gained better control over concurrency, especially when utilizing multiple Event Source Mappings with the same function.

SQS configurations

Queue visibility timeout

The visibility timeout (VisibilityTimeout) in SQS is a setting that determines how long a message remains invisible in the queue after it has been retrieved by a consumer. When a consumer receives a message from the queue, it becomes temporarily hidden from other consumers for the duration of the visibility timeout. If you choose a batch window greater than 0 seconds, it is important to consider the increased processing time within your queue's visibility timeout. It's recommended to set the visibility timeout to at least six times your function's timeout, plus the value of the batch window (MaximumBatchingWindowInSeconds). This ensures sufficient time for your Lambda function to process each batch of events and handle potential retries caused by throttling errors. If you for example would have function timeout of 30 seconds and a batch window of 20 seconds. This will be set to (30 x 6) + 20 = 200 seconds.

You can read more about this here: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-eventsource

Dead-letter queues (DLQs)

When a message fails to be processed by Lambda, it is returned to the queue for retrying. However, to prevent the message from being added to the queue multiple times and causing unnecessary consumption of Lambda resources, it is recommended to designate a Dead Letter Queue (DLQ) and send failed messages there. To control the number of retries for failed messages, you can set the Maximum receives value for the DLQ. Once a message has been re-added to the queue more times than the Maximum receives value, it will be moved to the DLQ. This allows you to process these failed messages at a later time, separate from the main queue.

You can read more about when to use a DLQ here: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#sqs-dead-letter-queues-when-to-use

Conclusion

In conclusion, the integration between SQS and Lambda provides a powerful and scalable solution for building event-driven architectures. By leveraging event source mappings, configuring batch processing, and utilizing noteworthy features like dead-letter queues and visibility timeouts, you can ensure reliable message processing and optimize resource utilization. Embrace this integration to unlock the full potential of distributed systems and create resilient applications that scale effortlessly.

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

The use-case we explore in this post is about enabling a central account (Tools) to handle feature flags for all environments and services within an Organization. The service we want to set up feature flags for in this post is called ElvaFlags Inc and is located in it's own accounts (dev and prod). This would for example enable several services to look for the same flag and can be used to enable the feature all over your application at once.

Organization Units

AWS Organizations and Organization Units are a great way to handle your multi-account strategy. Our own Tobias wrote a great post about it and also helped some during the real life scenario when we implemented this. The tl;dr you need to for this post is:

• Organizations are the outer shell of the account structure. All accounts are within this.

• Organization Units can be viewed as "folders" in which you can group your accounts. OUs can exist within other OUs.

The Solution

We'll start with setting up an AppConfig application in the account where we want to centrally manage the feature flags. In our case the Tools account.

1. Create an Application. Applications are a logical grouping of Configuration Profiles which in turn can have flags. A suggestion would be to name it after your application/solution you're developing.

2. Next up is creating an Environment. AWS describes them as "logical deployment groups of AppConfig targets" so a name like dev or prod would make sense here.

3. The next step is to create a Configuration Profile. Configuration profiles are either collections of feature flags or a "Freeform configuration". In this post we're focusing on FFs.

4. In the configuration profile you create the flags you want to toggle.

5. Save the configuration with the flags. Give it a version label or let AWS handle it for you.

6. Create an IAM Role in the same account with a policy which allows the actions: GetLatestConfiguration and StartConfigurationSession. Example policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "appconfig:GetLatestConfiguration",
                "appconfig:StartConfigurationSession"
            ],
            "Resource": "*"
        }
    ]
}

1. Create a trust relationship for the role. It should allow the the action AssumeRole on all AWS accounts (wait for it), but have a condition. The condition is a StringLike where you can define what OUs you want to allow access to the FFs. Example trust relationship:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ForAnyValue:StringLike": {
                    "aws:PrincipalOrgPaths": [
                        "o-orgiId/r-rootId/ou-WorkloadsId*"
                    ]
                }
            }
        }
    ]
}

In the example here I'm allowing the AssumeRole action on all OrgPaths that begin with my organization id/organization root id/WorkloadsOuId* which essentially means all accounts within my Workloads OU. Since it's an array you can add several OUs if you need to. Now everything is ready in the Tools account!

To then fetch the feature flags in your front- or backend you need to first get the STS token and then use that as the credentials for the AppConfig client. Here is an example code snippet to finish the writeup:

const stsClient = new STSClient({
  region: REGION,
});

interface Settings {
  applicationID: string;
  configurationProfileID: string;
  environmentID: string;
}
export const getAppConfiguration = async (
  settings: Settings,
) => {
  const stsResponse = await stsClient.send(
    new AssumeRoleCommand({
      RoleArn: READ_FLAGS_ROLE,
      RoleSessionName: ASSUME_ROLE_SESSION_NAME,
    }),
  );

  if (!stsResponse.Credentials) {
    return null;
  }

  const { AccessKeyId, SecretAccessKey, SessionToken } =
    stsResponse.Credentials;

  if (!AccessKeyId || !SecretAccessKey) {
    throw new Error(`Failed to retrieve ${ASSUME_ROLE_SESSION_NAME} `);
  }

  const client = new AppConfigDataClient({
    region: REGION,
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
      sessionToken: SessionToken,
    },
  });
  const sessionResponse = await client.send(
    new StartConfigurationSessionCommand({
      ApplicationIdentifier: settings.applicationID,
      ConfigurationProfileIdentifier: settings.configurationProfileID,
      EnvironmentIdentifier: settings.environmentID,
    }),
  );
  const configurationResponse = await client.send(
    new GetLatestConfigurationCommand({
      ConfigurationToken: sessionResponse.InitialConfigurationToken,
    }),
  );

  return JSON.parse(
    Buffer.from(configurationResponse.Configuration ?? '').toString('utf-8'),
  );
};

For additional reading on retrieving and using a configuration AWS has a detailed page in their docs.

That's it! Hopefully you learned something!

If you enjoyed this post you could follow me on twitter at @Paliago where I honestly mostly retweet dumb AWS related things. There might be some posts on the horizon as well 😶‍🌫️

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future

But because of how the pricing model is set up for WAF, the costs can quickly spiral out of control when adhering to the AWS best practices on multi-account strategies. Namely, the cost of merely having a Web ACL created in an account is $5 per month, and then it's $1 per rule added to that Web ACL. It's a small amount for each account but snowballs as you have hundreds or thousands of accounts, which isn't uncommon in a larger organization, and before you know it, you're paying thousands of dollars just for having these rules existing.

🛡️ AWS Shield to the rescue

AWS Shield is a managed service that protects against DDOS attacks. The "Standard" version of Shield is free of charge, and all AWS users automatically benefit from this service. There's, however, also an "Advanced" version of this service that many might have heard about, but few actually have any hands-on experience with, as it's $3000 per month with a minimum of 12 months commitment - and there's no free tier. All accounts in the AWS Organization will benefit from the same subscription from the management account, though.

Shield Advanced offers a higher level of protection, you get access to the Shield Response Team, and a few other features. But, the somewhat unexpected key feature in this case actually lies within the pricing model:

Did you catch that? Let's look again.

Because the Amazon CloudFront Distribution is already protected under AWS Shield Advanced, there are no additional charges for AWS WAF web ACL, rule or request fees.

If a resource in an account is protected by Shield Advanced, the WAF Web ACL and Rule costs for that account are waived. But a Web ACL and its rules are not created as part of a resource; they're created individually and are then attached to a resource, so how does that actually work? It's not very intuitive, but the costs are waived for a specific Web ACL as long as at least one resource that Shield Advanced protects has the Web ACL attached.

⚠️ Note that AWS Shield Advanced Data Transfer and other AWS WAF fees still apply. Managed rule groups such as Targeted Bots and Account Takeover Prevention are also not included in the Shield Advanced subscription.

What this means in practice is that if you're spending over $3000 per month on Web ACL and Rule fees, you can effectively cap those costs at $3000 and prevent them from spiraling further as your number of AWS accounts grows by subscribing to AWS Shield and enrolling your resources. And as an added bonus, you'll benefit from improved DDOS protection. Because of all this, it can be a good idea to automatically create a dummy resource that uses the Web ACL when vending new accounts - because otherwise, the fees won't be waived until a resource that does is deployed. Another important aspect is that you can use an AWS FirewallManager Policy, at no additional cost, to automatically subscribe all new accounts to Shield Advanced and protect all resources that use a WAF.

In conclusion, AWS Shield Advanced can be a game-changer when it comes to reducing the costs of AWS WAF. By protecting resources with Shield Advanced, the costs for WAF Web ACL and Rule are waived, which can save thousands of dollars for organizations with a large number of AWS accounts. While the high upfront cost of Shield Advanced may be daunting, the higher level of protection, access to the Shield Response Team, and, primarily, the cost savings on WAF can make it a fantastic hidden investment for organizations that heavily rely on AWS.

You can read more about AWS Shield Advanced here and about WAF best practices here!

Hi there, I'm Sebastian Bille! If you enjoyed this post or just want a constant feed of memes, AWS/serverless talk, and the occasional new blog post, make sure to follow me on Twitter at @TastefulElk or on LinkedIn 👋

Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future