Automating AWS Landing Zone Gap Assessments with Kiro and AWS Transform

How to use AI-powered IDE tooling to assess landing zone readiness before workload migration

Introduction

Before migrating workloads to AWS -- whether from VMware, on-premises data centers, or other cloud providers -- a well-architected multi-account landing zone is a prerequisite, not an afterthought. Organizations that skip this step often discover mid-migration that they lack account isolation, governance guardrails, or centralized logging -- leading to costly rework, security gaps, and delayed timelines.

This post demonstrates how to use Kiro (an AI-powered development environment) with the AWS Transform Power to conduct an automated landing zone gap assessment. We walk through the end-to-end process of connecting to a target AWS account, invoking the Landing Zone Agent, and generating a structured findings report -- all from the IDE without switching to the AWS Console.

Whether you are dealing with a greenfield environment (no Organization structure) or a brownfield scenario (existing OUs, accounts, and Control Tower already deployed), the AWS Transform Landing Zone Agent inspects your current state and identifies gaps against AWS best practices.

Prerequisites

Before starting, ensure you have the following:

• Kiro IDE installed with the AWS Transform Power enabled
• AWS Transform application deployed in the same AWS account you want to assess (or in an account within the same AWS Organization)
• AWS credentials configured for the target account (default CLI profile or named profile)
• Browser access to the AWS Transform console for connector approval

Important: The AWS Transform connector requires that the application account and target account be members of the same AWS Organization. For same-account assessments, this requirement is automatically satisfied.

Architecture Overview

The assessment workflow involves three layers: the Kiro IDE as the orchestration surface, the AWS Transform MCP (Model Context Protocol) server as the communication bridge, and the AWS Transform Landing Zone Agent running in the AWS cloud.

Data flow:

1. Kiro's AWS Transform Power sends commands to the MCP server
2. The MCP server authenticates and relays requests to the AWS Transform API
3. AWS Transform creates a job with the Landing Zone Agent
4. The agent assumes the connector's IAM role into the target account
5. The agent inspects AWS Organizations, Control Tower, SCPs, and account structure
6. Findings are returned through the chat interface to Kiro

Components:

• Kiro IDE - Developer workstation with AWS Transform Power activated
• MCP Server (aws-transform-mcp) - Handles Cookie/SSO auth to Transform API, SigV4 auth to AWS account, and Workspace/Job/Task management
• AWS Transform Service - Hosts Workspaces, Jobs, and the VMware Migration Agent v2 (orchestrator) which delegates to the Landing Zone Sub-Agent
• Connector (IAM Role) - Assumes role into the target account for Organizations, Control Tower, and SCP inspection
• Target AWS Account - The account being assessed (AWS Organizations, Control Tower, SCPs, IAM Identity Center, CloudTrail, AWS Config)

Step-by-Step Walkthrough

Step 1: Authenticate to AWS Transform

From your Kiro chat session, the AWS Transform Power connects using cookie-based authentication from an active browser session:

Transform App URL: https://<appID>.transform.us-east-1.on.aws
Auth Mode: cookie

The Power calls get_status to verify both the Transform API connection and the AWS credential chain:

{
  "serverVersion": "0.1.6",
  "connection": {
    "configured": true,
    "authMode": "cookie",
    "region": "us-east-1"
  },
  "sigv4": {
    "configured": true,
    "source": "auto-detected from default credential chain",
    "accountId": "<accountID>",
    "region": "us-east-1"
  }
}

Step 2: Create a Workspace and Job

The Power creates a dedicated workspace and launches a Landing Zone job using the VMware Migration Agent v2 (which orchestrates the Landing Zone sub-agent):

# Create workspace
create_workspace(
  name="LZ-Gap-Assessment",
  description="Landing zone gap assessment for target account"
)

# Create job with the orchestrator agent
create_job(
  workspaceId="<workspaceID>",
  jobName="LZ-Gap-Assessment",
  objective="Perform a landing zone gap assessment. Assess existing AWS Organization structure, identify gaps against AWS best practices. Assessment only - no deployment.",
  intent="Landing zone gap assessment",
  orchestratorAgent="vmware-migration-agent-v2"
)

