How to set up KIRO for the AWS Enterprise Tenancy -Part 2

Picking Up Where Part 1 Left Off

In Part 1, we covered the enterprise account architecture for Kiro — why the Kiro profile belongs in a Shared Services account rather than the management account, how it connects cross-account to your IAM Identity Center Organisation instance, and how developers install the IDE and sign in via SSO.

With Kiro installed and your team signed in, the next question is: how does Kiro actually become useful for the work your team does every day?

The answer is MCP — the Model Context Protocol. This is what turns Kiro from a smart autocomplete into an agent that can read your GitHub issues, query your AWS environment, inspect your database schema, or pull design specs from Figma — all from inside a single conversation.

This post covers setting up MCP in Kiro, then walks through concrete use cases for two roles that get disproportionate value from it: the Data Architect / DBA and the Cloud Architect.

What MCP Actually Does for Kiro

Model Context Protocol is an open standard that lets AI agents call external tools and read external data sources through a consistent interface. Instead of Kiro only knowing what's in your open files, an MCP server gives it a live connection to systems outside the IDE — your AWS account, your Git platform, your database, your documentation.

Kiro IDE
└── MCP Client (built in)
    ├── GitHub MCP Server      → issues, PRs, repo metadata
    ├── GitLab MCP Server      → merge requests, CI pipelines
    ├── AWS MCP Server         → 300+ AWS API calls, live account data
    ├── PostgreSQL MCP Server  → schema inspection, query execution
    └── Custom MCP Server      → anything you can wrap in MCP

Each MCP server exposes a defined set of tools — discrete capabilities the agent can choose to call. When you ask Kiro something that needs live data ("what's running in my dev account right now"), it selects the right tool, calls it, and reasons over the result — rather than guessing from training data.

Setting Up MCP in Kiro

Where Configuration Lives

MCP servers are configured per-project in .kiro/settings/mcp.json, or globally in ~/.kiro/settings/mcp.json for servers you want available across every project.

your-repo/
└── .kiro/
    └── settings/
        └── mcp.json    ← project-scoped MCP servers

Basic Configuration Structure

json

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-name"],
      "env": {
        "API_KEY": "${ENV_VAR_NAME}"
      }
    }
  }
}

Never hardcode credentials directly in mcp.json — reference environment variables, and keep those variables out of version control.

Connecting GitHub

json

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Once connected, prompts like "Create a spec from GitHub issue #42" or "Summarise open PRs waiting on my review" work directly.

Connecting GitLab

json

{
  "mcpServers": {
    "gitlab": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-gitlab"],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "${GITLAB_TOKEN}",
        "GITLAB_API_URL": "https://gitlab.com/api/v4"
      }
    }
  }
}

For self-hosted GitLab, point GITLAB_API_URL at your instance.

Connecting the AWS MCP Server

This is the one most relevant to infrastructure and platform teams:

json

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.0",
        "https://aws-mcp.us-east-1.api.aws/mcp"
      ],
      "env": {
        "AWS_MCP_PROXY_PROFILES": "prod-readonly staging dev"
      }
    }
  }
}

This is the multi-account configuration we covered separately — it lets Kiro work across multiple AWS accounts in a single conversation without restarting the session. Pin the proxy version explicitly rather than using @latest.

Verifying the Connection

In Kiro, open the MCP Servers panel (left sidebar). Connected servers show a green status indicator and list their available tools. If a server shows as disconnected, check the command path is correct and that any required CLI tools (npx, uvx) are installed and on your PATH.

Use Cases for the Data Architect / DBA

Data professionals get a different category of value from Kiro than application developers — less about generating new code, more about understanding, documenting, and governing existing data systems.

Use Case 1: Schema Documentation from a Live Database

Connect a PostgreSQL or MySQL MCP server, then ask:

"Connect to the reporting database and generate a data dictionary
 for every table in the analytics schema — include column types,
 foreign key relationships, and any tables with no primary key."

Kiro queries the live schema, builds the documentation, and can save it directly into a spec under .kiro/specs/data-dictionary/. This becomes a maintainable, version-controlled artefact rather than a one-time export that goes stale within a month.

Use Case 2: Migration Planning — Schema Diff Across Environments

"Compare the schema in the dev database against the schema in
 production. Flag any tables, columns, or indexes that exist in
 one but not the other, and draft a migration script to reconcile them."

