Gunnar Grosch

Posted on Feb 22

Building the AWS Serverless Power for Kiro

#aws #kiro #productivity #serverless

Kiro can scaffold a Lambda function and wire up an API Gateway. But ask it to choose between Step Functions and Durable Functions for your workflow, or to configure a Kafka event source mapping with the right VPC setup and authentication, and you'll hit a wall. General knowledge gets you a working template. Practical experience gets you one that holds up in production.

Powers, introduced at re:Invent 2025, are Kiro's answer to this. A Power bundles an MCP server connection, best practices, and workflow guidance into a package that loads dynamically when relevant. Without framework context, agents guess at patterns and configurations. Powers give the agent instant access to specialized knowledge, but only when it's actually needed, avoiding the context bloat you get from loading everything upfront.

I'd already encoded this serverless expertise as a Claude Code plugin. The AWS Serverless Kiro Power brings that same knowledge to Kiro. This post walks through what it covers, how it's built, and what I learned along the way.

What the Power Covers

The scope is the full serverless development lifecycle on AWS, backed by 25 tools from the AWS Serverless MCP Server and ten steering guides that provide decision-making context. Project initialization, building, local testing, deployment, web application hosting, event source mappings, security, and observability. Rather than listing every capability, here's a concrete example of the difference the Power makes.

Kafka ESM setup: without the Power vs. with it

Tell Kiro "set up a Lambda function to process messages from my MSK cluster." Without the Power, you get a Lambda function with an MSK event source mapping. The basics are there, but the batch size is the default, there's no error handling for partial batch failures, the IAM policy is too broad, and the VPC configuration doesn't account for your cluster being in private subnets. It works until it doesn't.

With the Power, the esm_guidance tool asks about your cluster configuration before generating anything. The steering guides inform the agent to configure BisectBatchOnFunctionError, set up a DLQ for failed messages, and choose a batch size based on your message throughput. secure_esm_msk_policy generates a least-privilege IAM policy scoped to your specific cluster ARN instead of using wildcards. The VPC configuration uses private subnets with security group rules for your broker ports. esm_optimize tunes the parallelization factor if you need higher throughput. The result handles the edge cases that only show up after you've run the setup in production for a while.

That pattern repeats across the Power. Project setup through sam_init uses the right template for your use case instead of the default. deploy_webapp handles the full CloudFront and S3 setup for Lambda Web Adapter deployments. The observability guide knows which CloudWatch metrics to alarm on and what thresholds make sense. The troubleshooting guide maps symptoms to root causes.

How It's Built

aws-serverless-kiro-power/
├── POWER.md                           # Tool docs, best practices, troubleshooting
├── mcp.json                           # MCP server connection config
└── steering/                          # On-demand workflow guidance
    ├── getting-started.md             # Prerequisites and first-use walkthrough
    ├── sam-project-setup.md           # SAM initialization and workflow
    ├── cdk-project-setup.md           # CDK constructs, testing, pipelines
    ├── web-app-deployment.md          # Full-stack deployment patterns
    ├── event-sources.md               # Event source mapping configuration
    ├── event-driven-architecture.md   # EventBridge, Pipes, schema registry
    ├── orchestration-and-workflows.md # Step Functions, Durable Functions
    ├── observability.md               # Logging, tracing, metrics, dashboards
    ├── optimization.md                # Performance and cost tuning
    └── troubleshooting.md             # Symptom-based diagnosis

The split between POWER.md and the steering files is deliberate. POWER.md is always loaded. Its frontmatter defines the activation keywords that tell Kiro when to load the Power:

---
name: "aws-serverless"
displayName: "AWS Serverless"
description: "Build and deploy serverless applications with AWS Lambda, SAM, API Gateway, EventBridge, Step Functions, and event-driven architectures"
keywords: ["serverless", "lambda", "sam", "cdk", "api gateway", "aws", "deployment", "cloudformation", "event-driven", "microservices", "backend", "web app", "dynamodb", "kinesis", "sqs", "kafka", "deploy", "cloudwatch", "cold start", "rest api", "s3", "eventbridge", "function url", "step functions", "durable functions", "state machine"]
author: "Gunnar Grosch"
---

