Infrastructure as Code for the Agentic Cloud

How the infrastructure strategy changes when you move from an AWS-first agent platform to a genuinely multi-cloud architecture — and where SST, Terraform, CDK and the Agent Platform API fit.

Infrastructure as Code has traditionally been concerned with relatively predictable things: networks, compute, databases, queues, storage, identity and deployment pipelines.

Agentic systems change the shape of that infrastructure.

A production AI agent is not simply another process running in a container. It increasingly depends on an ecosystem of capabilities around it: model access, runtime isolation, memory, tool connectivity, workload identity, authorization policy, evaluation, tracing, guardrails and communication with other agents.

The major cloud providers are responding by building increasingly complete agent platforms.

AWS has Amazon Bedrock AgentCore. Microsoft has Foundry Agent Service. Google Cloud has Gemini Enterprise Agent Platform and Agent Runtime.

This raises an architectural question that is more significant than a simple Terraform-versus-CDK debate:

What should Infrastructure as Code look like when agents become a significant part of the application architecture?

My answer depends heavily on whether you are building primarily for one cloud or genuinely operating across several.

The core recommendation

If AWS is your strategic cloud, optimize for AWS. Use Terraform or OpenTofu for the enterprise foundation, and strongly consider SST as the developer-facing application and agent infrastructure layer, with CDK or native AWS mechanisms available where they provide clear advantages.

If AWS, Azure and Google Cloud are genuine deployment targets, move the abstraction upward. Terraform or OpenTofu becomes the enterprise infrastructure control plane, SST can remain a developer experience layer where it fits, and an Agent Platform API becomes the portable abstraction above the cloud-specific agent platforms.

Agents Change What We Mean by Infrastructure

A conventional cloud application might be described like this:

Application
    │
    ├── Compute
    ├── Database
    ├── Queue
    ├── Storage
    └── Observability

A production agent increasingly looks like this:

Agent
  │
  ├── Runtime
  ├── Model
  ├── Memory
  ├── Tools
  ├── Identity
  ├── Authorization
  ├── Policy
  ├── Guardrails
  ├── Evaluation
  └── Observability

This means the infrastructure repository is increasingly part of the Agent SDLC.

Several different forms of as code begin to operate together:

Infrastructure as Code
        │
        ├── Runtime
        ├── Networking
        ├── Storage
        └── Compute

Identity as Code
        │
        ├── Workload identity
        ├── Service identity
        └── User delegation

Policy as Code
        │
        ├── IAM
        ├── Tool authorization
        └── Business constraints

Agent as Code
        │
        ├── Orchestration
        ├── Tools
        ├── Skills
        └── Multi-agent topology

Prompts as Code

Evaluation as Code

Observability as Code

Infrastructure is no longer just concerned with where the software runs.

It increasingly defines what an agent can see, what it can invoke, how it authenticates, what actions it may perform, how its behaviour is evaluated and how that behaviour is observed.

There Are Really Three Different Problems

One reason IaC discussions become confusing is that we often ask one tool to solve three different problems.

1. Enterprise Infrastructure Governance

   Accounts
   Landing zones
   Networks
   Security
   IAM foundations
   Central logging
   Policy
   Connectivity


2. Developer Infrastructure Experience

   Application infrastructure
   Local development
   Resource linking
   Environment management
   Deployment
   Product-level policies


3. Agent Platform Abstraction

   Agent runtime
   Models
   Tools
   Memory
   Identity
   Policy
   Evaluation
   Observability

These layers do not necessarily need the same technology.

That distinction is central to the architecture. Terraform may be the right enterprise infrastructure control plane while SST is the better developer infrastructure experience. Above both of them, an Agent Platform API may eventually become the abstraction product teams actually consume.

Scenario One: AWS Is Your Strategic Cloud

Assume AWS is overwhelmingly your primary cloud and you expect to build a significant number of agents using technologies such as Strands Agents and Amazon Bedrock AgentCore.

In this scenario I would not prematurely design a generic multi-cloud platform.

I would optimize for AWS.

But I would now consider a slightly different architecture from the traditional Terraform-plus-CDK model.

AWS Organizations
       │
AWS Control Tower
       │
Enterprise Landing Zone
       │
Terraform / OpenTofu
       │
       │ Enterprise foundation
       │
────────────────────────────────────
       │
      SST
       │
       │ Developer infrastructure experience
       │
Enterprise Components
       │
Agent Platform Components
       │
Amazon Bedrock AgentCore
       │
Strands Agents
       │
Amazon Bedrock

Why SST Is Interesting Here

SST has changed significantly from its earlier architecture.

SST v3 no longer sits on top of AWS CDK and CloudFormation. It uses a deployment engine based around Pulumi and Terraform providers.

That changes where SST fits architecturally.

sst.config.ts
      │
      ▼
SST Components
      │
      ▼
Pulumi deployment engine
      │
      ▼
Pulumi / Terraform providers
      │
      ▼
Cloud APIs

SST also supports a large provider ecosystem while providing richer, higher-level built-in components primarily around AWS and Cloudflare.

That means SST can combine two useful properties:

a strongly typed TypeScript infrastructure experience,
and access to the broader Terraform/Pulumi provider ecosystem.

For an engineering organization already comfortable with TypeScript, that is particularly attractive.

The AgentCore Terraform Story Has Also Improved

There is another reason the recommendation has shifted.

The official AWS Terraform provider now has broad first-class support across Amazon Bedrock AgentCore resources.

At the time of writing, the provider includes resources covering capabilities such as:

Agent Runtime

Runtime Endpoint

Gateway

Gateway Target

Memory

Memory Strategy

Policy

Policy Engine

Evaluator

Online Evaluation

Workload Identity

Browser

Code Interpreter

Registry

Resource Policies

Credential Providers

This weakens the argument that using AgentCore automatically implies using CDK.

CDK remains an excellent AWS-native tool.

But it is no longer the only compelling path for an AgentCore-heavy platform.

SST Can Become the Developer-Facing Agent Platform

The most interesting use of SST is not simply:

"Use SST instead of Terraform."

That is the wrong comparison.

A more useful model is:

Terraform / OpenTofu
        │
        │ Enterprise governance
        ▼
AWS Foundation


Developer
    │
    ▼
   SST
    │
    │ Product infrastructure
    ▼
Agent Platform Components
    │
    ▼
AgentCore

SST becomes the interface developers use for the application infrastructure they own.

The enterprise platform still owns the cloud foundation underneath it.

Build Enterprise Agent Components

I would not expect product teams to instantiate low-level AgentCore resources directly.

Instead, create an internal agent component library.

@company/platform

VpcService
SecureBucket
SecureQueue
ServiceApi
Database
EventConsumer


@company/agent-platform

