AWS Professional Services just published production data on a multi-agent system that compresses infrastructure-as-code development from weeks to minutes. The system chains four specialized agents (discovery, IaC generation, governance, operations) using Amazon Bedrock AgentCore primitives. This is not a demo. It is a deployed enterprise migration workflow with real customer proof points.
The interesting part is how AWS routes tasks between agents without creating circular dependencies, and how they instrument handoffs when a single migration spans four agents with different failure modes.
Architecture: Four Agents, One Workflow
The system decomposes cloud migration into four agent roles:
- Discovery Agent: Scans existing infrastructure, builds dependency graphs, identifies migration candidates
- IaC Generation Agent: Converts discovered resources into Terraform or CloudFormation templates
- Portfolio Governance Agent: Validates generated IaC against organizational policies, cost budgets, security baselines
- Post-Migration Operations Agent: Monitors deployed resources, handles drift detection, executes remediation
Each agent is a Bedrock Agent with tool access scoped to its domain. The discovery agent cannot deploy infrastructure. The IaC generation agent cannot read production credentials. The governance agent has read-only access to policy repositories.
AgentCore orchestrates handoffs using a state machine pattern. When the discovery agent completes a scan, it writes structured output (JSON schema with resource metadata, dependencies, and migration readiness scores) to an S3 bucket. The IaC generation agent subscribes to that bucket via EventBridge and begins template generation only after the discovery agent marks the scan as complete.
State Management and Handoff Primitives
The key orchestration primitive is a migration manifest stored in DynamoDB. Each migration project gets a manifest with these fields:
-
project_id: Unique identifier for the migration -
current_stage: Enum (discovery, iac_generation, governance_review, deployment, post_migration) -
agent_outputs: Map of agent name to S3 URIs for structured outputs -
validation_results: Array of governance checks with pass/fail status -
deployment_state: Terraform state file location or CloudFormation stack ARN
When an agent completes its task, it updates the manifest and publishes an EventBridge event. The next agent in the chain subscribes to that event type and reads the previous agent's output from S3.
This design avoids circular dependencies because agents never call each other directly. They communicate through immutable artifacts (S3 objects) and state transitions (DynamoDB updates). If the governance agent rejects IaC templates, it sets current_stage back to iac_generation and writes rejection reasons to validation_results. The IaC generation agent polls the manifest and regenerates templates based on the feedback.
Governance Agent: The Critical Checkpoint
The portfolio governance agent is the only agent that can block a migration. It runs a suite of validation tools:
- Cost estimation: Calls AWS Pricing API to project monthly spend for generated resources
-
Security posture: Runs
checkovortfsecagainst IaC templates to catch misconfigurations - Compliance checks: Validates that resources match organizational tagging policies, encryption requirements, network segmentation rules
If any check fails, the governance agent writes a structured rejection message to the manifest and halts the workflow. The IaC generation agent must address all failures before the workflow can proceed.
This checkpoint prevents the common failure mode where automated IaC generation creates resources that violate organizational policies. The governance agent acts as a circuit breaker.
Authorization Boundaries
AWS uses IAM roles to enforce least-privilege access between agents:
| Agent | Read Access | Write Access | Deployment Permissions |
|---|---|---|---|
| Discovery | Existing infrastructure (EC2, RDS, VPC) | S3 (scan results) | None |
| IaC Generation | S3 (scan results), policy repos | S3 (IaC templates) | None |
| Governance | S3 (IaC templates), policy repos, pricing API | DynamoDB (validation results) | None |
| Operations | Deployed resources (CloudWatch, Config) | S3 (remediation logs), CloudFormation/Terraform | Deploy, update, delete resources |
Only the operations agent can deploy infrastructure. The discovery and IaC generation agents operate in a read-only or generate-only mode. This separation limits blast radius. If the IaC generation agent hallucinates invalid templates, the governance agent catches them before deployment.
The operations agent assumes a role with time-limited credentials. After deployment, the role expires. Post-migration monitoring uses a separate read-only role.
Observability and Failure Modes
AWS instruments agent handoffs using CloudWatch Logs Insights and X-Ray. Each agent logs structured JSON with these fields:
{
"project_id": "migration-12345",
"agent_name": "iac-generation",
"stage": "template_generation",
"status": "success",
"duration_ms": 4200,
"output_uri": "s3://migrations/12345/iac-templates.zip",
"errors": []
}
When a handoff fails, the system captures:
- Timeout errors: If an agent does not update the manifest within 15 minutes, EventBridge triggers a dead-letter queue handler
- Validation errors: The governance agent writes detailed rejection reasons to the manifest, which the IaC generation agent reads and uses to refine templates
- Deployment errors: The operations agent captures Terraform or CloudFormation error messages and writes them to CloudWatch Logs
The most common failure mode is the IaC generation agent producing templates that fail governance checks. AWS reports that the first iteration of generated IaC passes governance about 60% of the time. The agent typically needs two or three iterations to satisfy all policies.
Code Example: Manifest Update Pattern
Here is how an agent updates the migration manifest after completing its task:
import boto3
from datetime import datetime
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('migration-manifests')
def complete_discovery(project_id, scan_results_uri):
table.update_item(
Key={'project_id': project_id},
UpdateExpression='SET current_stage = :stage, agent_outputs.discovery = :uri, updated_at = :ts',
ExpressionAttributeValues={
':stage': 'iac_generation',
':uri': scan_results_uri,
':ts': datetime.utcnow().isoformat()
}
)
# Publish event to trigger next agent
events = boto3.client('events')
events.put_events(
Entries=[{
'Source': 'migration.discovery',
'DetailType': 'DiscoveryComplete',
'Detail': json.dumps({
'project_id': project_id,
'scan_results_uri': scan_results_uri
})
}]
)
The IaC generation agent subscribes to DiscoveryComplete events and begins work when it receives one.
Deployment Shape
AWS deploys this system as a set of Lambda functions (one per agent) orchestrated by Step Functions. Each Lambda function:
- Reads the migration manifest from DynamoDB
- Downloads input artifacts from S3
- Calls Bedrock Agent APIs to execute the agent's task
- Writes output artifacts to S3
- Updates the manifest and publishes an EventBridge event
Step Functions provides retry logic and timeout handling. If an agent Lambda times out (15-minute limit), Step Functions retries up to three times with exponential backoff.
The system uses Bedrock Agents with Claude 3.5 Sonnet as the foundation model. Each agent has a custom instruction set and tool definitions. The IaC generation agent has tools for reading AWS documentation, querying Terraform registry, and validating HCL syntax. The governance agent has tools for running policy-as-code checks and querying cost estimation APIs.
Performance and Cost
AWS reports these metrics from production deployments:
- Discovery phase: 5-10 minutes for a typical enterprise application (50-100 resources)
- IaC generation: 3-5 minutes per iteration (average 2 iterations to pass governance)
- Governance review: 1-2 minutes (automated checks only)
- Total workflow time: 15-30 minutes from discovery to deployment-ready IaC
Cost per migration project:
- Bedrock API calls: $2-5 (depends on resource count and iteration count)
- Lambda execution: $0.50-1.00
- DynamoDB and S3: negligible
- Total: $3-7 per migration project
This compares to manual IaC development, which AWS estimates at 2-4 weeks of engineer time per application.
Trade-offs and Risks
| Aspect | Benefit | Risk |
|---|---|---|
| Multi-agent decomposition | Clear separation of concerns, easier to debug individual agents | Coordination overhead, more moving parts |
| Governance checkpoint | Prevents policy violations before deployment | Can block workflows if policies are too strict or unclear |
| Immutable artifacts | Agents cannot corrupt each other's state | Storage costs for large migrations, S3 consistency delays |
| EventBridge orchestration | Loose coupling, easy to add new agents | Harder to trace end-to-end workflow, eventual consistency |
| Bedrock Agent foundation | No model hosting, built-in tool calling | Vendor lock-in, limited control over prompt engineering |
The biggest operational risk is the governance agent becoming a bottleneck. If organizational policies are ambiguous or contradictory, the IaC generation agent may iterate indefinitely without satisfying all checks. AWS recommends starting with a small set of high-priority policies and expanding gradually.
Technical Verdict
Use this pattern when:
- You have a portfolio of applications to migrate (10+ projects) and manual IaC development is a bottleneck
- Your organization has well-defined infrastructure policies that can be encoded as automated checks
- You need audit trails and governance checkpoints before deploying generated infrastructure
- You are already using AWS and Bedrock (minimal integration work)
Avoid this pattern when:
- You are migrating a single application (overhead outweighs benefits)
- Your infrastructure policies are still evolving or poorly documented (governance agent will block everything)
- You need fine-grained control over LLM prompts and tool definitions (Bedrock Agents abstract this away)
- You require sub-minute latency for IaC generation (multi-agent handoffs add coordination overhead)
The real value is not the speed of IaC generation. It is the ability to apply consistent governance policies across dozens or hundreds of migration projects without manual review. The multi-agent architecture makes it easy to add new validation checks (security scanning, cost optimization, compliance audits) without rewriting the entire system.
Top comments (0)