# AWS AgentCore Cloud Migration: Multi-Agent Orchestration for Infrastructure-as-Code Generation > Source: > Published: 2026-08-25 00:07:21+00:00 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. The system decomposes cloud migration into four agent roles: 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. 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 ARNWhen 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. The portfolio governance agent is the only agent that can block a migration. It runs a suite of validation tools: `checkov` or `tfsec` against IaC templates to catch misconfigurationsIf 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. 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. 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: 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. Here is how an agent updates the migration manifest after completing its task: ``` python 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. AWS deploys this system as a set of Lambda functions (one per agent) orchestrated by Step Functions. Each Lambda function: 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. AWS reports these metrics from production deployments: Cost per migration project: This compares to manual IaC development, which AWS estimates at 2-4 weeks of engineer time per application. | 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. **Use this pattern when:** **Avoid this pattern when:** 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.