The agent responds with a workflow selection. For landing zone assessment, we select "Landing Zone" which configures a two-phase plan:

1. Connect target AWS account -- Establish connector with IAM role
2. Build landing zone -- Inspect current state and identify gaps

Step 3: Create and Approve the Target Connector

The connector establishes a trust relationship between AWS Transform and the target account. It requires:

• A KMS key ARN for encryption at rest
• The target account ID
• The target region (must match Control Tower home region if deployed)

# Resolve KMS key for S3 encryption
# aws kms describe-key --key-id alias/aws/s3 --region us-east-1 --query KeyMetadata.Arn --output text

# Create the connector
create_connector(
  workspaceId="<workspaceID>",
  connectorName="lz-assessment-connector",
  connectorType="vmware_migration|infra_provisioning|4",
  configuration={"encryptionKeyArn": "<kmsKeyArn>"},
  awsAccountId="<accountID>",
  targetRegions=["us-east-1"]
)

The connector is created in PENDING status. AWS Transform generates a verification link:

https://us-east-1.console.aws.amazon.com/transform/connector/<connectorID>/configure?region=us-east-1

Opening this link in the AWS Console creates an IAM role with scoped permissions for:

• AWS Organizations read/write operations
• AWS Control Tower management
• CloudFormation stack deployments
• Service Control Policy management
• S3 bucket operations for assessment artifacts

After approval, the connector transitions to ACTIVE:

{
  "connectorId": "<connectorID>",
  "connectorName": "lz-assessment-connector",
  "accountConnection": {
    "awsAccountConnection": {
      "accountId": "<accountID>",
      "roleArn": "arn:aws:iam::<accountID>:role/service-role/AWSTransform-Connector-role-<roleID>",
      "status": "ACTIVE"
    }
  }
}

Step 4: Complete the Connector Task

With the connector active, we submit it to the agent's pending task:

complete_task(
  workspaceId="<workspaceID>",
  jobId="<jobID>",
  taskId="<taskID>",
  content=json.dumps({
    "connectorId": "<connectorID>",
    "connectorType": "vmware_migration|infra_provisioning|4"
  })
)

Step 5: Agent Performs the Assessment

Once the connector task is submitted, the Landing Zone Agent:

1. Assumes the connector IAM role into the target account
2. Calls organizations:DescribeOrganization to detect the Organization
3. Calls organizations:ListRoots and organizations:ListOrganizationalUnitsForParent to map the OU tree
4. Checks for AWS Control Tower deployment status
5. Enumerates existing SCPs via organizations:ListPolicies
6. Compares findings against the AWS recommended baseline:
   • Security OU (Audit + Log Archive accounts)
   • Infrastructure OU
   • Sandbox OU
   • Workloads OU (Production + Non-Production sub-OUs)

The agent returns findings as a structured chat response within 30-60 seconds.

Assessment Findings: Greenfield Example

In our assessment of a greenfield account, the Landing Zone Agent returned the following:

Current State

Root [us-east-1]
  (no OUs defined)
    Management Account -- single account at root

Gap Matrix

Area	Finding	Severity
Multi-account structure	No OUs exist; all workloads in management account	Critical
Security isolation	No Audit or Log Archive accounts	Critical
Governance guardrails	No SCPs applied anywhere	Critical
AWS Control Tower	Not deployed	Critical
Environment separation	No Production / Non-Production boundary	High
Shared infrastructure	No Infrastructure OU	Medium
Developer sandbox	No Sandbox OU	Medium

Key Risk: Workloads in Management Account

The management account holds unrestricted access to the entire Organization. SCPs -- the primary governance mechanism -- cannot restrict the management account. Running workloads here means:

• Any compromise has organization-wide blast radius
• No policy boundary can prevent privilege escalation
• Cost attribution is impossible at the account level

