Post Syndicated from Malini Chatterjee original https://aws.amazon.com/blogs/compute/streamline-your-infrastructure-automating-ami-creation-with-kiro-cli-and-ec2-image-builder/
Managing infrastructure at scale requires robust automation tools that reduce manual effort while maintaining consistency and security. The combination of Kiro CLI and AWS EC2 Image Builder offers a powerful solution for automating the creation, testing, and deployment of Amazon Machine Images (AMIs).
The challenge of manual image management
Traditional approaches of creating and maintaining AMIs often involve manual processes that are time-consuming, error-prone, and difficult to scale. Teams struggle with:
- Inconsistent configurations across development, testing, and production environments
- Security vulnerabilities from outdated base images and missing patches
- Compliance gaps due to manual validation processes
- Slow deployment cycles caused by repetitive manual tasks
With EC2 Image Builder and Kiro CLI, teams can replace these manual workflows with automated, and secure AMI pipelines. EC2 Image Builder provides the fully managed automation engine, while Kiro CLI brings AI-powered assistance to help you build, iterate, and troubleshoot those pipelines faster — using natural language.
EC2 Image Builder
EC2 Image Builder is a fully managed AWS service that simplifies the creation, maintenance, and deployment of customized, secure, and up-to-date server images. The service provides the following key capabilities:
- Automated build pipelines: Define your image configuration once, automatically build images on a schedule or trigger basis, and manage the lifecycle of the AMI. Image Builder handles the entire lifecycle of custom AMI creation, testing, distributing and managing the lifecycle of the AMIs.
- Built-in security: Automatically apply the latest security patches and validate images against AWS security best practices. EC2 Image Builder can enforce security with every created AMI using update-linux/update-windows components patch OS vulnerabilities at build time, IMDSv2 can be enforced at the pipeline level, and Amazon Inspector validates CVE posture before image distribution — all automated, no manual intervention
- Testing and validation: Run automated tests to verify your images meet functional and security requirements before deployment. This ensures only validated images reach production environments.
- Multi-region distribution: Automatically distribute your AMIs across multiple AWS regions and share them with specific AWS accounts, streamlining deployment across complex organizational structures.
Kiro CLI: AI-powered infrastructure automation
Kiro CLI brings generative AI capabilities directly to your terminal, enabling natural language interactions with AWS services. This AI-powered command-line interface transforms how developers and operators interact with infrastructure automation tools.
What makes Kiro CLI powerful
- Natural language commands: Instead of memorizing complex CLI syntax or hand-authoring CloudFormation templates, simply describe what you want to accomplish. Kiro CLI interprets your intent and generates Infrastructure as Code — such as CloudFormation or CDK — that you can review, version-control, and deploy through your existing CI/CD pipelines. For quick, non-destructive exploration (e.g., listing resources or describing configurations), Kiro can also execute AWS API calls directly.
- Context-aware assistance: Kiro understands your AWS environment and provides intelligent suggestions based on your current context, resources, and best practices. You can connect Kiro CLI to remote tools and systems via Model Context Protocol (MCP), for example, you can connect to AWS MCP servers for and documentation and troubleshooting assistance.
- Workflow automation: Chain multiple operations together using conversational commands, reducing the cognitive load of managing complex infrastructure tasks.
- Integration with AWS services: Seamlessly interact with EC2 Image Builder, Systems Manager, and other AWS services without switching between different tools or interfaces.
The synergy: Kiro CLI + EC2 Image Builder, automated pipeline creation
When combined, these tools create a streamlined workflow infrastructure automation:
- Faster onboarding: Seamless AMI creation and faster maintenance with Kiro CLI. Rather than switching between the AWS Console and AWS CloudFormation documentation during initial exploration, Kiro CLI lets you describe your requirements conversationally — giving you a fast path to a working pipeline that you can then manage and refine through the Console or CloudFormation as your production needs mature.
- Improved security posture: Automated patching and compliance validation built into every image. Describe your patching requirements conversationally, and Kiro CLI includes the appropriate build components that apply OS-level patches, kernel updates, and CVE fixes directly into the AMI at build time.
- Consistent deployments: Version-controlled AMI pipelines that produce identical, pre-tested images promoted across dev, staging, and production without manual changes. EC2 Image Builder ensures every build follows the same recipe, components, and validation steps.
- Reduced operational overhead: Eliminates manual, repetitive tasks around image creation, distribution, and lifecycle management accelerating iteration cycles for pipeline builds.
- Faster troubleshooting: Kiro CLI parses error output and explains root cause in plain language, cutting the time spent deciphering CloudFormation stack traces and Image Builder build logs.
Getting started
Before implementing this solution, ensure you have the pre-requisites:
- Kiro CLI installed (installation guide: for Linux, macOS or Windows) and configured.
- Configure the AWS Documentation MCP server , refer the detailed steps here.
- AWS account with access permissions for the following services:
- EC2 Image Builder
- IAM (for role creation and policy attachment)
- EC2 (for AMI management)
- Systems Manager
- VPC (for network configuration)
- An existing VPC with public/private subnets configured
To begin automating your infrastructure using Kiro-CLI, here are some sample prompts that you can use as a baseline:
Example 1: Amazon Linux for EKS nodes
Use case: Teams running Kubernetes on Amazon EKS need custom node AMIs that include the correct container runtime, kubelet version, and security hardening — and that stay current with weekly base image updates. This prompt automates that pipeline and keeps your EKS node groups up to date automatically.
Prompt:
Create a production-ready EC2 Image Builder pipeline using a direct APIs
for custom EKS-optimized Amazon Linux 2023 AMIs with the following requirements:
- Weekly automated builds triggered by base AMI updates
- AWS managed components for container runtime, kubelet and CloudWatch agent
- Automatic launch template updates for EKS managed node groups
What Kiro CLI generates:
Kiro CLI produces the API calls and supporting configuration to set up:
- An EC2 Image Builder pipeline with a weekly schedule and base AMI change detection
- Image recipe based on the EKS-optimized Amazon Linux 2023 AMI
- Component definitions for container runtime (containerd), kubelet, and CloudWatch Agent
- Automation to update EKS managed node group launch templates with the new AMI ID after each build
- If we use a short prompt, Kiro will pick the default values, which customer can definitely change/edit accordingly. However, if we want to be more presriptive, then one can follow a detailed prompt like Example 2 below.
Example 2: Windows server golden image
Use case: Enterprise teams running Windows-based workloads often need a standardized, hardened base image that meets compliance requirements (such as CIS benchmarks) and includes approved software. Manually maintaining this image is error-prone and time-consuming. This prompt automates the full pipeline — from build to distribution.
Prompt:
Create a production-ready EC2 Image Builder pipeline for a Windows Server 2025
golden image as a single CloudFormation template:
- Monthly automated builds via cron schedule
- Using latest public Windows Server 2025 AMI from AWS
- Components: AWS-managed CloudWatch Agent, AWS CLI, Windows Updates
- Apply AWS-managed STIG components (stig-build-windows) for build-time hardening
and corresponding stig-validate-windows for validation.
- For the EC2 instance profile role, use only these AWS-managed policies:
EC2InstanceProfileForImageBuilder, EC2InstanceProfileForImageBuilderECRContainerBuilds,
and AmazonSSMManagedInstanceCore. Do NOT use any policy containing "FullAccess".
- Create a KMS multi-region primary key (MRK) in the pipeline region for AMI
encryption, with a key policy granting cross-account access to
[ACCOUNT_1, ACCOUNT_2, ACCOUNT_3] for kms:CreateGrant, kms:DescribeKey,
and kms:Decrypt. Include a KMS alias. Output the key ARN for replica
creation in target regions.
- Amazon Inspector vulnerability scanning
- Single pipeline deployed in one region. Use EC2 Image Builder
DistributionConfiguration to share the output AMI to accounts
[ACCOUNT_1, ACCOUNT_2, ACCOUNT_3] in regions us-east-1 and us-west-2.
Do NOT create separate pipelines or stacks per region.
- In the DistributionConfiguration, use AmiDistributionConfiguration's
built-in SsmParameterConfigurations to write the output AMI ID to
/golden-image/windows-server-2025/latest in each distribution region.
Do NOT use Lambda functions or custom resources for SSM parameter updates.
- Create an SNS topic for build notifications. Use the
InfrastructureConfiguration's built-in SnsTopicArn property for pipeline
status notifications. Do NOT create EventBridge rules for notifications.
- Lifecycle policy: Disable AMIs after 180 days, delete after 360 days
- Least-privilege IAM roles for Image Builder, EC2 instance profile,
and lifecycle
- All resource names (KMS alias, IAM roles, SNS topics, Image Builder
components, recipes, pipelines, infrastructure configs, distribution
configs, lifecycle policies, EventBridge rules, and SSM parameter paths)
must include !Sub "${AWS::StackName}" or a parameterized prefix to ensure
uniqueness. This prevents conflicts if the template is deployed multiple
times in the same account/region.
- Use AWS-managed components where available
- Parameterize account IDs and regions
- Do NOT create multiple stacks or deploy resources in multiple regions
What Kiro CLI generates:
Kiro CLI interprets this prompt and produces a complete CloudFormation template that includes:
- An EC2 Image Builder pipeline with a monthly build schedule
- Image recipe referencing the latest Windows Server 2025 AMI from AWS Systems Manager public parameter
- AWS-managed components for CloudWatch Agent, AWS CLI, and Windows Updates
- STIG hardening build component with corresponding validation component
- KMS key and encryption settings applied to the output AMI
- Amazon Inspector integration for CVE scanning before distribution
- Distribution configuration targeting 3 AWS accounts across 2 regions
- Built-in SsmParameterConfigurations writing the AMI ID to /golden-image/windows-server-2025/latest in each distribution region
- SNS topic and subscriptions for build success/failure notifications
- Lifecycle policy: disable AMIs after 180 days, delete after 360 days
- Least-privilege IAM roles for Image Builder service, EC2 instance profile, and lifecycle management
Once the execution is complete, you can navigate to the EC2 Image Builder console. Once you are in the AWS Console EC2 Image Builder, you will be on the page for Image Pipelines. You will see in the screenshot below that the new pipeline is now Enabled.
Please note that the name of the pipeline will vary based on your specific inputs. This image is just a sample “enabled” pipeline looks like in EC2 Image Builder console.
Fig 1: Sample EC2 Image Builder console, after the pipeline is “enabled”.
For more examples and scenarios, you can check Infrastructure Automation with Kiro CLI and EC2 Image Builder workshop.
Cleanup
To avoid ongoing charges, remove all resources created during this walkthrough. The cleanup steps depend on which example you followed.
Example 1: Amazon Linux for EKS nodes cleanup
If you created resources via direct API calls, delete them in the following order:
- Disable and delete the Image Builder pipeline — this stops the weekly automated builds triggered by base AMI updates.
- Delete the image recipe based on the EKS-optimized Amazon Linux 2023 AMI.
- Delete the component definitions for container runtime (containerd), kubelet, and CloudWatch Agent.
- Delete the infrastructure configuration and distribution configuration.
- Revert your EKS managed node group launch templates to their previous AMI ID, or point them to a known-good image, before removing the custom AMIs.
- Deregister any AMIs produced by the pipeline and delete their associated EBS snapshots.
- Remove IAM roles and instance profiles created for Image Builder and the EC2 instance profile.
Example 2: Windows server golden image cleanup
If you deployed the CloudFormation template, navigate to the AWS CloudFormation console, select your stack, and choose Delete. This removes the pipeline, recipe, components, IAM roles, KMS resources, SNS topic, and lifecycle policy in a single operation.
After the stack is deleted, manually clean up these resources that CloudFormation does not remove:
- Deregister distributed AMIs — In each target account (ACCOUNT_1, ACCOUNT_2, ACCOUNT_3) and region (us-east-1, us-west-2), deregister the shared Windows Server 2025 AMIs and delete their associated EBS snapshots.
- Delete SSM parameters — Remove
/golden-image/windows-server-2025/latest in each distribution region where it was written by the SsmParameterConfigurations.
- Schedule KMS key deletion — If the multi-region primary key (MRK) was replicated to other regions, delete the replica keys first, then schedule deletion of the primary key. Revoke any cross-account grants issued to ACCOUNT_1, ACCOUNT_2, and ACCOUNT_3.
- Remove Amazon Inspector associations — If Inspector was enabled solely for this pipeline, disable it to avoid ongoing scanning charges.
- Verify lifecycle policy cleanup — Confirm that the lifecycle policy (disable after 180 days, delete after 360 days) was removed with the stack. If any AMIs were already marked for lifecycle action, manually deregister and delete them.
Please note that AMI de-registration and snapshot deletion must be performed in every account and region where images were distributed. Ensure receiving accounts also deregister their copies to stop incurring storage costs.
Conclusion
The combination of AI-powered tools like Kiro CLI with robust automation services like EC2 Image Builder represents the future of infrastructure management. Whether you’re managing dozens or thousands of instances, automating your AMI creation pipeline is no longer optional—it’s essential for maintaining security, consistency, and agility in modern cloud environments.
In this post, we highlighted the benefits of AI-assisted infrastructure management using Kiro CLI. You can start using the workshop Infrastructure Automation with Kiro CLI and EC2 Image Builder for detailed prompts for building production-ready golden AMI pipeline with minimal manual coding.