EnterpriseAgent
AgentRuntime
AgentGateway
AgentTool
AgentMemory
AgentIdentity
AgentPolicy
AgentEvaluator

The desired developer experience should eventually look closer to this:

const agent = new EnterpriseAgent("AccountServicingAgent", {

  framework: "strands",

  runtime: {
    provider: "agentcore"
  },

  model: {
    capability: "reasoning-large"
  },

  tools: [
    accountQuery,
    payments,
    customerProfile
  ],

  memory: {
    enabled: true
  },

  policy: {
    profile: "customer-servicing"
  },

  evaluation: {
    profile: "production"
  },

  observability: {
    enabled: true
  }

});

The component could provision or configure:

EnterpriseAgent
      │
      ├── AgentCore Runtime
      ├── Runtime Endpoint
      ├── Gateway
      ├── Memory
      ├── Workload Identity
      ├── Policy Engine
      ├── Evaluators
      ├── IAM
      ├── Encryption
      ├── Logging
      └── OpenTelemetry

That is much more valuable than allowing each team to individually learn every underlying AgentCore resource.

SST Resource Linking Is Especially Useful

SST's resource-linking model fits agent applications particularly well.

Traditional infrastructure frequently leaks configuration into the application through environment variables:

PAYMENT_API_URL

MEMORY_TABLE_NAME

QUEUE_ARN

CUSTOMER_BUCKET_NAME

GATEWAY_ENDPOINT

MODEL_ENDPOINT

Over time that becomes fragile configuration plumbing.

SST allows resources defined in infrastructure to be linked into application code and accessed through its resource model.

Conceptually:

Resource.PaymentTool.url

Resource.AgentMemory.name

Resource.CustomerData.name

An enterprise agent SDK could take this further:

AgentResource.CustomerData

AgentResource.Payments

AgentResource.Memory

AgentResource.ToolGateway

AgentResource.Model

This starts looking less like raw IaC and more like an application platform.

The Inner Development Loop Matters

Agent development has a particularly demanding inner loop.

Developers need to iterate across:

Agent code

Prompts

Tools

MCP servers

Model calls

Memory

Policies

Evaluations

Telemetry

A productive development environment might look like:

sst dev
   │
   ├── Local Strands agent
   │
   ├── Local web application
   │
   ├── Local MCP tools
   │
   ├── Remote Bedrock models
   │
   ├── Remote AgentCore Memory
   │
   ├── Remote DynamoDB
   │
   └── Remote enterprise APIs

This is where SST has a different value proposition from traditional infrastructure tooling.

It is trying to improve the development experience around infrastructure, not just create the infrastructure.

Policy Packs Fit the Agent Platform Well

SST supports policy packs based on Pulumi Policy Packs and can apply those policies during development, diff and deployment.

That gives a central engineering platform a useful enforcement point.

Imagine an enterprise agent policy pack enforcing:

Enterprise Agent Policy Pack


Agent runtime must have dedicated identity

Privileged agents require a tool gateway

Wildcard IAM prohibited in production

Encryption required

OpenTelemetry required

Production agents require evaluations

Privileged tools require explicit policy

Public network exposure prohibited by default

Required enterprise tags must exist

Production retention policies required

Then:

Developer
    │
    ▼
sst deploy
    │
    ▼
Enterprise Policy Pack
    │
    ├── PASS ──────► Deploy
    │
    └── FAIL ──────► Reject

This is exactly the kind of guardrail needed as infrastructure creation increasingly becomes automated or agent-generated.

Treat the Agent Tool Boundary as Infrastructure

One of the most important differences between traditional applications and agents is the tool boundary.

An unsafe model is:

Agent
   │
   └──────────────► Enterprise Systems

      broad credentials

A better model is:

Agent
   │
   ▼
Tool Gateway
   │
   ├── Identity
   ├── Authorization
   ├── Policy
   ├── Audit
   └── Tool contracts
          │
          ▼
     Enterprise APIs

AgentCore Gateway can expose enterprise capabilities to agents as MCP-compatible tools.

AgentCore Policy adds deterministic authorization around those tool calls.

This matters because authorization should not depend on a system prompt.

You do not want this:

System prompt:

"Never approve a refund greater than $1,000."

to be your security architecture.

You want:

Agent
  │
  ▼
refund($20,000)
  │
  ▼
Policy Engine
  │
  ▼
amount <= $1,000 ?
  │
  └── NO ──────► DENY

The LLM decides what it would like to do.

Policy decides what it is allowed to do.

Evaluation Is Infrastructure Too

Traditional infrastructure deployment asks:

Did the infrastructure deploy successfully?

Agent infrastructure introduces another question:

Does the agent still behave correctly after this deployment?

A mature deployment process should increasingly look like:

Commit
   │
   ▼
Static analysis
   │
   ▼
Unit tests
   │
   ▼
Infrastructure diff
   │
   ▼
Infrastructure policy checks
   │
   ▼
Deploy ephemeral environment
   │
   ▼
Agent evaluations
   │
   ├── Task completion
   ├── Tool selection
   ├── Policy compliance
   ├── Safety
   ├── Regression
   └── Cost / latency
   │
   ▼
Deploy

Evaluation definitions therefore belong alongside infrastructure, policies and application code.

The AWS-First Architecture

Putting those ideas together gives an AWS-first architecture such as:

┌───────────────────────────────────────────────┐
│                Agent Products                 │
│                                               │
│        Strands / application code             │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│             Enterprise Agent SDK              │
│                                               │
│ Agent │ Tool │ Memory │ Policy │ Evaluation   │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│                     SST                       │
│                                               │
│ Developer experience                          │
│ Resource linking                              │
│ Product infrastructure                        │
│ Policy packs                                  │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│          Amazon Bedrock AgentCore             │
│                                               │
│ Runtime │ Gateway │ Memory │ Identity          │
│ Policy │ Evaluations │ Observability          │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│                    AWS                        │
│                                               │
│ Bedrock │ IAM │ KMS │ DynamoDB │ S3 │ SQS     │
│ Lambda │ EventBridge │ VPC │ CloudWatch       │
└───────────────────────────────────────────────┘

─────────────────────────────────────────────────

       Terraform / OpenTofu Enterprise Layer

─────────────────────────────────────────────────

Organizations │ Accounts │ Networks │ Security
DNS │ Landing Zones │ Logging │ Enterprise IAM

For AWS-first environments: Optimize for AWS. Do not hide AgentCore or AWS behind unnecessary portability abstractions. But consider SST as the developer-facing platform rather than forcing every product team to work directly with Terraform or CDK.

What Role Does CDK Still Have?

CDK remains highly relevant.

There will be cases where:

AWS releases a capability through CloudFormation/CDK before other providers.
An AWS service has particularly good CDK abstractions.
An existing internal construct library already provides significant value.
A team has deep operational experience with CDK.

Therefore I would not prohibit CDK.

