Why I built a Custom Kiro Power to ship faster with AWS Blocks

Every developer building on AWS has hit the same wall. You need a sandbox account to test your idea. In most organizations that means a ticket, an approval workflow, a budget tag, and three days of waiting before you can find out if your DynamoDB schema even makes sense.

Once you get access, the iteration cycle starts: write code, deploy, wait two minutes, request pull request approvals from Cloud Engineering/Platform leads and discover your IAM policy is wrong, fix it, deploy again, wait again. For a single table and an API endpoint, you might burn half a day just getting to "hello world" on real infrastructure.

And when the sprint is over, somebody needs to tear it all down so the bill doesn't keep running.

AWS Blocks eliminates this entire loop. You write your application using self-contained building blocks that run locally on your laptop with zero AWS credentials, then flip a single switch to deploy real infrastructure when the feature is validated. No sandbox requests. No deploy-wait-fix cycles during development. No environment-specific configuration. The code you test locally IS the code that runs on AWS.

How AWS Blocks works

You import a building block and use it directly in your application logic. There is no separate infrastructure definition layer. AWS calls this "Infrastructure from Code" — your backend entry point (aws-blocks/index.ts) is both your runtime code and your infrastructure definition simultaneously.

import { Scope, ApiNamespace, DistributedTable } from '@aws-blocks/blocks';
import { z } from 'zod';

const scope = new Scope('my-app');

const tasks = new DistributedTable(scope, 'tasks', {
  schema: z.object({
    userId: z.string(),
    taskId: z.string(),
    title: z.string(),
    done: z.boolean(),
  }),
  key: { partitionKey: 'userId', sortKey: 'taskId' },
});

export const api = new ApiNamespace(scope, 'api', (context) => ({
  async addTask(userId: string, title: string) {
    await tasks.put({ userId, taskId: crypto.randomUUID(), title, done: false });
  }
}));

Run npm run dev and this works immediately. The table persists to .bb-data/ on disk (survives restarts). The API serves on localhost with hot reload. Your frontend imports the backend directly with full type safety — no codegen, no REST clients, no OpenAPI specs:

import { api } from 'aws-blocks';

const result = await api.addTask('user123', 'Write blog post');
// TypeScript knows the return type. Change the backend signature,
// and the frontend breaks at compile time. No contract drift.

Add a method to the API, and it shows up in frontend autocomplete instantly. Change a return type in the backend, and TypeScript breaks the frontend at compile time itself. No more developer excuses like "the API changed but nobody updated the client."

When the feature is ready, run npm run sandbox and the same code deploys as DynamoDB, API Gateway, and Lambda. You did not configure IAM policies, write CloudFormation, or think about capacity modes. The building block provisions itself.

And when you outgrow what a Block provides? Every AWS Blocks app is a CDK app. Drop into aws-blocks/index.cdk.ts and use any CDK construct directly. You're never stuck in an abstraction.

What changes for teams

A new developer clones the repository, runs npm run dev, and has a working application in thirty seconds without ever needing an AWS account. They build and test features for days or weeks against local mocks that behave identically to production services. The CI pipeline runs integration tests against the same typed API imports — no browser required, no sandbox credentials to manage, no access keys to rotate.

When a feature passes review, one deploy command creates real infrastructure. The team goes from "works on my machine" to "running on AWS" without changing a single line of application code, because there was never a separate infrastructure layer that could drift out of sync.

For organizations where AWS environment access is controlled, gated, or simply slow to provision, this is the difference between developers waiting and developers shipping.

What you can build

Twenty building blocks covering data, identity, communication, compute, storage, AI, and observability. Each runs locally with zero configuration and deploys to production AWS services:

Plus KVStore for simple key-value, AuthBasic for JWT auth, AuthOIDC for social login, AppSetting for config/secrets, Dashboard for auto-generated observability views, and Hosting for frontend deployment (CloudFront + S3 with SSR support).

It works on every major web framework — Next.js, Nuxt, Astro, SolidStart, TanStack Start, React, Vue, Svelte, Angular — and generates typed native clients for iOS (Swift), Android (Kotlin), and Flutter (Dart) from the same backend definition.

Teaching your AI agent a new framework

AWS Blocks ships steering files inside the npm package that guide AI coding agents to build correct code. These work with any agent that reads node_modules documentation.

A Custom Kiro Power takes this further. It packages all twenty building block APIs, their constructor signatures, common pitfalls, deployment workflows, and scaffolding automation into a context bundle that activates dynamically when you mention "blocks" or "building blocks" in conversation. The agent doesn't need to dig through node_modules — it already knows the patterns.

Here is what that looks like in practice. You open Kiro, point it at an empty directory, and say:

"Create a bookmark manager with AWS Blocks where users can save links, tag them, and search by tag or date added"

The Power activates. The agent scaffolds the project with --yes (non-interactive), defines a DistributedTable with a schema for bookmarks, adds a byTag index and a byDate index, exports an ApiNamespace with CRUD methods plus tag-based queries, wires up AuthBasic for user isolation, and starts the dev server. Working app, running locally, in under a minute.

"Use building blocks to create a file sharing app with upload, download links, and automatic cleanup of expired files"

It uses FileBucket for presigned upload/download URLs, DistributedTable to track file metadata and expiry, CronJob to sweep expired files daily, and AuthOIDC with Google sign-in for user identity.

Without the Power, the agent would need to find and read each block's README from node_modules. With the Power, it builds complete applications from a single sentence because all the patterns, gotchas, and deployment knowledge are pre-loaded.

From local to production in two commands

AWS Blocks gives you two deployment paths:

Sandbox — fast, ephemeral, backend-only. Deploys in seconds using Lambda hot-swapping. Each developer gets an isolated environment. Use this during development to test against real AWS services.

npm run sandbox          # deploy backend to AWS (seconds)
npm run sandbox:destroy  # tear it down

Production — full CDK deployment via CloudFormation. Deploys your entire application including frontend hosting (CloudFront + S3), SSR if you use Next.js/Nuxt/Astro, custom domains, and WAF. Use this for staging and production environments.

npm run deploy   # full production deployment
npm run destroy  # tears down all deployed resources

The same code that ran on localhost:3000 is now running on AWS with DynamoDB tables, Lambda functions, API Gateway endpoints, and a CloudFront distribution. No infrastructure files were written. No IAM policies were hand-crafted. The building blocks provisioned themselves.

Install Custom Kiro Power for AWS Blocks

Kiro IDE: Powers panel > Add Custom Power > Import from GitHub > https://github.com/awsdataarchitect/aws-blocks

The Custom Kiro Power is at github.com/awsdataarchitect/aws-blocks for anyone who wants to go from plain English to a running AWS Blocks app without reading docs first.

Or Try it Manually

If you want to scaffold manually without a Power or any AI steering:

npm create @aws-blocks/blocks-app@latest my-app
cd my-app
npm run dev

Working application in seconds, deployable to AWS with npm run sandbox when you are ready. Full production deployment with hosting via npm run deploy. Tear it down via npm run destroy.

Links:

• Official Documentation
• npm package
• Source (GitHub)
• Custom Kiro Power for AWS Blocks

Now, what will you build with AWS Blocks?