Below the frontmatter, POWER.md contains tool documentation with parameter tables and quick-reference best practices. The steering files load on demand when the agent hits a specific workflow. This matters because agent context windows have limits. Loading all ten guides upfront would eat context budget on knowledge the agent might not need for the current task. On-demand loading means the Kafka ESM guide loads when you ask about Kafka, not when you're deploying a web app.

mcp.json connects to the AWS Serverless MCP Server with --allow-write and --allow-sensitive-data-access flags enabled. You can remove either flag if you want the agent to advise without modifying your AWS account.

Design Decisions

A few things I learned building this:

Keep steering files focused on decisions, not templates

Early versions had full YAML templates, CI/CD pipelines, and code examples in the steering files. The problem is that the MCP tools already generate these. Having them in the steering files just duplicates content and wastes context. The final versions focus on decision-making guidance: when to use which deployment type, how to choose batch sizes, what metrics to alarm on.

Document every tool with actual parameters

I validated every tool's parameters against the actual MCP server schemas. This matters because if POWER.md says a parameter is called function_identifier but the tool actually expects resource_name, the agent will fail silently or hallucinate parameters. All 25 tools have correct required/optional parameter listings.

Follow the official Power structure

The official Kiro Powers (Stripe, Neon, Datadog, and others) follow a consistent structure in POWER.md: frontmatter with keywords, overview, available steering files, full MCP tool documentation, usage examples, Do/Don't best practices, Error/Cause/Solution troubleshooting, and configuration. Following this pattern means Kiro knows exactly where to find what it needs.

The expertise is portable, the packaging isn't

I built the Claude Code plugin first. The ten steering guides transferred to the Kiro Power almost entirely. The packaging didn't: Claude Code uses SKILL.md as the entry point, Kiro uses POWER.md with different frontmatter conventions. Claude Code uses .mcp.json, Kiro uses mcp.json. Claude Code's plugin includes a PostToolUse hook that auto-validates SAM templates after edits, which doesn't package into a Power. You could set up that hook in Kiro separately, but it's not something the Power installs for you. Distribution is different too: marketplace installation versus direct GitHub import.

But the real investment is the expertise layer: the decision trees, the operational knowledge, the judgment calls that come from experience. Writing that once and adapting the packaging was significantly less work than building from scratch. This is the same idea behind the Agent Skills standard: encode expertise in a format that multiple tools can consume. If you structure knowledge as clear decision guidance in markdown files, the per-tool adaptation is mostly mechanical.

Getting Started

Prerequisites

You'll need:

AWS CLI configured with credentials
AWS SAM CLI installed
Docker Desktop (for local testing)
Python 3.10+ with uv package manager (this runs the MCP server locally, regardless of what language your application uses)

Installation

Open the Powers panel in Kiro
Click "Add Custom Power" and select "Import power from GitHub"
Enter: https://github.com/gunnargrosch/aws-serverless-kiro-power
Press "Enter" to confirm

Try It Out

The Power activates on keywords like serverless, lambda, sam, deploy, dynamodb, kinesis, sqs, and others. Just describe what you want to build:

> I need a Python API on Lambda with DynamoDB behind it
> the iterator age on my kinesis stream keeps climbing, help me figure out why
> set up an EventBridge bus for order events with routing to three downstream services
> my cold starts are killing me, what can I do

Kiro uses the MCP tools to scaffold, build, test, and deploy, following the patterns in the steering files.

Making It Better

Both the Claude Code plugin and the Kiro Power are open source. The underlying expertise is shared, so a fix in one improves both. Some areas where contributions would be most useful:

Steering guides for additional event source patterns (DocumentDB, MQ, S3 event notifications)
Real-world troubleshooting scenarios that the current guides don't cover
Corrections where the guidance doesn't match your production experience

Open an issue or a PR on whichever repo you're using.

Additional Resources

What Powers have you built or are you thinking about building? Let me know in the comments.

DEV Community