← Blog
#AWS#Kubernetes#MCP#DevOps#AI

AWS's EKS MCP Server: Natural-Language Kubernetes Needs Guardrails First

webhani·

EKS now speaks MCP

AWS has released a fully managed EKS MCP Server in preview, letting AI coding assistants interact with Kubernetes clusters in natural language through the Model Context Protocol (MCP). Alongside it, AWS also announced the DevOps Agent (preview), which brings agentic reasoning to Kubernetes operations.

Webhani manages Kubernetes for several client infrastructure projects, so we needed to work out how far natural-language cluster operations can realistically go before we'd recommend it. Here's where we landed.

What changes with MCP

Checking cluster state or troubleshooting an issue traditionally meant assembling kubectl commands by hand. With the EKS MCP Server, an MCP-aware client like Claude Code can translate a prompt like "show me the pods stuck in CrashLoopBackOff in the default namespace" directly into the corresponding cluster operation.

// .mcp.json (example MCP client config, e.g. for Claude Code)
{
  "mcpServers": {
    "eks": {
      "command": "aws-eks-mcp-server",
      "args": ["--cluster", "prod-cluster", "--region", "ap-northeast-1"]
    }
  }
}

Not having to remember every kubectl flag to get moving on an incident is a real practical win. But that same convenience means natural language can now trigger operations against a production cluster — and that deserves careful handling.

Paired with the DevOps Agent

The DevOps Agent goes further with agentic reasoning: rather than executing a single command, it can plan and carry out a multi-step operational task autonomously. Given a vague instruction like "figure out why this service's latency degraded and fix it," it could plausibly chain log inspection, metric lookups, and scaling adjustments into one continuous flow.

That's powerful, but the wider the scope of actions an AI can decide and execute on its own, the more the risk of an unintended production change grows in proportion. When we introduce this kind of agentic operation for a client, we treat the following as non-negotiable:

  • Separate read-only access from mutating operations — hand out read-only credentials during investigation, and gate any actual change behind a separate approval step
  • Route mutating operations through a dry run — kubectl apply --dry-run output or an IaC plan should always get a human review before it's applied
  • Keep an independent audit trail — store the MCP server's operation history in a form that can be cross-checked against the cluster's own Kubernetes audit log

A complementary piece: faster container startup

AWS also announced Seekable OCI (SOCI) Parallel Pull mode around the same time, claiming up to 60% faster startup for AI containers with large model files. As the DevOps Agent starts making autonomous decisions about scaling and pod restarts, startup latency feeds directly into overall operational responsiveness. The two features are unrelated technically, but in the context of running AI workloads on Kubernetes, they reinforce each other.

A checklist before adopting this

We work through a fixed sequence when proposing tools like this to clients:

  1. Trial the MCP connection in staging first — verify how natural-language operations actually behave with scoped-down permissions before pointing it at production
  2. Enumerate dangerous operation patterns — explicitly deny high-impact operations like namespace deletion, Secret access, or RBAC changes
  3. Define where human review kicks in — agree as a team on exactly which operations are auto-approved and which require explicit confirmation
  4. Integrate with existing monitoring and alerting — make sure MCP-driven operations flow into your existing alert paths on failure

Takeaway

The EKS MCP Server and DevOps Agent have real potential to lower the barrier to Kubernetes operations — faster incident response and less reliance on memorized kubectl syntax are genuine practical gains. But being able to operate production infrastructure in natural language means your permission design and review process become the actual safety boundary. We recommend adopting agentic DevOps tools like this only alongside a deliberately designed set of guardrails, not on their own.

Source: AWS at KubeCon EU 2026 (aws.amazon.com/blogs/containers)

← Back to Blog