5 Kiro Workflows for Better IaC Development

When it comes to generating Terraform modules, creating documentation, or even automating testing, AI-powered tools have become a natural part of the developer workflow. But using them effectively for Infrastructure as Code requires more than just prompting. It requires structure.

In this article, we’ll walk through five practical tools and workflows integrating Kiro into everyday IaC development. Whether you’re setting up a new project from scratch, generating OpenTofu modules, or enforcing naming conventions across a multi-account landing zone, these patterns will help you get more out of Kiro while keeping your IaC clean, well-documented, and maintainable.

Reviewing the basic concepts

Kiro is an AI-powered IDE built by AWS that goes beyond simple code generation. With features like steering files, hooks, specs, and skills, it gives you a framework to set up custom conventions, automate repetitive tasks, and maintain consistency across your infrastructure codebase.

Before diving into the workflows, let’s review the key Kiro concepts we’ll be using throughout this article.

In addition to the tips described in this article, we use this public skill with the AWS API and Terragrunt Docs MCP servers.

Tip 1: Setting up a project skeleton

Starting a new IaC project usually means copying the same set of boilerplate files, folder structure, root configs, CI pipelines, pre-commit hooks, and tool definitions. It’s not complex work, but it’s tedious and easy to get wrong when done manually.

To solve this, we use a user-level steering file. User-level steering lives in ~/.kiro/steering/ and applies across all workspaces, not just a single project. Ours includes instructions that direct Kiro to a local template folder containing our standard project skeleton.

When we open a fresh workspace and ask Kiro to set up the project, it reads the steering file, copies the relevant files from our template directory, and scaffolds everything in place. Folder layout, mise.toml, root.hcl, project.hcl, GitHub Actions workflows, pre-commit config, all landed in one go, following conventions from the start.

The benefit here is consistency. Every new project starts from the same foundation, and we never have to remember which files to copy or which values to update. If our template evolves, we update it in one place and every future project picks it up automatically.

Tip 2: Generating Opentofu modules

Most of the time, when setting up new infrastructure for a project, we like to use already existing, well-tested public modules. In that way, we don’t have to develop and maintain modules, and we can rely on solutions that have already been proven in production environments.

There are some exceptions, though, where we need heavy customization and a special set of resources. In these cases, we add a custom module to our stack. Generating Opentofu modules is a fairly straightforward and repetitive task, making it an ideal candidate for AI assistance, so instead of manually creating the module structure, variables, outputs, documentation, and tests, we can use Kiro to automate much of the boilerplate and focus on the implementation details that are specific to our use case.

To make this workflow more reliable, we set up two components:

1. A Kiro steering file containing all conventions

Although the public skill we use already includes a set of best practices for developing Infrastructure as Code (IaC), we also maintain a dedicated steering file that defines our organization’s specific requirements and conventions. This ensures that all generated code adheres not only to general IaC best practices but also to our internal standards, naming conventions, and architectural guidelines. By combining skills with project-specific steering files, we can achieve both consistency and flexibility across our infrastructure codebase.

2. A Kiro hook that can be used to start the workflow quickly

This custom hook is configured to run only when triggered manually. Rather than containing a lengthy, detailed prompt, it references the conventions defined in our Steering Files. This approach makes the hook easier to maintain, as updates to coding standards or project requirements only need to be made in a single location. It also helps ensure that all checks remain aligned with the latest conventions without having to modify the hook itself.

Kiro steering:

Kiro hook:

Tip 3: Creating conventions

As a project grows, keeping conventions consistent becomes harder. With Kiro, we can also encode our conventions directly into steering files. Kiro can even analyze an existing codebase and extract the appropriate conventions. It looks at the patterns already in use, like variable naming, tag structures, and module layout, and produces a markdown document that captures them as rules.

Here are some good snippets as examples:

Steering file for project structure:

Steering file for Terragrunt conventions:

Tip 4: Checking for best practices

In the past, our checks were usually handled by external tools, like checkov or tfsec. We did not quit using them, of course. They are reliable tools to use locally as well as in workflows. But now we also utilize Kiro’s capabilities. We built hooks that trigger on file save. Whenever we edit an OpenTofu or Terragrunt file, the hook asks the agent to review the changes against known best practices. This includes things like:

• Missing encryption configuration on storage resources
• Overly permissive IAM policies
• Resources without proper tagging
• Security groups with wide-open ingress rules
• Missing lifecycle policies or backup configurations

The hooks use an askAgent action with a prompt referencing our steering files and the Terraform skill. It’s not a replacement for a proper security scanner in CI, but it catches the obvious mistakes early and keeps us from committing code that we’d have to fix later.

Here’s a simple example to get started. This hook automatically reviews files against best practices whenever they are saved:

We wouldn’t recommend using it as-is during active development, since the fact that it triggers on every save can make it consume a significant number of tokens.

Tip 5: Writing documentation

Documentation is the first thing to fall behind when infrastructure evolves quickly. Module READMEs go stale, variable descriptions get outdated, and architectural decisions live only in someone’s head.

We use Kiro to keep documentation in sync with the code by combining two approaches:

1. First a hook that triggers when module files change. Whenever main.tf, variables.tf, or outputs.tf is modified, the hook runs terraform-docs to regenerate the module’s README automatically. This ensures that variable descriptions, types, defaults, and outputs are always up to date without manual effort.

2. Second, for higher-level documentation, we use the agent directly. After implementing a significant change, we ask Kiro to document what was done and why. Because it has the full context of the codebase through steering files and the files it just modified, the documentation it produces is accurate and specific rather than generic boilerplate.

The combination means our docs stay current at both levels: the mechanical reference documentation (generated automatically) and the human-readable explanations (written with context). Neither requires us to context-switch away from the actual infrastructure work.

Are you interested in this topic? Do you have any questions about the article? Book a free consultation and let’s see how the Code Factory team can help you, or take a look at our services!