Rethinking EKS Management: Kiro Meets AWS MCP Server

Why EKS Management Needs Rethinking

Managing Amazon EKS with kubectl and ad-hoc scripts doesn’t scale. This post shows how Kiro, an agentic AI IDE, combined with the AWS EKS MCP Server, enables intent-driven, human-approved, and auditable EKS operations—without direct cluster access. It’s a safer, more structured approach designed for modern platform teams.

What usually starts as a clean Kubernetes cluster slowly turns into a mix of kubectl commands, Terraform modules, IAM policies, shell scripts, and tribal knowledge. Simple tasks—like understanding cluster state, enforcing access, or making safe operational changes—end up spread across multiple tools and workflows.

At some point, you realize the real challenge isn’t Kubernetes itself. It’s how we manage it.

In this post, I explore a different approach to EKS management using Kiro as an intelligent control layer, backed by the AWS MCP Server. Instead of relying on manual commands and ad-hoc automation, this model focuses on intent-driven operations, better visibility, and more predictable control over EKS environments.

If you’ve ever felt that EKS management could be simpler, more structured, and less fragile—this one’s for you.

What is Kiro?

It is an agentic AI Integrated Development Environment (IDE) built to translate high-level intent into structured plans and coordinated changes—with human review always in the loop.

Think of Kiro as a tech lead in a box. You describe the outcome you want, and Kiro drafts a spec, proposes a plan, and carries out the changes while presenting clear diffs for approval. Nothing runs implicitly. Every action is visible, reviewable, and auditable.

When applied to Amazon EKS, this model becomes especially effective. Instead of operators memorising kubectl commands, IAM policies, or AWS API sequences, Kiro shifts the focus to what needs to happen—not how to execute it. The actual execution is handled by backend systems such as the AWS MCP Server, which act as controlled interfaces to cloud resources.

From an EKS management perspective, Kiro operates at a higher level of abstraction. It doesn’t shell out commands or scatter credentials across scripts. Instead, it coordinates changes through structured APIs and predefined workflows. This allows platform teams to enforce consistency, security boundaries, and operational standards without slowing teams down.

At a high level, Kiro enables:

• Intent-driven EKS operations (for example: scaling node groups or inspecting cluster health)
• Human-in-the-loop automation, with explicit approval at every step
• Centralized control without direct infrastructure access
• Auditable workflows, suitable for regulated environments
• Reduced cognitive load when managing Kubernetes at scale

For platform and SRE teams operating multiple EKS clusters across accounts and environments, Kiro provides a more structured and reliable alternative to ad-hoc scripts and manual workflows.

In the next section, we’ll look at how Kiro integrates with the AWS MCP Server and why that pairing changes the way EKS clusters are managed.

What is AWS MCP Server?

The AWS Model Context Protocol (MCP) Server is the backbone that makes controlled, scalable EKS operations possible. It acts as a centralised API gateway between your management tools—like Kiro—and your Kubernetes clusters.

Instead of giving developers or scripts direct access to cluster APIs, the MCP Server enforces access boundaries, role-based permissions, and audit logging, ensuring that every change is safe, intentional, and traceable.

In practice, this means:

• All API calls are centralised through the MCP Server
• Role-based access control prevents accidental or unauthorised operations
• Auditability ensures you can track who did what and when
• Consistency across clusters, even across accounts and regions

When combined with Kiro, the MCP Server becomes the trusted execution layer. Kiro proposes and coordinates changes, while MCP validates, enforces policies, and executes them on the EKS clusters. Together, they shift cluster management from scattered scripts and manual commands to intent-driven, auditable workflows.

Architecture Overview

At a high level, the workflow of managing EKS clusters with Kiro and AWS MCP Server can be visualised in three layers:

Developer / Platform Team
Users describe the outcome they want—whether it’s scaling a node group, creating a namespace, or inspecting cluster health. This high-level intent is passed to Kiro.

Kiro (Agentic AI IDE)
Kiro acts as the central intelligence. It translates the user’s intent into a structured plan, proposes the steps, and coordinates execution while keeping human approval in the loop. Every change is auditable and visible, reducing errors and guesswork.