Assessment Findings: Brownfield Example

For organizations with an existing landing zone, the agent detects what is already deployed and reports only the gaps. A typical brownfield finding might look like:

Root [us-east-1]
  Security OU [PRESENT]
    Audit [PRESENT]
    Log Archive [PRESENT]
  Infrastructure OU [PRESENT]
    Shared Services [PRESENT]
  Workloads OU [PRESENT]
    Production [PRESENT]
    Non-Production [PRESENT]
  Sandbox OU [MISSING]

Brownfield gaps identified:

Area	Finding	Severity
Sandbox OU	Missing -- developers share non-production accounts	Medium
Region-deny SCP	Not applied -- workloads can deploy in unapproved regions	High
IAM user creation SCP	Not applied -- long-lived credentials still possible	High

Generating the Report

The AWS Transform Landing Zone Agent delivers findings conversationally through the chat interface. To produce a formal assessment report, we captured the structured findings and generated a professional PDF-ready document with the following structure:

• Executive Summary -- Overall finding: Greenfield or Brownfield with gaps
• Current State Assessment -- Organization tree, Control Tower status, SCP inventory
• Gap Analysis -- Per-domain findings with severity and rationale
• Recommended Target Architecture -- Visual org tree showing recommended structure
• Prioritized Remediation Roadmap -- Phase 1: Foundation, Phase 2: Governance, Phase 3: Workload Accounts

When to Use This Approach

Scenario	Use Landing Zone Gap Assessment
Pre-migration readiness check	Validate landing zone exists before committing to migration timelines
Customer workshops	Generate assessment findings on-the-spot during discovery sessions
Migration Readiness Assessment (MRA)	Automate the Landing Zone pillar of the MRA framework
Brownfield audit	Detect drift or gaps in an existing multi-account environment
Compliance preparation	Identify missing governance controls before audit season

Limitations and Considerations

• Same-Organization requirement: The AWS Transform application account and target account must be in the same AWS Organization. For cross-Organization assessments, deploy a separate Transform instance in the target Organization.

• Connector permissions: The connector IAM role requires broad Organizations and Control Tower permissions. Review the role policy before approving in production environments.

• Assessment only: The Landing Zone Agent can assess and design, but deployment requires explicit approval at every step. No changes are made to the target account during assessment.

• Single region per job: Each landing zone job targets one AWS Region. The connector region must match the Control Tower home region and IAM Identity Center region.

Conclusion

Landing zone readiness is a gate that every migration program must pass through. By combining Kiro's AI-powered development environment with the AWS Transform Landing Zone Agent, platform engineers can assess landing zone gaps in minutes rather than days -- directly from the IDE, without manual account inspection or spreadsheet-based checklists.

The workflow we demonstrated:

1. Authenticated to AWS Transform from Kiro
2. Created a workspace and landing zone assessment job
3. Established a secure connector to the target account
4. Received automated findings against AWS best practices
5. Generated a structured gap report for stakeholder communication

For greenfield environments, this provides a clear remediation roadmap. For brownfield environments, it identifies drift and missing controls that may have been overlooked as the organization grew.

The next step after assessment is action -- the same AWS Transform Landing Zone Agent can design the foundation, generate IaC artifacts (AWS CDK or Landing Zone Accelerator YAML), and deploy the recommended structure with approval-gated workflows.

Appendix: Tool Reference

Tool	Purpose
get_status	Verify Transform API and AWS credential connectivity
create_workspace	Create an isolated workspace for the assessment
create_job	Launch a landing zone job with the orchestrator agent
create_connector	Establish IAM trust to the target account
complete_task	Submit connector details to the agent's pending task
send_message	Communicate with the agent (workflow selection, proceed)
list_resources	Poll for messages, tasks, and artifacts
get_resource	Retrieve connector status, task details, or artifacts

This post demonstrates capabilities available in AWS Transform as of July 2026. Features and agent behavior may evolve. For the latest documentation, visit the AWS Transform User Guide.