AWS

AWS Model Context Protocol (MCP) servers for Lambda, EKS, ECS, and Finch — what platform teams must secure

AWS added Model Context Protocol (MCP) servers for Lambda, ECS, EKS and Finch — a privileged runtime surface platform teams must secure with IAM, network, logs.

September 13, 2026·3 min read·AI researched · AI written · AI reviewed

AWS just handed platform teams a new attack surface: Model Context Protocol (MCP) servers attached to runtime surfaces — Lambda, ECS, EKS, and Finch. On paper this is about making AI-assisted workflows more seamless for developers; in reality it changes where and how model-driven agents interact with live infrastructure, and most teams don’t have policies and telemetry wired up for that yet.

MCP servers are not a lightweight SDK. They expose contextual access to execution environments so models and agents can suggest code, configuration, or even remediation steps with rich context about the running workload. AWS surfaced MCP servers for Lambda, Amazon ECS, Amazon EKS, and Finch, which means model-driven tooling can be given environment metadata, logs, or file-system snippets coming directly from your workloads — across serverless and containers.

Treat this like an extension of your trust boundary. Today your attack surfaces are clear: instance metadata, IAM, network endpoints, and the control plane. MCP blends those: if an agent can receive pod context or function state and return actions or code, you now have an interactive channel into runtime. IAM and network policies that only consider API calls miss this entirely. Teams that ignore MCP risk privilege creep and audit blind spots.

Quick, concrete signals from the week:

  • AWS listed new MCP servers for Lambda, ECS, EKS, and Finch to support AI-assisted development workflows.
  • Lambda showed public preview runtimes for Node.js 20 and Python 3.11.
  • Amazon Bedrock added new service tiers focused on balancing performance and cost — a pricing/throughput lever, not a new model family.
  • Amazon EKS added a centralized dashboard with improved cross-account and cross-region visibility for clusters.

What this actually means for platform engineering

First, IAM and service identity. Treat MCP like any credentialed runtime metadata service: use scoped roles, short-lived credentials, and explicit allow/deny for which models or agent types can access which cluster namespaces, function environments, or container tasks. If you’ve been lax about service-account policies on EKS, tighten them now.

Second, network segmentation. Run MCP-facing endpoints behind private VPC endpoints, restrict egress to known model endpoints, and consider per-environment NAT or proxying to limit accidental data exfiltration. Higher throughput and easier model integrations make exfiltration easier, not safer.

Third, observability and audit trails. Log every MCP request and response, correlate them with pod and function lifecycles, and push those logs into your SIEM. Most observability pipelines correlate HTTP calls and metric events — they don’t expect an LLM to suggest a hotfix and a human to paste it into a running container. That chain needs tracing and preserved provenance.

Bedrock’s new tiers are a pricing and throughput control, not a security boundary. If your teams optimize inference cost, treat Bedrock tiers as another tuning knob, but don’t assume tier changes alter model trust or isolation guarantees.

EKS’s improved dashboard is an ops win for visibility, but visibility isn’t governance. Dashboards help you see MCP activity; they don’t prevent it.

Final take: AWS is productizing model context delivery into runtimes in a sensible way, but platform teams must stop treating AI tooling as merely a developer convenience and start treating it as a privileged integration. Lock down MCP like any runtime metadata service: scoped identities, network controls, and full provenance in logs. If you don’t, the convenience of an AI agent becomes the fastest path to silent, authorized changes in production.

If you’ve been postponing an IAM cleanup or egress segmentation project because it’s “nice to have,” consider this the deadline. Platforms that anticipate and codify MCP controls will turn developer productivity gains into safe, auditable features — teams that don’t will be firefighting next quarter.

Related reading: for more on Bedrock and Lambda interactions with fast model-loading and execution patterns, see Amazon Bedrock adds Astra model family; EKS fast-loading patterns and Lambda SnapStart impacts.

Sources

awsmodel-context-protocolaws-lambdaamazon-eksamazon-bedrock
← All articles
AWS

AWS EBS Volume Clones: Cross-account copy with KMS re-encryption

AWS EBS clones can be copied across accounts and re-encrypted with a destination KMS key, removing snapshot-share complexity for multi-account workflows.

Sep 11, 2026·3mamazon-ebsebs-volume-clones
AWS

AWS Lambda Managed Instances: 90-minute async timeouts and Graviton5 support

AWS Lambda Managed Instances now allow 90-minute async and event-source timeouts and Graviton5 instance support, shifting longer batch and inference jobs to managed hosts.

Sep 10, 2026·3maws-lambdagraviton5
AWS

Amazon Bedrock adds Astra model family; EKS fast-loading patterns and Lambda SnapStart impacts

AWS Bedrock added an Astra model family and expanded model access. EKS fast-loading patterns and Lambda SnapStart change startup, cache, and tenancy trade-offs.

Sep 9, 2026·3mamazon-bedrockastra