I would treat it as an AWS-native implementation option rather than assuming it must be the application platform standard.

Enterprise Platform

Terraform / OpenTofu
        │
        ▼
AWS foundation


Product / Agent Layer

SST by default
        │
        ├── Terraform / Pulumi providers
        │
        └── AWS native integrations

CDK
        │
        └── used where justified

The Most Important Rule: One Owner per Resource

Mixing infrastructure technologies is not inherently a problem.

Mixing ownership is.

Bad:

Terraform creates IAM role

SST modifies IAM role

CDK modifies policy

AgentCore CLI modifies runtime

Engineer changes configuration manually

Good:

Terraform owns:

  AWS accounts
  landing zone
  VPC
  central DNS
  central security
  shared connectivity


SST owns:

  product API
  agent runtime
  product queues
  application database
  agent tools
  evaluators


CDK owns:

  only explicitly isolated AWS-native components

Infrastructure ownership boundaries are more important than infrastructure syntax.

Then Someone Says: “We Also Need Azure and GCP”

This changes the architecture.

Imagine AWS remains the dominant cloud, but Azure and Google Cloud are legitimate deployment targets.

There are many reasons this happens:

different business units have different cloud strategies,
particular models are stronger on one provider,
data residency requirements differ by geography,
acquisitions bring additional cloud estates,
commercial negotiations favour different providers,
or avoiding excessive dependency on one AI platform is itself strategic.

At this point the abstraction needs to move upward.

Do Not Build an Imaginary Generic Cloud

A common multi-cloud mistake is:

                  Generic Cloud
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼

         AWS          Azure         GCP
          │            │            │
          └───── all treated ───────┘
                identically

This usually produces a lowest-common-denominator platform.

The problem is even more obvious for agents because the cloud platforms provide different capabilities and different abstractions.

Capability	AWS	Azure	Google Cloud
Managed agent platform	Bedrock AgentCore	Foundry Agent Service	Gemini Enterprise Agent Platform
Runtime	AgentCore Runtime	Foundry Agent Runtime / Hosted Agents	Agent Runtime
Model platform	Bedrock	Foundry Models	Vertex AI / Model Garden
Identity	IAM / AgentCore Workload Identity	Microsoft Entra	IAM / Agent Identity
Tool integration	AgentCore Gateway / MCP	Foundry Toolboxes / MCP	Agent Gateway / MCP
Observability	CloudWatch / OpenTelemetry	Azure Monitor / Application Insights	Google Cloud Observability
Cloud-native IaC	CloudFormation / CDK	Bicep	Cloud APIs / Terraform ecosystem

These services are not identical.

And they should not be forced to appear identical.

Terraform or OpenTofu Becomes the Multi-Cloud Control Plane

Once infrastructure genuinely spans multiple clouds, Terraform or OpenTofu becomes much more attractive at the enterprise layer.

                 Enterprise Platform
                         │
                 Terraform / OpenTofu
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼

             AWS       Azure       GCP

              │          │          │

          AWS Modules Azure Modules GCP Modules

Terraform is not valuable here because it makes the clouds equivalent.

It is valuable because it gives the organization a common:

Lifecycle model

Planning model

State model

Module model

Policy model

Deployment workflow

Governance approach

Where Does SST Fit in Multi-Cloud?

SST becomes interesting in a different way.

SST supports a broad provider ecosystem, including providers beyond AWS.

But its first-class higher-level component experience is not symmetrical across AWS, Azure and GCP.

Its richest built-in component families are currently primarily AWS and Cloudflare oriented.

Its state "home" mechanism also currently has specific provider choices rather than behaving like a fully symmetrical three-cloud enterprise control plane.

So I would not make this claim:

SST = enterprise multi-cloud control plane

I would instead position it as:

SST = developer-facing application infrastructure platform

That is an important distinction.

The Multi-Cloud Architecture Becomes Three Layers

┌───────────────────────────────────────────────────────┐
│                Agent Applications                     │
│                                                       │
│            Strands / other frameworks                 │
└─────────────────────────┬─────────────────────────────┘
                          │
                          ▼
┌───────────────────────────────────────────────────────┐
│              Enterprise Agent SDK                     │
│                                                       │
│ Agent │ Tool │ Model │ Memory │ Policy │ Evaluation   │
└─────────────────────────┬─────────────────────────────┘
                          │
                          ▼
┌───────────────────────────────────────────────────────┐
│               Agent Platform API                      │
│                                                       │
│ Runtime      Identity       Policy                    │
│ Model        Tooling        Evaluation                │
│ Memory       Registry       Observability             │
└──────────────┬────────────────┬────────────────┬───────┘
               │                │                │
               ▼                ▼                ▼

          AWS Adapter      Azure Adapter      GCP Adapter
               │                │                │
               ▼                ▼                ▼

           AgentCore          Foundry       Agent Platform


─────────────────────────────────────────────────────────

                SST where appropriate

        Developer infrastructure experience

─────────────────────────────────────────────────────────

             Terraform / OpenTofu

        Enterprise infrastructure control plane

─────────────────────────────────────────────────────────

        AWS              Azure              GCP

─────────────────────────────────────────────────────────

              Enterprise Landing Zones

The Agent Platform API Becomes the Real Abstraction

In an AWS-only environment:

Enterprise SST Components
          ≈
     Platform API

can work extremely well.

But for genuine multi-cloud operation, the abstraction needs to move one level higher:

Agent Platform API
       │
       ├── AWS implementation
       ├── Azure implementation
       └── GCP implementation

Developers should describe their intent.

kind: Agent

metadata:
  name: account-servicing

spec:

  runtime:
    class: managed-agent

  model:
    capability: reasoning-large

  tools:
    - account-query
    - payments

  memory:
    profile: conversational
    retention: 30d

  identity:
    profile: customer-facing

  policy:
    profile: customer-servicing

  evaluation:
    profile: production

  observability:
    profile: standard

The platform then determines how that requirement should be implemented.

Developer
    │
    ▼
Agent Platform API
    │
    ├── createAgent
    ├── attachTool
    ├── attachMemory
    ├── attachIdentity
    ├── attachPolicy
    ├── attachModel
    └── deploy
    │
    ▼
Platform Control Plane
    │
    ├────────────┬────────────┐
    ▼            ▼            ▼

  AWS          Azure          GCP

Abstract Capabilities, Not Resources

The portable abstraction should not be:

GenericBucket

GenericQueue

GenericDatabase

GenericFunction

for every possible resource.

Those abstractions often destroy useful cloud-specific capability.

The more valuable agent abstractions are:

AgentRuntime

AgentModel

AgentTool

AgentMemory

AgentIdentity

AgentPolicy

AgentEvaluation

AgentObservability

These represent architectural capabilities rather than cloud resources.

