Kiro is a development tool, not an application hosting platform or an AWS runtime service. Engineers use it to work with source code, develop features, investigate problems, and prepare applications for deployment. Applications created with Kiro can run on AWS or other platforms; their runtime architecture, permissions, availability, and operating costs remain separate engineering responsibilities.
A central workflow in Kiro is specification-driven development. An engineer describes a feature, then develops requirements, a technical design, and an implementation task plan with the agent. Project specifications are stored as Markdown files, commonly under the .kiro/specs directory. Keeping these artifacts in version control lets reviewers evaluate intended behavior and technical decisions alongside the implementation. Specifications are useful planning artifacts, but they do not replace acceptance tests or prove that generated code satisfies a requirement.
Kiro also supports direct conversational development when a formal specification is unnecessary. Engineers can ask the agent to explain code, investigate a failing test, or implement a focused change. Review generated changes as ordinary code contributions: inspect the diff, run relevant tests, validate dependencies, and check security-sensitive behavior. For larger changes, smaller implementation tasks make it easier to identify regressions and preserve review quality.
Steering files provide reusable project guidance, such as repository structure, preferred libraries, coding conventions, and testing expectations. Agent hooks associate development events with repeatable agent actions, such as checking whether a code change needs corresponding tests or documentation. These mechanisms help apply team conventions, but deterministic checks should still run in continuous integration. An agent instruction is not an enforcement boundary.
Kiro can connect to external tools through Model Context Protocol servers. Such servers can expose documentation lookup, repository operations, or cloud management capabilities, depending on their implementation and configuration. Treat each server as an additional software dependency and trust boundary. Review its provenance, restrict credentials, and understand whether exposed tools only read information or can change infrastructure and data.
For AWS projects, a practical setup combines Kiro with infrastructure-as-code files, automated tests, and established deployment pipelines. The agent can help edit AWS CDK, AWS SAM, Terraform, or CloudFormation definitions, while existing command-line tools and pipelines perform validation and deployment. Use short-lived credentials, separate development and production roles, and require approval for consequential operations. Keep secrets out of prompts, specifications, source files, and tool output wherever possible.
Kiro does not automatically configure production monitoring, data protection, or application access control. Engineers must explicitly design these controls and verify the resulting infrastructure. Track Kiro subscription usage separately from charges for deployed AWS resources, build jobs, model endpoints, or third-party tools used during development.