AWS MCP Server & EKS Clusters
The MCP Server acts as a controlled gateway to EKS clusters. It enforces access policies, RBAC, and audit logging. Kiro sends approved plans to MCP, which then executes the operations on one or multiple EKS clusters in a consistent and secure manner.

Key takeaways of this architecture:

• Separation of intent and execution reduces risk and complexity.
• Human-in-the-loop automation ensures changes are reviewed and auditable.
• Multiple clusters across accounts and regions can be managed consistently.
• Platform teams gain a repeatable workflow without exposing raw cluster access.

How Kiro Interacts with EKS via MCP?

The interaction between Kiro and EKS clusters via the AWS MCP Server is designed to simplify operations while maintaining control, security, and auditability. Here’s how it works step by step:

User Intent
A developer or platform engineer defines a high-level goal, like “scale this node group” or “create a new namespace with access policies.” Kiro captures this intent instead of relying on raw commands.

Planning & Proposal
Kiro translates the intent into a structured plan, generating a sequence of actions that need to happen across cluster resources. The proposed plan is presented to the user for review, ensuring human approval before execution.

MCP Server Enforcement
Once approved, Kiro sends the plan to the AWS MCP Server. MCP acts as a centralised control plane, validating permissions, enforcing policies, and coordinating the actions across the target EKS clusters.

Execution on EKS & Feedback
MCP executes the approved operations on the EKS clusters. Feedback—success, errors, or warnings—is sent back to Kiro, which updates the plan state and notifies the user. This loop ensures full visibility and auditability.

Audit & Logging
Every step—intent capture, plan proposal, approval, execution—is logged. This makes it easy to track who did what, when, and why, which is critical for platform teams and regulated environments.

Why this approach matters

• Reduces errors from direct kubectl commands or ad-hoc scripts.
• Scales safely across multiple clusters and accounts.
• Maintains compliance with centralised auditing and RBAC.
• Keeps humans in the loop, so automation doesn’t become a blind process.

Architecture diagram:

An intent-driven EKS management flow where Kiro plans and reviews changes, and the AWS MCP Server enforces and executes them.

Kiro vs kubectl and Terraform

Traditional EKS management with kubectl and Terraform focuses on execution primitives: you apply manifests, run commands, or converge infrastructure state, often with direct access to the cluster or AWS APIs. While powerful, these tools assume deep context, careful sequencing, and disciplined workflows—especially at scale. Kiro takes a different approach by operating at the intent and planning layer. Instead of executing immediately, it proposes structured changes, requires human approval, and delegates execution to the AWS MCP Server, which enforces policies and auditability. Rather than replacing kubectl or Terraform, Kiro complements them by providing a safer, more controlled interface for day-to-day EKS operations across teams and environments.

Demo / Workflow Example

Prerequisites

Before starting, make sure you have:

• Kiro IDE installed on your system
• An AWS account with permissions for EKS
• An existing EKS cluster. Note-You can create new cluster using Kiro as well but it is out of scope for this blog.
• AWS CLI installed and configured
• AWS EKS MCP Server

Step 1: Install Kiro

Kiro runs locally as an IDE-style interface where you define intent, review plans, and approve changes.

1. Install IDE from the link as per your system OS https://kiro.dev/downloads/

2. Kiro CLI for macOS and Linux
   

curl -fsSL https://cli.kiro.dev/install | bash

Step 2: Configure AWS Credentials

Kiro relies on standard AWS authentication mechanisms. Configure your default profile:

aws configure

Or verify an existing profile:

aws sts get-caller-identity

Kiro does not directly execute AWS or Kubernetes commands—it delegates execution to the MCP Server.

Step 3: Instruct Kiro to Install and Configure MCP

1. Use the config details from https://awslabs.github.io/mcp/servers/eks-mcp-server

Please see below example config.