Standardize Protocols Instead of Cloud Services

Protocols provide a more valuable form of portability.

I would standardize around:

Agent ↔ Agent       A2A

Agent ↔ Tool        MCP

Service ↔ Service   HTTP / OpenAPI

Identity            OAuth2 / OIDC

Telemetry           OpenTelemetry

This allows an architecture such as:

AWS Agent
    │
    │ A2A
    ▼
Azure Agent
    │
    │ MCP
    ▼
Enterprise Tool
    │
    │ HTTP
    ▼
GCP-hosted Service

That is far more valuable than pretending an S3 bucket and Azure Blob Storage are the same thing.

Separate Agent Runtime from Model Provider

Another important multi-cloud principle is:

Where the agent executes and where the model executes do not necessarily need to be the same architectural decision.

Think:

Agent Runtime
      │
      ▼
Model Gateway
      │
      ├── Amazon Bedrock
      ├── Microsoft Foundry
      ├── Google Vertex AI
      └── Other providers

The application could request a capability:

reasoning-large

reasoning-fast

vision

embedding

low-cost-classifier

rather than embedding provider-specific model IDs everywhere.

The model layer can then route based on:

Quality

Cost

Latency

Region

Data classification

Availability

Capacity

Regulation

Fallback policy

The abstraction represents model intent, not a claim that every model behaves identically.

Identity Is One of the Hard Multi-Cloud Problems

In AWS:

Agent
  │
  ▼
IAM Role
  │
  ▼
AWS Resource

is relatively straightforward.

Multi-cloud creates:

AWS Agent
    │
    ▼
Azure API


Azure Agent
    │
    ▼
GCP Service


GCP Agent
    │
    ▼
AWS Resource

Long-lived credentials should not become the solution.

The enterprise architecture should favour:

OIDC

OAuth2

Workload Identity Federation

Short-lived credentials

Per-agent identities

User-delegated identity where required

Identity should become a platform capability:

AgentIdentity

rather than an implementation detail every team has to rediscover.

Policy Must Sit Above Cloud IAM

AWS IAM, Azure RBAC and Google Cloud IAM remain essential.

But they answer infrastructure authorization questions.

Agent authorization often needs to answer:

May this agent perform this business operation on this object, for this user, under these conditions?

For example:

CustomerServiceAgent

readAccount
    ALLOW

changeAddress
    ALLOW

transferMoney(500)
    ALLOW

transferMoney(50,000)
    DENY

That policy should ideally behave consistently regardless of cloud.

                 Agent
                   │
                   ▼
              Tool Gateway
                   │
                   ▼
           Agent Authorization
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼

        AWS      Azure      GCP

        IAM       RBAC      IAM

Cloud IAM remains an important enforcement layer.

But business authorization should not be forced entirely into cloud-specific IAM models.

OpenTelemetry Should Be the Observability Contract

Cloud-native observability platforms remain useful:

AWS
    CloudWatch

Azure
    Azure Monitor
    Application Insights

Google Cloud
    Cloud Observability

But agent instrumentation should not depend directly on one of them.

Use OpenTelemetry as the common contract:

Agent
   │
   ▼
OpenTelemetry
   │
   ├── CloudWatch
   ├── Application Insights
   ├── Google Cloud Observability
   └── Enterprise observability platform

Define a common semantic model:

agent.run

model.invoke

tool.select

tool.invoke

agent.delegate

policy.evaluate

memory.read

memory.write

evaluation.run

This is the type of abstraction that should remain consistent across clouds.

Containers Are Another Useful Portability Boundary

Managed agent platforms differ, but OCI containers provide another useful boundary.

Agent Source
    │
    ▼
OCI Image
    │
 ┌──┼───────────────┐
 ▼  ▼               ▼

AWS Azure           GCP

Containers do not make the platforms identical.

They do, however, give the architecture another escape hatch.

Combined with:

Strands

MCP

A2A

OIDC

OpenTelemetry

this provides meaningful portability without requiring a lowest-common-denominator agent platform.

Do Not Confuse Portability with Symmetry

A multi-cloud architecture does not require:

AWS capability
     =
Azure capability
     =
GCP capability

A better model is:

               Enterprise Capability

                    AgentRuntime
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼

    AWS optimized    Azure optimized   GCP optimized
    implementation  implementation    implementation

The contract says:

Give me an agent runtime meeting these enterprise requirements.

The implementation uses the best capability available on the target cloud.

This avoids turning multi-cloud strategy into multi-cloud mediocrity.

Terraform vs SST vs CDK vs Pulumi

These technologies are often presented as mutually exclusive choices.

I think that is increasingly the wrong framing.

Technology	Role I Would Give It
Terraform / OpenTofu	Enterprise infrastructure control plane: landing zones, networks, accounts, policy, shared services and multi-cloud governance.
SST	Developer-facing application and agent infrastructure experience, particularly compelling for AWS-centric TypeScript engineering organizations.
AWS CDK	AWS-native implementation option and escape hatch where AWS-native abstractions or CloudFormation support provide an advantage.
Pulumi	A direct programmable-IaC alternative and an important part of the underlying ecosystem SST builds upon.
Bicep	Azure-native implementation option where native Azure integration makes it appropriate.

The Architecture I Would Choose for AWS

                   Developers
                       │
                       ▼
               Enterprise Agent SDK
                       │
                       ▼
                      SST
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼

     Application     Agents      Product Infra

                       │
                       ▼
                Amazon AgentCore
                       │
                       ▼
                     AWS


──────────────────────────────────────────────────

              Terraform / OpenTofu

──────────────────────────────────────────────────

AWS Organizations
Control Tower
Accounts
Networks
Security
IAM foundations
Logging
Shared services

CDK remains available where it provides a meaningful AWS-specific advantage.

The Architecture I Would Choose for Multi-Cloud

                    Developers
                        │
                        ▼
               Enterprise Agent SDK
                        │
                        ▼
                Agent Platform API
                        │
           ┌────────────┼────────────┐
           ▼            ▼            ▼

          AWS          Azure         GCP

           │            │            │
           ▼            ▼            ▼

       AgentCore      Foundry    Agent Platform


─────────────────────────────────────────────────────

             SST where it adds DX value

─────────────────────────────────────────────────────

              Terraform / OpenTofu

─────────────────────────────────────────────────────

        AWS          Azure          GCP

─────────────────────────────────────────────────────

           Enterprise Landing Zones

What About Agents Managing Infrastructure?

There is another reason this layered architecture matters.

Agents themselves will increasingly create and modify infrastructure definitions.

The wrong model is:

Infrastructure Agent
        │
        ▼
Cloud Administrator Credentials
        │
        ▼
Production

The better model is:

Agent
   │
   ▼
Generate IaC Change
   │
   ▼
Pull Request
   │
   ▼
Diff / Plan
   │
   ▼
