Building a Kiro Power for AWS Amplify Gen 2

🏃 TL;DR

There’s a moment that often comes after big conferences.
A brief pause, when the excitement fades and only the right questions remain.

For me, that moment arrived after the latest AWS re:Invent in December, with the announcement of Kiro Powers and then almost by accident, when I stumbled upon a brand-new page in the AWS Amplify Gen 2 documentation: Build with AI assistants

It made me ask a simple question:

What if working with Amplify Gen 2 could feel more guided, more intentional, and less repetitive, every single time?

That question eventually became AWS Amplify Gen 2 Kiro Power.

✨ AWS MCP server and AWS SOPs

I immediately started experimenting AWS MCP SOPs integration for AWS Amplify Gen 2, as prompts and guidance rules as suggested by documentation. I tried it in a few real scenarios:

• Building a full application from scratch
• Adding a new backend to an existing frontend
• Creating a frontend for a project where only the backend existed
• Being guided step by step through deployment and configuration

What surprised me wasn’t just that it worked, it was how well it worked.

The agent didn’t just execute commands: it followed patterns, respected best practices and reduced the mental overhead of remembering how AWS Amplify Gen 2 wants things done.

But what I finally wanted to achieve was not to use prompts, but for the agent to be able to guide me autonomously.

At this point this was my new question:

Why am I loading MCP SOPs upfront for every request, when the agent could just “know” when to use it dinamically?

👻 From idea to a Kiro power

Instead of treating AWS MCP SOPs as something external plugged into the agent and loaded upfront, I wanted the agent to know when activate it and use it.

That’s where Kiro Power comes in.

Traditional MCP servers are loaded upfront, while a power enables Dynamic MCP tool loading saving context (and thus tokens!)

The idea is simple:

• Let the agent know how Amplify Gen 2 actually works
• Encode best practices, workflows, and conventions
• Make those rules automatically available whenever AWS Amplify is part of the conversation

So every time the agent:

• Designs a backend with AWS Amplify
• Modifies an existing AWS Amplify project
• Generates frontend code for an AWS Amplify app
• Handles environment setup or deployment via AWS Amplify

it does so without loading the AWS MCP Server upfront but having AWS Amplify Gen 2 in mind and knowing when activate the power, without me having to restate the rules every time i need it.

📦 What I've build.

I started by following the official instructions to create a Kiro Power, which you can find here.

That’s when I realized something amusing:

There is a power to create powers.

So I installed it and let it guide me in building my own, a personal Kiro Power tailored specifically for AWS Amplify Gen 2.

From there, it became an iterative process: I reviewed the generated output, tightened the rules, explicitly blocked AWS Amplify Gen 1 related commands, and added behaviors based on my hands-on experience with AWS Amplify Gen 2 in real projects.

The final repository contains:

• A Kiro Power definition focused on AWS Amplify Gen 2
• Embedded AWS MCP SOPs that guide architecture, setup, and evolution
• A structure designed to be reusable and extensible

It’s not meant to replace documentation but to operationalize it.

You can find the full implementation and details here:

👉 AWS Amplify Gen 2 Kiro Power

🤝 Contributing

Also I've made a PR to the official kirodotdev/powers repo hoping this will be merged for all folks out there building with AWS Amplify Gen 2. You can use also this repo if you want to try all powers officially available but including mine.

👀 See it in action

After Installation

Once the power is installed, Kiro will show you a confirmation and overview of what the power provides:

Power Usage Guide

When you ask Kiro for help with Amplify Gen 2, it will propose the available workflows and guide you through the process:

🎯 Why this matters

AWS Amplify Gen 2 is powerful, but it also introduces new mental models:

• Backend-first thinking
• Strong conventions
• Opinionated workflows

Those are great, until you context-switch, forget a detail, or come back to a project weeks later.

Also there is still a lot of confusion with AWS Amplify Gen 1 doc and samples (at least for me) and folks migrating from Gen 1 projects can easily feel overwhelmed (I’ve definitely felt that pain!).
You can test this yourself: ask Kiro to initialize a project without mentioning the generation. It will default to Gen1, or worse, it may switch back and forth between Gen 1 and Gen 2 as you iterate.

By encoding Gen 2 guidance via AWS MCP SOPs into Kiro agent with a power:

• You reduce cognitive load
• You avoid subtle mistakes between generation
• You keep architectural decisions consistent over time
• You use best practices
• You use a security first approach
• You don't waste tokens (and money) when you're not speaking about Amplify!

In short, you let Kiro agent worry about remembering AWS Amplify Gen 2 doc and best practices, so you can focus on building your app.

🙏 Acknowledgements

This work wouldn’t be the same without thoughtful feedback and sharp reviews.

A big shout-out to Catalin Borsan and Francesco Bertani: their input helped shape this from an experiment into something actually useful.

🙋 Who am I

I'm D. De Sio and I work as a Head of Software Engineering in Eleva.
I'm currently (Apr 2025) an AWS Certified Solution Architect Professional and AWS Certified DevOps Engineer Professional, but also a User Group Leader (in Pavia), an AWS Community Builder and, last but not least, a #serverless enthusiast.

My work in this field is to advocate about serverless and help as more dev teams to adopt it, as well as customers break their monolith into API and micro-services using it.