{
  "mcpServers": {
    "awslabs.eks-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest",
        "--allow-write",
        "--allow-sensitive-data-access"
      ],
      "env": {
        "AWS_PROFILE": "kiro-eks-demo",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

Kiro analyses the config and generates a plan that includes:

• Installing the MCP Server runtime
• Binding AWS credentials securely
• Applying configuration settings
• Validating EKS API access
• Enabling audit logging

Nothing executes yet.

Step 4: Review and Approve the Plan

• Kiro presents the full setup plan, step by step:
• What will be installed
• What permissions will be used
• What validations will run
• After review, approve the plan.

Kiro then orchestrates the MCP Server installation and configuration.

Step 5: Perform an EKS Operation Using Intent

From here on:

• Kiro handles intent and planning
• MCP handles policy enforcement and execution
• Users never touch the cluster directly

Now that MCP is configured, instruct Kiro:

In Kiro, describe the desired outcome:

• Create a namespace called eksdemomcpns.
• Create new deployment eksmcpdemo.
• Check deployment, service, load balancer status.

No commands. No manifests. Just intent.

Kiro generates a plan:

• Namespace creation
• Deployment creation

Step 6: Approve and Execute

After approval:

• Kiro submits the plan to MCP
• MCP enforces policies and permissions
• MCP executes the changes against EKS
• All actions are logged

Execution happens only after explicit approval.

Namespace creation:

Deployment creation

Kiro instructed MCP server and created new deployment and associated service!!

Step 7: Observe Results

Kiro reports:

• Namespace created
• Access applied
• No policy violations detected

The cluster state is updated without direct cluster access or kubectl usage.

This workflow demonstrates a clear separation of duties:

• Intent & review → Kiro
• Policy & execution → MCP Server
• Infrastructure access → tightly controlled

Benefits & Trade-offs

Adopting Kiro with the AWS MCP Server introduces a different way of managing EKS—one that prioritizes intent, control, and auditability. Like any architectural choice, it comes with clear benefits and real trade-offs.

Benefits

Intent-driven operations:
Teams describe what they want to achieve rather than how to execute it. This reduces cognitive load and lowers the risk of operational mistakes.

Human-in-the-loop safety:
Every change is reviewed and approved before execution. This makes production operations safer and more predictable, especially for shared or regulated environments.

Centralised policy enforcement:
The MCP Server ensures all EKS interactions follow defined permissions, RBAC rules, and organisational policies—no matter who initiates the change.

Auditability by default:
From intent to execution, every step is logged. This is particularly valuable for compliance, incident review, and operational transparency.

Scales across clusters and teams:
The same workflow applies consistently across multiple EKS clusters, AWS accounts, and environments, without granting broad cluster access.

Trade-offs

Slower than direct CLI for ad-hoc tasks:
For quick experiments or one-off debugging, direct kubectl access is faster. Kiro intentionally optimises for safety and consistency over speed.

Requires upfront setup:
Introducing MCP and defining policies adds initial complexity. Teams need to invest time in configuration before seeing long-term gains.

Not a replacement for IaC:
Kiro complements tools like Terraform; it doesn’t replace them. Infrastructure provisioning and cluster lifecycle management still belong in IaC workflows.

Best suited for platform teams:
Smaller teams or personal clusters may find this approach heavyweight. The benefits compound as the number of clusters and users grows.

When this approach makes sense

• Platform or SRE teams managing multiple EKS clusters
• Environments with compliance or audit requirements
• Organisations moving away from shared cluster admin access
• Teams standardising operational workflows

Conclusion

Managing Amazon EKS doesn’t have to mean juggling kubectl, YAML files, scripts, and tribal knowledge. As clusters, teams, and environments grow, those approaches become fragile, hard to audit, and difficult to scale.

Kiro, combined with the AWS MCP Server, introduces a different model—one that separates intent, planning, and execution. By moving cluster operations behind reviewed plans, centralized policy enforcement, and auditable workflows, EKS management becomes safer and more predictable without slowing teams down.

This approach isn’t about replacing Kubernetes primitives or infrastructure-as-code. It’s about improving how humans interact with them. Platform teams gain control and consistency, developers gain clarity, and organisations gain confidence in how changes reach production.

If your EKS operations are starting to feel complex, brittle, or risky, it may be time to rethink not what tools you use—but how you use them.