Policy Checks
   │
   ▼
Automated Tests
   │
   ▼
Risk Classification
   │
   ├── Low Risk
   │      │
   │      ▼
   │   Automated Approval
   │
   └── High Risk
          │
          ▼
      Human Approval
          │
          ▼
        Deploy

Agents should propose infrastructure changes. Deployment identities should apply them.

This separates reasoning authority from execution authority.

As agents become more capable, that distinction becomes increasingly important.

Start AWS-Native, but Design the Seams

Many organizations will be primarily AWS today while acknowledging that multi-cloud may matter later.

I would not build the full multi-cloud control plane in anticipation.

Instead, design useful seams:

Agent
  │
  ├── Model Provider Interface
  │
  ├── MCP Tool Interface
  │
  ├── A2A Agent Interface
  │
  ├── OIDC Identity Boundary
  │
  ├── OpenTelemetry
  │
  └── OCI Packaging

But deploy:

SST
 │
 ▼
AWS
 │
 ▼
AgentCore

today if that is what gives the organization the best engineering productivity.

The goal is:

Native optimization now
          +
Architectural optionality later

rather than paying the complexity cost of multi-cloud before the business actually needs it.

A Practical Maturity Model

I would expect an organization to evolve through something like these stages.

Stage 1 — Infrastructure as Code

Terraform / CDK / SST
        │
        ▼
Cloud Resources

Stage 2 — Platform as Code

Enterprise Components
        │
        ▼
Reusable Cloud Capabilities

Stage 3 — Agent Platform as Code

EnterpriseAgent

AgentRuntime

AgentTool

AgentMemory

AgentIdentity

AgentPolicy

AgentEvaluation

Stage 4 — Intent-Driven Agent Platform

Developer Intent
       │
       ▼
Agent Platform API
       │
       ├── AWS
       ├── Azure
       └── GCP

At this point the developer no longer thinks primarily in terms of cloud resources.

They think in terms of agent capabilities.

The Most Important Architectural Distinction

The discussion ultimately comes down to three different abstractions:

Terraform / OpenTofu

    standardizes how the enterprise
    governs infrastructure


SST

    standardizes how developers
    consume and develop with infrastructure


Agent Platform API

    standardizes how applications and agents
    consume agent capabilities

Trying to force one technology to perform all three roles is likely to create unnecessary complexity.

The Principle to Remember

If you are AWS-centric

Optimize for AWS. Use Terraform or OpenTofu for the enterprise foundation, strongly consider SST for the developer-facing application and agent platform, and use AWS-native capabilities such as AgentCore aggressively.

If you are genuinely multi-cloud

Move the abstraction upward. Use Terraform or OpenTofu as the enterprise control plane, use SST where it improves developer experience, and make the Agent Platform API — not the individual IaC technology — the cross-cloud abstraction.

Most importantly:

Standardize capabilities, protocols, identity, policy, evaluation and observability — not individual cloud resources.

This allows an organization to take full advantage of Amazon Bedrock AgentCore, Microsoft Foundry and Google's agent platform without pretending they are identical.

It also gives developers something much more valuable than nominal portability: a consistent engineering model.

That is where I think Infrastructure as Code is heading for agentic systems.

Not toward one giant generic cloud abstraction.

But toward an architecture where:

Enterprise Governance
        │
        ▼
Terraform / OpenTofu
        │
        ▼

Developer Experience
        │
        ▼
       SST
        │
        ▼

Agent Platform
        │
        ▼
Agent Platform API
        │
   ┌────┼────┐
   ▼    ▼    ▼

  AWS Azure GCP

The clouds remain different.

The developer experience becomes consistent.

And the platform preserves enough separation to adopt new agent runtimes, models and cloud capabilities as the ecosystem continues to evolve.

That is a much stronger form of portability than simply choosing an IaC language that happens to work everywhere.

Sources and Further Reading

This article was reviewed against current product documentation as of August 2026. Key source material includes:

SST documentation — architecture, components, providers and resource linking.
SST v3 architecture documentation — Pulumi and Terraform provider model.
SST Policy Packs documentation.
SST state and home-provider documentation.
HashiCorp AWS Provider documentation for Amazon Bedrock AgentCore resources.
AWS documentation for Amazon Bedrock AgentCore.
AWS CDK best-practice documentation.
Strands Agents documentation.
Microsoft Foundry Agent Service documentation.
Google Cloud Gemini Enterprise Agent Platform documentation.
OpenTelemetry documentation.
Model Context Protocol documentation.
Agent2Agent protocol documentation.

Infrastructure as Code for the Agentic Cloud

How infrastructure strategy changes when moving from AWS-first to multi-cloud agent platforms

Infrastructure as Code has traditionally been concerned with relatively predictable things: networks, compute, storage, databases, identity, queues and deployment pipelines.

Agentic systems change the shape of that infrastructure.

An AI agent is not simply another workload running in a container. Production agents increasingly require a collection of capabilities around them: runtime isolation, model access, memory, tool connectivity, workload identity, policy enforcement, evaluation, tracing and sometimes communication with other agents.

Cloud providers are responding by building increasingly complete agent platforms.

AWS has Amazon Bedrock AgentCore. Microsoft has Foundry Agent Service. Google has been evolving its managed agent capabilities around its Gemini and Vertex AI platforms.

This raises an important infrastructure question:

If agents become a significant part of the application architecture, what should Infrastructure as Code look like?

The answer is quite different depending on whether you are committed primarily to AWS or genuinely expect to operate across AWS, Azure and Google Cloud.

The core recommendation: for AWS-only, embrace AWS-native abstractions and make CDK constructs part of your agent platform. For multi-cloud, standardize the platform contract rather than the underlying resources, with Terraform or OpenTofu as the common infrastructure control plane and cloud-native IaC behind clear ownership boundaries.

Agents Change What We Mean by Infrastructure

Consider a conventional cloud application:

Application
    │
    ├── Compute
    ├── Database
    ├── Queue
    ├── Storage
    └── Observability

A production agent increasingly looks more like:

Agent
  │
  ├── Runtime
  ├── Model
  ├── Memory
  ├── Tools
  ├── Identity
  ├── Policy
  ├── Guardrails
  ├── Evaluation
  └── Observability

This means Infrastructure as Code needs to evolve beyond provisioning infrastructure.

For an agent platform, several forms of as code start working together:

Infrastructure as Code
        │
        ├── Runtime
        ├── Network
        ├── Storage
        └── Compute

Identity & Policy as Code
        │
        ├── IAM
        ├── Tool permissions
        └── Business authorization

Agent as Code
        │
        ├── Orchestration
        ├── Tools
        └── Skills

Prompts as Code

Evaluation as Code

Observability as Code

The infrastructure repository is becoming part of the Agent SDLC.

