From Infrastructure as Code to Infrastructure as Intent: How GenAI is reshaping the way we build
The way we build cloud infrastructure is changing. For years, IaC gave us repeatability, governance, and speed through templating. However, in the era of GenAI, we must adopt a new paradigm: describing what you want rather than defining it. This post explores that shift - from IaC templates to Infrastructure as Intent (IaI). But LLMs are probabilistic, this probability poses governance risks. To solve this, we can use Kiro Steering to encode organizational standards and OPA to validate AI output.
The Golden Age of IaC Templates
For years, our team lived and breathed Infrastructure as Code. CloudFormation stacks and Terraform modules were the backbone of how we delivered cloud infrastructure to our customers. Depending on the customer context, we'd choose one or the other: CloudFormation for AWS-native shops that wanted tight service integration, Terraform for organizations running multi-cloud or with an existing HashiCorp investment.
The model was elegant in its simplicity:
- When a customer asked for a piece of AWS infrastructure, we'd evaluate whether it had reuse potential - could this pattern serve future customers or projects ? If yes, we invest in turning it into a proper, well-architected template.
- That template would encode best practices: proper IAM boundaries, encryption at rest, VPC segmentation, tagging conventions, etc
- The rest of the organization would consume those templates, stamping out consistent, compliant infrastructure in minutes rather than days. It worked. It scaled. And for a long time, it was enough.
But the landscape started shifting ! The rise of large language models capable of generating production-quality infrastructure code forced us to ask a fundamental question: if an AI can write a CloudFormation template from a description, what is the role of a pre-built template library today ? The shift toward Infrastructure as Intent is a natural, almost inevitable evolution of Infrastructure as Code itself, driven by the emergence of LLMs as credible engineering tools.
Enter in the GenAI Era: Infrastructure as Intent
The rise of large language models capable of writing production-quality IaC has fundamentally changed the equation. Instead of maintaining a library of templates, we can now describe what we want - our intent - and let an LLM to generate the infrastructure definition that realizes it. This is what we call Infrastructure as Intent (IaI).
Rather than writing:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Resources:
DataBucket:
Type: 'AWS::S3::Bucket'
Properties:
BucketName:
VersioningConfiguration:
Status: Enabled
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "aws:kms"
Tags:
- Key: "CostCenter"
Value: !Ref CostCenter
- Key: "Environment"
Value: "Production"We express the intent:
"Create an S3 bucket for our data lake in production. It must be private, versioned, encrypted with a customer-managed KMS key. Apply our standard cost allocation tags."
The LLM translates that intent into a complete, deployable IaC artifact - using the latest AWS APIs, resource properties, and recommended patterns.
The Undeniable Pros of Infrastructure as Intent
Drop the cost of templating
In a consulting organization, infrastructure templating is the engine of efficiency and quality. It allows us to accelerate customer onboarding by injecting years of hard-won experience and best practices into every new project. Reuse sounds simple in principle, but producing a truly customer-agnostic template requires deliberate extra effort. A module built for one customer encodes their assumptions. Stripping those out, abstracting the right variables, and making the template genuinely reusable across different customers is work that goes beyond the original delivery. And the problem compounds with scale. The more customers you serve, the more experience you accumulate - new edge cases solved, new architectural patterns validated, new compliance requirements handled. All of that knowledge wants to flow back into the template library. As a result, teams must dedicate significant energy to produce and maintain the library.
With Infrastructure as Intent, the dynamic changes. There is no customer-agnostic template to manage, there is no template to fork and readapt. The intent is expressed fresh for each customer, getting infrastructure tailored to their context - without the overhead of abstracting and versioning a shared module. The result: onboarding a new customer from first conversation to deployed, compliant infrastructure compresses significantly. The engineers focus on understanding the customer need, not on generalizing or adapting templates.
Always Up to Date with the Latest AWS Features
When AWS launches a new capability, traditional IaC libraries often fall behind, forcing engineers to manually study documentation and update modules. This creates technical debt and version drift across the repository - where some templates are modernized while others no. Consequently, this inconsistency increases friction and evaluation fatigue when teams attempt to reuse existing modules.
With Infrastructure as Intent, the LLM already knows about these features (assuming access to documentation via AWS MCP Server ). Ask for an S3 bucket with latest features and you get the latest feature not a 2024 era one. The result: our engineering teams stopped to manually search for the new AWS features before reuse templates, they now simply describe customer requirements.
The Honest Cons: Standardization Is the Hard Problem
Infrastructure as Intent introduces a challenge that IaC templates largely solved by design: standardization. LLMs are probabilistic. Ask to the same model the same question twice, and you might get two slightly different CloudFormation templates. The S3 bucket in one might use
aws:kms encryption while another uses aws:s3 SSE. The naming convention for the IAM role might differ. The tagging structure might vary. In a large organization, this probabilistic variability it's a compliance risk, an operational burden, and a security exposure. This is the central challenge of Infrastructure as Intent: how do you get the benefits of AI-generated infrastructure without sacrificing consistency, governance, and security ? Our actual answer is a two-phases solution.Our Two-Phases Approach: generate then validate
Working with AI to generate infrastructure immediately surfaces two problems: AI models have no memory of your standards and LLM outputs are always different.
Every time an engineer started a new conversation, the model starts from zero. To get output that fits your organization - correct naming, right tagging, approved network patterns, security defaults - the engineer has to explain all of it upfront, every time. We started to manage this with prompt engineering. We wrote shared prompt templates, documented conventions, trained the team on how to frame their intent. The output improved, but the approach had a structural flaw: it placed the entire burden on each individual engineer, in each individual conversation. What we needed was a way to make the AI permanently aware of in place standards, without relying on engineers to remember to include them.
That is exactly what Kiro Steering solves.
Even with Kiro Steering in place, a second problem remains. LLMs are probabilistic by nature: they do not produce deterministic output. The same intent, expressed slightly differently, can generate a different infrastructure template. The components are likely the same - the right services, the right resource types - but their configuration can silently vary. This is not a failure of prompting or of Steering - it is a fundamental property of how language models work. In a consulting organization operating across multiple customers and regulated environments, this is not an acceptable property for infrastructure generation. We needed something structurally stronger than a prompt, we needed a validation layer that sits after generation and enforces compliance independently of how the template was produced.
That is what OPA (Open Policy Agent) solves.
Together, these two layers close the loop: Kiro Steering ensures the AI always generates within organizational context; Policy as Code ensures the output never exits the pipeline without meeting your compliance requirements.
Layer 1 - Kiro Steering: Encoding Organizational DNA into the AI
Kiro is an AI-powered development environment built for agentic engineering workflows. Kiro supports a feature called Steering. A steering allows you to define persistent, authoritative guidance documents that the AI always has in context when generating code or infrastructure. Think of it as the institutional memory of your engineering organization, embedded directly into the model's generation process.
Kiro permits to create Steering files with a workspace scope or a global scope. This permitted us to mirroring the way our team works: some rules apply everywhere, some rules apply only to a specific project.
Global Steering — Organization layer
At the top of the hierarchy sits our organization-wide Steering configuration. This is maintained centrally by our platform team and applies to every project, every engineer, every customer engagement. It encodes the things that never change regardless of context: our company-wide security posture, our cost allocation tagging taxonomy, and the architectural principles that apply across all workloads. No engineer needs to think about this layer. It is always active.
Workspace Steering — Project layer
Below the organization layer sits the project-specific Steering configuration, defined per Kiro workspace. This is where customer-specific context lives: the customer's environment structure, their security requirements, the specific AWS services in scope for that engagement, etc. When a new project is onboarded, the first thing we do is define its Workspace Steering giving Kiro a complete picture of the project before a single line of infrastructure is generated. Here is where we put some extra effort to try to classify every kind of project delivered - for example healthcare project - to define a preconfigured steering file where engineer can start for future similar work.
The new Workflow
On the engineer's side, this creates a streamlined and repeatable workflow. When a new project is onboarded, the engineer inherits the organization's Global Steering automatically — it is always there, requiring no action. For the Workspace Steering, rather than starting from scratch, the engineer picks the steering files from the most similar existing project as a baseline. If the new engagement is in the healthcare space, the healthcare project's steering is the starting point: data residency rules, compliance constraints, approved service patterns are already encoded. What needs customization gets customized. What doesn't is inherited as-is. This has quietly changed how we think about reuse in our organization. We no longer version CloudFormation templates or Terraform modules as the primary unit of institutional knowledge. We version our Steering files. A template is ephemeral - generated fresh each time from intent. A Steering file is the asset. It captures the decisions, the standards, the hard-won lessons from every project that came before it.
Layer 2 — OPA Policy: The Requirements that LLM Cannot Guarantee
Open Policy Agent (OPA) is a general-purpose, open-source policy engine maintained by the CNCF. You express your policies in Rego, OPA's declarative query language, and OPA evaluates any structured input - JSON or YAML - against those policies and returns a decision. OPA is also designed to integrate anywhere in a pipeline by is CLI.
Rego Policy - Requirements as Code
Just as Kiro Steering solves the problem of context surviving conversations, our Rego policy library solves the problem of compliance requirements surviving across projects. And we approached it with the same design principle: a layered, reusable structure organized by concern. The library is the primary mechanism through which our engineers guarantee that LLM-generated output meets organizational and customer-specific standards. It is not a monolithic set of rules — it is a structured collection of policy bundles, organized by market segment and compliance domain, that engineers inherit and customize for each engagement.
Just as Kiro Steering solves the problem of context surviving conversations, our Rego policy library solves the problem of compliance requirements surviving across projects. And we approached it with the same design principle: a layered, reusable structure organized by concern. The library is the primary mechanism through which our engineers guarantee that LLM-generated output meets organizational and customer-specific standards. It is not a monolithic set of rules — it is a structured collection of policy bundles, organized by market segment and compliance domain, that engineers inherit and customize for each engagement.
Here an example of OPA policy, written in Rego that deny S3 buckets without KMS encryption
1
2
3
4
5
6
7
8
# Rule to check if S3 encryption is enabled and correctly configured to use aws:kms
encryption_enabled {
resource := input.Resources[]
resource.Type == "AWS::S3::Bucket"
encryption := resource.Properties.BucketEncryption.ServerSideEncryptionConfiguration[]
encryption.ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
is_non_empty(encryption.ServerSideEncryptionByDefault.KMSMasterKeyID)
}CI/CD - How OPA integrates in our IaI flow
When Kiro generates an IaC artifact, it is immediately passed to our validation pipeline before any human review or deployment step. The flow looks like this: LLM generates a CloudFormation or Terraform artifact from the developer's intent. The artifact is converted to a structured JSON representation (Terraform plan JSON, or CloudFormation template parsed as JSON) then evaluated against our OPA policy bundle. OPA evaluates each policy rule and returns a list of violations, if all policies pass, the artifact proceeds to the pipeline; if any fail, the developer receives a structured report of exactly which rules were violated and why.
When Kiro generates an IaC artifact, it is immediately passed to our validation pipeline before any human review or deployment step. The flow looks like this: LLM generates a CloudFormation or Terraform artifact from the developer's intent. The artifact is converted to a structured JSON representation (Terraform plan JSON, or CloudFormation template parsed as JSON) then evaluated against our OPA policy bundle. OPA evaluates each policy rule and returns a list of violations, if all policies pass, the artifact proceeds to the pipeline; if any fail, the developer receives a structured report of exactly which rules were violated and why.
These policies are version-controlled alongside our Steering files, reviewed through pull requests, and deployed to every project's pipeline automatically. When a new compliance requirement emerges - a new regulation, a new customer security mandate - we add a policy, merge it, and every future generation is immediately subject to it.
Conclusions
Infrastructure as Intent changes the way engineers work - not what they are responsible for. The craft does not disappear. Understanding architecture, evaluating trade-offs, designing for resilience and cost efficiency, knowing when a generated template is subtly wrong - these remain deeply human skills. What changes is the layer where engineers spend their time. Instead of authoring HCL or YAML, they express intent. Instead of maintaining a template library, they maintain Steering files and policy bundles. The shift is from writing infrastructure to writing security and compliance checks - the Rego policies, the cfn-guard rules, the Steering constraints that define what correct infrastructure looks like. The AI produces the artifact. The engineer defines and enforces the standard it must meet.
The two-layer governance model that I Introduced here - Kiro Steering for standardization and Open Policy Agent for verification - is what we are trying to do in the last six months to guarantee compliance in the IaI era. Steering encodes your organizational DNA into every generation. OPA provides the deterministic safety net that transforms probabilistic AI output into trustworthy infrastructure.
One evolution we are actively evaluating is the shift from OPA and Rego to Cedar - Amazon's open-source policy language based on Automated Reasoning. It is not a replacement we are ready to commit to today, but it is one we are watching closely and prototyping against our existing policy library with goals to enforce guardrail leveraging the concept of Provable Security (mathematically proof).
The future of cloud delivery is not templates. It's intent - governed, validated, and continuously improved. If you're still maintaining a library of aging IaC templates, I encourage you to experiment with this approach. Start small: pick a workload, write your first Steering document, inherit the closest policy bundle, and let the AI generate the infrastructure.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article