This is a Spec-Driven Development moment — Kiro can generate the requirements (what's different), the design (the migration approach), and the tasks (the actual DDL scripts), giving you a reviewable plan before any schema change touches production.

Use Case 3: Data Lineage and Impact Analysis

"I'm planning to rename the customer_id column in the orders table.
 Search the codebase and any connected dbt models for every place
 this column is referenced, and list what would break."

Combined with a GitHub or GitLab MCP connection, Kiro can search across repositories — application code, ETL pipelines, dbt models, Terraform-managed RDS configs — to build a genuine impact assessment before a breaking schema change ships.

Use Case 4: NZISM-Aligned Data Classification Review

"Review the table definitions in this schema and flag any columns
 that look like they contain PII — names, emails, IP addresses,
 national ID numbers — that don't currently have column-level
 encryption or masking applied."

This won't replace a formal data classification exercise, but it's a fast first-pass scan that surfaces obvious gaps before a compliance review — useful groundwork ahead of an NZISM or Privacy Act assessment.

Use Case 5: Query Performance Investigation

"This query has been running slow in production. Here's the
 EXPLAIN output. Connect to the database, check the table statistics
 and existing indexes, and suggest what's missing."

Kiro can combine the live EXPLAIN ANALYZE output with direct schema inspection via MCP, rather than you manually copying query plans back and forth.

Steering File for Data Teams

.kiro/steering/data-standards.md
─────────────────────────────────
- All new tables require a primary key and created_at/updated_at columns
- PII columns must be tagged in column comments: -- PII:email
- No SELECT * in production views — explicit column lists only
- Migration scripts must be reversible (include a down migration)

Once committed, every Kiro interaction touching the database respects these conventions automatically — no need to repeat them in every prompt.

Use Cases for the Cloud Architect

For Cloud Architects, the value sits at the intersection of the AWS MCP Server (live account access) and Kiro's spec-driven workflow (structured design before implementation).

Use Case 1: Landing Zone Drift Detection

"Compare the actual SCPs attached to each OU in my AWS Organization
 against what's defined in the landing-zone Terraform module. Flag
 any drift — anything applied manually that isn't in the IaC."

With multi-account MCP profiles configured, Kiro queries Organizations and Terraform state side by side and surfaces exactly where reality has diverged from the intended architecture — a recurring problem in any environment that's had more than one engineer with console access.

Use Case 2: Cross-Account Security Posture Review

"Check Security Hub findings across the management, audit, and
 production accounts. Summarise any CRITICAL or HIGH findings that
 appear in production but are absent in audit — those are likely
 either unmonitored or recently introduced."

This is exactly the cross-account MCP pattern from our earlier post — a single conversation spanning three accounts without restarting the session each time you switch context.

Use Case 3: Generating a Network Architecture Spec from an Existing VPC

"Connect to the networking account and inspect the current VPC,
 subnets, route tables, and Transit Gateway attachments. Generate
 a design document describing the current state, then propose a
 design for adding a new Auckland region VPC that peers correctly
 with the existing Sydney hub."

Kiro produces this as a proper spec — requirements.md capturing what the new VPC needs to achieve, design.md with the actual architecture, and tasks.md breaking it into Terraform changes. This is materially faster than manually documenting current-state network architecture by clicking through the console.

Use Case 4: IAM Least-Privilege Review

"Review the IAM roles in the shared-services account. Identify any
 roles with policies broader than what their actual CloudTrail
 activity over the last 90 days would justify, and draft a
 tightened policy for each."

This combines AWS MCP Server access (CloudTrail data, current IAM policies) with Kiro's reasoning to produce a concrete, reviewable least-privilege proposal rather than a generic "you should review your IAM policies" recommendation.

Use Case 5: Control Tower Guardrail Gap Analysis

"List all Strongly Recommended Control Tower guardrails. Cross-reference
 against what's currently enabled in my Organization and tell me
 which recommended guardrails are missing, with a one-line explanation
 of what risk each one mitigates."

A genuinely useful pre-audit exercise that turns a manual AWS documentation cross-reference exercise into a single prompt.

Use Case 6: Multi-Account Cost Anomaly Investigation

"Compare this month's Cost Explorer data for the dev and staging
 accounts against the prior three-month average. Flag any service
 with greater than 30% cost increase and check what changed in
 the corresponding Terraform repo around that time."

Particularly valuable when you're managing cost across multiple client engagements and need a fast first-pass triage before a deeper FinOps review.

Steering File for Cloud/Platform Teams

.kiro/steering/aws-architecture-standards.md
──────────────────────────────────────────────
- All new VPCs use /20 CIDR blocks minimum, tagged with Environment and CostCentre
- No IAM policies with wildcard ("*") actions or resources without explicit justification
- All S3 buckets require SSE-KMS encryption and block-public-access enabled
- Terraform state must use S3 backend with DynamoDB locking — no local state
- New accounts must pass through Control Tower account factory, never created manually

Why This Matters for Both Roles

The common thread across every example above: Kiro isn't writing fictional, plausible-sounding infrastructure or schema descriptions. It's reasoning over live data retrieved through MCP — the actual schema, the actual Security Hub findings, the actual CloudTrail activity. That distinction is what makes the output something you can act on rather than something you need to independently verify before trusting.

For consulting engagements specifically, this combination — multi-account MCP access plus spec-driven documentation — turns discovery work (the "Assessment" phase of a MAP engagement) from days of manual console review into structured, reviewable specs generated directly from the client's live environment.

What's Next

Part 3 of this series moves up a layer — from using Kiro as a development and discovery tool to building production AI agents on Amazon Bedrock, AgentCore, and the Strands Agents SDK. We'll cover when to use a Bedrock Managed Agent versus a custom AgentCore deployment, how to connect an agent to your AWS environment securely via AgentCore Gateway, and how Kiro itself can be used to scaffold and deploy these agents using the AgentCore CLI.