Scenario One: AWS Is Your Cloud

Suppose AWS is overwhelmingly your strategic cloud platform and you expect to build agents with Strands Agents and Amazon Bedrock AgentCore.

In that situation, I would optimize for AWS rather than prematurely designing for portability.

My preferred stack would look something like:

AWS Organizations
       │
AWS Control Tower
       │
Enterprise Landing Zone
       │
Terraform / OpenTofu
or existing enterprise IaC
       │
─────────────────────────
       │
AWS CDK + TypeScript
       │
Enterprise Constructs
       │
Agent Platform Constructs
       │
Amazon Bedrock AgentCore
       │
Strands Agents
       │
Amazon Bedrock

There is an important distinction here.

Terraform may still be the right choice for the enterprise AWS foundation:

Organizations
Accounts
Organizational Units
SCPs
Network foundations
DNS
Security accounts
Logging
Shared services

But for application and agent infrastructure I would seriously favour AWS CDK using TypeScript.

The closer you get to AgentCore, the more valuable AWS-native abstractions become.

AgentCore's deployment tooling itself makes extensive use of AWS CDK, which is an important architectural signal: AWS is treating CDK and CloudFormation as native deployment substrates for these capabilities.

CDK Constructs Become Your Agent Platform API

The most powerful feature of CDK in this environment isn't simply that TypeScript is nicer than YAML.

It is constructs.

Instead of every agent team creating raw resources, a central platform team could expose:

@company/aws-platform

SecureBucket
ServiceApi
EventConsumer
StandardLambda
StandardContainer

and then:

@company/agent-platform

EnterpriseAgent
AgentRuntime
AgentGateway
AgentTool
AgentMemory
AgentIdentity
AgentPolicy
AgentEvaluator

The developer experience could eventually look conceptually like:

new EnterpriseAgent(this, "AccountServicingAgent", {
  framework: "strands",

  model: {
    capability: "reasoning-large"
  },

  tools: [
    accountQuery,
    payments,
    customerProfile
  ],

  memory: {
    enabled: true
  },

  policy: {
    source: "./policies"
  },

  evaluation: {
    source: "./evals"
  },

  observability: {
    enabled: true
  }
});

The construct could provision or configure everything required around the agent:

EnterpriseAgent
      │
      ├── AgentCore Runtime
      ├── Runtime Endpoint
      ├── Gateway
      ├── Memory
      ├── Identity
      ├── Policy Engine
      ├── Evaluators
      ├── IAM
      ├── KMS
      └── Observability

That becomes a powerful internal golden path.

Treat the Tool Boundary as Infrastructure

One of the biggest architectural changes with agents is that the boundary between an agent and its tools becomes critical infrastructure.

An unsafe architecture looks like:

Agent
   │
   └──────────────► Enterprise systems

     broad credentials

A better pattern is:

Agent
   │
   ▼
Agent Gateway
   │
   ├── Identity
   ├── Authorization
   ├── Policy
   ├── Audit
   └── Tool contracts
          │
          ▼
    Enterprise APIs

AgentCore Gateway can expose tools to agents using MCP, while AgentCore Policy can enforce deterministic authorization at the gateway boundary.

This matters because authorization should not depend on an LLM deciding to follow a prompt.

You don't want this to be your security control:

System prompt:

"Never refund more than $1,000."

You want:

Agent
  │
  ▼
refund($20,000)
  │
  ▼
Policy Engine
  │
  ▼
amount <= $1,000 ?
  │
  └── NO → DENY

Policy therefore belongs alongside your infrastructure:

agent/
├── src/
├── tools/
├── prompts/
├── skills/
├── policies/
│   ├── accounts.cedar
│   └── payments.cedar
├── evals/
└── infra/

Agent infrastructure is therefore not simply where does my process run?

It defines what the agent is allowed to do.

Evaluation Should Be Part of Deployment

Traditional IaC asks:

Did the infrastructure deploy successfully?

Agent infrastructure needs another question:

Does the agent still behave correctly after the deployment?

A mature pipeline begins to look like:

Commit
   │
   ▼
Static analysis
   │
   ▼
Unit tests
   │
   ▼
CDK synth
   │
   ▼
Policy tests
   │
   ▼
Deploy ephemeral environment
   │
   ▼
Agent evaluations
   │
   ├── task completion
   ├── tool selection
   ├── policy compliance
   ├── safety
   └── regression
   │
   ▼
Deploy

Evaluation definitions should increasingly become deployable platform assets just like alarms or dashboards.

Observability Should Be Automatic

Agent observability is richer than conventional application logging.

A useful trace might look like:

agent.run
   │
   ├── model.invoke
   │
   ├── memory.read
   │
   ├── tool.select
   │
   ├── policy.evaluate
   │
   ├── tool.invoke
   │
   ├── model.invoke
   │
   └── evaluation

AgentCore and Strands both align well with OpenTelemetry-based instrumentation.

An EnterpriseAgent construct should therefore configure observability automatically.

Developers shouldn't have to remember it.

The AWS-Only Architecture

The resulting AWS architecture might look like:

┌─────────────────────────────────────────────┐
│               Agent Products                │
│                                             │
│         Strands-based applications          │
└─────────────────────┬───────────────────────┘
                      │
┌─────────────────────▼───────────────────────┐
│        Enterprise Agent Constructs          │
│                                             │
│ Runtime │ Tool │ Memory │ Policy │ Eval     │
└─────────────────────┬───────────────────────┘
                      │
┌─────────────────────▼───────────────────────┐
│          Amazon Bedrock AgentCore           │
│                                             │
│ Runtime     Gateway       Memory            │
│ Identity    Policy        Evaluations       │
│ Observability                              │
└─────────────────────┬───────────────────────┘
                      │
┌─────────────────────▼───────────────────────┐
│              AWS Platform                   │
│                                             │
│ Bedrock │ IAM │ KMS │ S3 │ SQS │ DynamoDB  │
│ EventBridge │ Lambda │ VPC │ CloudWatch     │
└─────────────────────────────────────────────┘

For an AWS-only environment: use the cloud. Don't hide it.

AWS is the platform. AgentCore is an architectural choice. CDK is a productive mechanism for packaging those capabilities.

Trying to make this portable before you actually need portability adds abstractions without necessarily creating value.

Then Someone Says: “We Also Need Azure and GCP”

This changes the problem significantly.

Suppose AWS remains the dominant provider, but business units may deploy workloads into Azure or Google Cloud.

Perhaps different geographic regions have different cloud strategies. Perhaps you acquire companies with different cloud estates. Perhaps a particular AI model or managed service is attractive on another provider.

Or perhaps avoiding excessive dependence on a single AI platform is itself a strategic objective.

At that point I would not simply extend the AWS CDK model to every cloud.

The architecture needs another layer.

The Multi-Cloud Rule: Abstract Capabilities, Not Resources

A common multi-cloud mistake is attempting to create an imaginary generic cloud:

                 Generic Cloud
                      │
          ┌───────────┴───────────┐
          │                       │
       AWS S3                Azure Blob
          │                       │
          └──── "Storage" ────────┘

Keep repeating this and eventually you end up with a platform exposing only the features that all three clouds have in common.

You have built the lowest common denominator cloud.

Agents make this particularly problematic because the managed platforms are meaningfully different.

Capability	AWS	Microsoft Azure	Google Cloud
Managed agent platform	Bedrock AgentCore	Foundry Agent Service	Gemini / Vertex AI agent platform
Model platform	Bedrock	Foundry Models	Vertex AI / Model Garden
Identity	IAM / AgentCore Identity	Entra / Managed Identity	IAM / Workload Identity
Secret store	Secrets Manager	Key Vault	Secret Manager
Object storage	S3	Blob Storage	Cloud Storage
Messaging	SQS / EventBridge	Service Bus / Event Grid	Pub/Sub / Eventarc
Observability	CloudWatch	Azure Monitor / Application Insights	Cloud Observability
Native IaC	CDK / CloudFormation	Bicep	Terraform / APIs

These aren't simply three implementations of the same API.

And that is a good thing.

Terraform Becomes Much More Attractive

Once infrastructure genuinely spans AWS, Azure and GCP, my IaC recommendation changes.

Make Terraform or OpenTofu the enterprise-level declarative infrastructure control plane.

The architecture becomes:

                     Platform Engineering
                            │
                    Terraform / OpenTofu
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
            AWS            Azure           GCP
             │              │              │
        AWS modules    Azure modules    GCP modules
             │              │              │
             ▼              ▼              ▼
        AgentCore         Foundry      Agent Platform

The benefit isn't that Terraform magically makes cloud services equivalent.

It gives platform engineering teams a common lifecycle, policy and delivery mechanism.

But Don't Ban Native IaC

A multi-cloud Terraform strategy should not become:

Everything must be represented directly in Terraform no matter how awkward it is.

I would allow:

Terraform / OpenTofu
        │
        ├── AWS
        │     └── CDK / CloudFormation where appropriate
        │
        ├── Azure
        │     └── Bicep / native APIs where appropriate
        │
        └── GCP
              └── native APIs where appropriate

AgentCore is a good example.

Its deployment model has a natural relationship with CDK:

AgentCore tooling
      │
      ▼
AWS CDK
      │
      ▼
CloudFormation
      │
      ▼
AWS

There is little value in fighting that purely in the name of tool standardization.

The important rule: two IaC systems must never believe they own the same resource lifecycle.

Bad:

Terraform creates IAM role
CDK modifies IAM role
Terraform creates Gateway
CLI modifies Gateway
someone manually creates Policy

Good:

Terraform owns:
  AWS account
  network
  shared platform
  cross-cloud integration

CDK owns:
  AgentCore application boundary

Ownership boundaries matter more than having exactly one syntax.

Move the Abstraction Above IaC

This is the most important architectural change when moving to multi-cloud.

In an AWS-only environment:

CDK Constructs
      ≈
Platform API

In a mature multi-cloud environment:

Agent Platform API
       │
       ├── AWS implementation
       ├── Azure implementation
       └── GCP implementation

becomes the platform API.

Terraform, CDK and Bicep move underneath it.

Developers should increasingly describe intent:

kind: Agent

metadata:
  name: account-servicing

spec:
  runtime:
    provider: aws

  model:
    capability: reasoning-large

  memory:
    retention: 30d

  tools:
    - account-query
    - payments

  policy:
    profile: customer-servicing

  evaluation:
    profile: production

  observability:
    profile: standard

The control plane determines how to implement that intent.

Developer
    │
    ▼
Agent Platform API
    │
    ├── createAgent
    ├── attachTool
    ├── attachMemory
    ├── attachPolicy
    ├── attachModel
    └── deploy
    │
    ▼
Platform Control Plane
    │
    ├────────────┬────────────┐
    ▼            ▼            ▼
  AWS          Azure          GCP

This is the right level of abstraction.

Standardize Protocols Rather Than Cloud Services

Portability becomes much easier if the contracts between components are open.

I would strongly favour an architecture built around:

Agent ↔ Agent       A2A

Agent ↔ Tool        MCP

Service ↔ Service   HTTP / OpenAPI

Identity            OAuth2 / OIDC

Telemetry           OpenTelemetry

Strands is useful here because it provides an agent framework while supporting model-provider abstraction, MCP, A2A and OpenTelemetry.

That enables architectures such as:

AWS Agent
    │
    │ A2A
    ▼
Azure Agent
    │
    │ MCP
    ▼
Enterprise Tool
    │
    │ HTTP
    ▼
GCP-hosted service

This is real portability.

Making S3 and Azure Blob Storage share an artificial API is far less strategically valuable.

Separate the Agent from the Model

Another important multi-cloud principle is:

Where the agent executes and where the model executes do not necessarily need to be the same decision.

Think:

Agent Runtime
      │
      ▼
Model Gateway
      │
      ├── Bedrock
      ├── Microsoft Foundry
      ├── Google Vertex AI
      └── other providers

The application might ask for:

reasoning-large
reasoning-fast
vision
embedding
low-cost-classifier

instead of embedding model identifiers everywhere.

The routing layer can then consider:

Quality
Cost
Latency
Region
Data classification
Availability
Capacity
Regulation
Fallback

Notice what we are abstracting here.

We are abstracting model intent.

We are not pretending every model is identical.

Identity Becomes a First-Class Multi-Cloud Capability

Identity is relatively straightforward when everything lives within one AWS boundary:

Agent
  │
  ▼
IAM Role
  │
  ▼
AWS Service

It becomes harder when:

AWS Agent
    │
    ▼
Azure API

Azure Agent
    │
    ▼
GCP Service

GCP Agent
    │
    ▼
AWS Resource

Long-lived credentials should not become the solution.

A mature architecture should build around:

OIDC
OAuth2
Workload identity federation
Short-lived credentials
Per-agent identities
User delegation

The enterprise platform should therefore expose something conceptually like:

AgentIdentity

rather than expecting every product team to invent its own cross-cloud credential strategy.

Policy Must Sit Above Cloud IAM

IAM remains essential.

But AWS IAM, Azure RBAC and Google Cloud IAM are infrastructure authorization systems.

Agent authorization often needs to express a different question:

May this agent perform this business operation on this object, for this user, under these conditions?

For example:

CustomerServiceAgent

readAccount
    ALLOW

changeAddress
    ALLOW

transferMoney(500)
    ALLOW

transferMoney(50,000)
    DENY

That policy should ideally behave consistently regardless of whether the agent happens to execute on AWS, Azure or GCP.

                 Agent
                   │
                   ▼
              Tool Gateway
                   │
                   ▼
           Agent Authorization
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
        AWS      Azure      GCP
        IAM       RBAC      IAM

Cloud IAM remains the last line of enforcement.

But it shouldn't have to encode every piece of business authorization logic.

Make OpenTelemetry the Observability Contract

Cloud-native observability remains useful.

AWS has CloudWatch. Azure has Azure Monitor and Application Insights. Google has Cloud Observability.

But agent instrumentation should not depend on any one of them.

Agent
   │
   ▼
OpenTelemetry
   │
   ├── CloudWatch
   ├── Application Insights
   ├── Google Cloud Observability
   └── Enterprise observability platform

Define a common semantic model:

agent.run

model.invoke

tool.select

tool.invoke

agent.delegate

policy.evaluate

memory.read

memory.write

evaluation.run

This is precisely the kind of layer that should be standardized.

Containers Become Another Useful Portability Boundary

There is also a more mundane but powerful portability mechanism:

OCI Container

Containers don't make managed agent platforms equivalent.

They do, however, give you a useful packaging boundary:

Agent source
    │
    ▼
OCI image
    │
 ┌──┼──────────────┐
 ▼  ▼              ▼
AWS Azure          GCP

Combined with Strands, MCP, A2A, OIDC and OpenTelemetry, this provides several practical escape hatches without forcing a lowest-common-denominator platform.

Don't Confuse Portability with Symmetry

A multi-cloud architecture does not require:

AWS capability
    =
Azure capability
    =
GCP capability

A better model is:

              Enterprise Capability

                     AgentRuntime
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼

    AWS optimized    Azure optimized   GCP optimized
    implementation  implementation    implementation

The contract says:

Give me a managed agent runtime meeting these enterprise requirements.

The implementation can still use the best available cloud-native capability.

That distinction prevents multi-cloud strategy becoming multi-cloud mediocrity.

The Architecture I Would Build

Putting everything together gives us three major layers.

┌─────────────────────────────────────────────────────────┐
│                    Agent Applications                   │
│                                                         │
│                Strands / other frameworks               │
└───────────────────────────┬─────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────┐
│                 Enterprise Agent SDK                    │
│                                                         │
│ Agent │ Tool │ Model │ Memory │ Policy │ Evaluation     │
└───────────────────────────┬─────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────┐
│                 Agent Platform API                      │
│                                                         │
│ Deployment       Identity        Policy                 │
│ Model routing    Registry        Evaluation             │
│ Observability    Secrets         Governance             │
└───────────────┬──────────────┬──────────────┬───────────┘
                │              │              │
                ▼              ▼              ▼
         AWS Adapter      Azure Adapter     GCP Adapter
                │              │              │
                ▼              ▼              ▼
          AgentCore          Foundry      Agent Platform

───────────────────────────────────────────────────────────

             Terraform / OpenTofu Control Plane

───────────────────────────────────────────────────────────

        AWS              Azure              Google Cloud

───────────────────────────────────────────────────────────

                  Enterprise Landing Zones

Notice where Terraform sits.

It is important.

But it isn't the developer abstraction.

The Agent Platform API is the abstraction.

Terraform, OpenTofu or Pulumi?

For a large enterprise, Terraform remains the conservative default for a multi-cloud control plane because of its provider model, ecosystem and widespread platform-engineering adoption.

OpenTofu deserves consideration where its open-source governance and licensing model better fit organizational strategy.

Pulumi is also interesting for this particular problem because agent platforms increasingly involve sophisticated abstractions, and defining those abstractions in TypeScript, Python or Go can be attractive.

I would therefore think about the decision like this:

Single-cloud AWS

        CDK
         │
         ▼
   Agent Constructs
         │
         ▼
     AgentCore

versus:

Multi-cloud

       Agent Platform API
              │
       Terraform/OpenTofu
              │
     ┌────────┼────────┐
     ▼        ▼        ▼
    AWS     Azure     GCP
     │        │        │
    CDK     Bicep    Native
    where    where    where
    useful   useful   useful

These aren't contradictory architectures.

They are two different levels of abstraction.

What About Agents Managing Infrastructure?

There is one additional consideration that becomes increasingly important as agent adoption grows.

Agents will themselves start writing and modifying Infrastructure as Code.

The wrong pattern is:

Infrastructure Agent
        │
        ▼
cloud administrator credentials
        │
        ▼
Production

The better model is:

Agent
   │
   ▼
Generate IaC change
   │
   ▼
Pull Request
   │
   ▼
Plan / Synth
   │
   ▼
Policy checks
   │
   ▼
Automated tests
   │
   ▼
Risk classification
   │
   ├── low risk ─────► automated approval
   │
   └── high risk ────► human approval
                         │
                         ▼
                       Deploy

The principle: agents propose infrastructure changes. Deployment identities apply them.

This gives you a clean separation between reasoning authority and execution authority.

As agents become more capable, that distinction becomes increasingly important.

Start AWS-Native, but Design the Seams

There is also a pragmatic middle ground.

You may be AWS-only today while recognizing that multi-cloud is possible in the future.

I would not build the entire multi-cloud control plane in anticipation.

Instead, design the seams:

Agent
  │
  ├── Model Provider interface
  │
  ├── MCP tool interface
  │
  ├── A2A agent interface
  │
  ├── OIDC identity boundary
  │
  ├── OpenTelemetry
  │
  └── OCI packaging

But deploy:

AWS CDK
   │
   ▼
AgentCore

today.

This gives you:

Native optimization now
        +
Architectural optionality later

without paying the complexity cost of multi-cloud before it creates business value.

The Principle to Remember

If I had to reduce the architecture to two rules, they would be these.

For an AWS-centric organization

Use AWS-native capabilities aggressively. Treat reusable CDK agent constructs as your internal platform API.

For an organization genuinely operating across clouds

Move the abstraction upward. Standardize agent capabilities, protocols, identity, telemetry and policy — not individual cloud resources.

That gives us the progression:

Stage 1

Infrastructure as Code
        │
        ▼
Cloud resources


Stage 2

Platform as Code
        │
        ▼
Reusable cloud capabilities


Stage 3

Agent Platform as Code
        │
        ▼
Agents
Models
Tools
Identity
Memory
Policy
Evaluation
Observability

And ultimately:

Developer Intent
       │
       ▼
Agent Platform
       │
       ├── AWS
       ├── Azure
       └── GCP

That is where Infrastructure as Code is heading for agentic systems.

Not toward a universal abstraction that pretends every cloud is the same.

But toward an intent-driven agent platform that gives developers a consistent operating model while deliberately preserving the differentiated capabilities of each cloud.

That difference is subtle, but it is the difference between building a multi-cloud platform and merely building another abstraction layer.