Amazon EKS User Guide

Amazon EKS Capabilities are a layered set of fully managed, Kubernetes-native features that run within EKS rather than on your worker nodes. They are designed to accelerate developer velocity by offloading the operational burden of building, scaling, and maintaining foundational platform services like continuous deployment, AWS resource management, and resource orchestration.

Key Characteristics

• Fully Managed: AWS handles security patching, updates, and operational management.
• Resource Efficient: Because they run in EKS rather than on your worker nodes, they do not consume your cluster's compute capacity.
• Kubernetes-Native: You interact with them using standard tools like kubectl and Kubernetes custom resources.
• Independent but Composable: Capabilities are independent cloud resources that can be used individually or together (e.g., using Argo CD and ACK for a complete GitOps workflow).

Constraints

• One per Cluster: You cannot create multiple capability resources of the same type (Argo CD, ACK, or kro) on the same cluster.

The Amazon EKS MCP server is a fully managed service that provides a standardized interface for AI agents and applications to interact with your Amazon EKS clusters and Kubernetes resources. It uses the Model Context Protocol (MCP) to provide real-time, contextual knowledge to AI-powered development and operations workflows.

Key Capabilities

• Cluster Management: Create, configure, and manage EKS clusters using automated best practices.
• Kubernetes Resource Management: Deploy applications, manage resources, and inspect cluster state.
• Troubleshooting: Diagnose issues using integrated troubleshooting tools and runbook knowledge bases.
• Documentation Querying: Contextually search and retrieve relevant EKS documentation.

Key Benefits

• Fully Managed: Hosted in the AWS cloud, eliminating the need for local installation, maintenance, or manual updates.
• Centralized Access Management: Integrates with AWS IAM. All requests are signed using AWS SigV4 through a lightweight proxy, allowing you to use existing AWS credentials and IAM policies.
• Enhanced Monitoring: Integrates with AWS CloudTrail to capture initialization and full access tool calls for audit trails and compliance.
• Always Up-to-date: Automatic updates and bug fixes are delivered without manual intervention.

The Amazon EKS Hybrid Nodes gateway automates networking between your Amazon EKS cluster VPC and Kubernetes pods running on EKS Hybrid Nodes. It eliminates the need to make on-premises pod networks routable from the VPC or coordinate manual network infrastructure changes.

Key Capabilities

• Control plane to webhook communication: Allows the Kubernetes API server to reach webhook endpoints on hybrid nodes.
• Pod-to-pod traffic: Enables direct communication between pods in the VPC (EC2-based) and pods on hybrid nodes (on-premises).
• AWS service connectivity: Allows AWS services like Application Load Balancers (ALB), Network Load Balancers (NLB), and Amazon Managed Service for Prometheus to reach hybrid pods.

Core Mechanisms

• VXLAN tunneling: Creates a hybrid_vxlan0 interface (VNI 2, UDP port 8472) to tunnel traffic to hybrid nodes.
• VPC route table management: The active gateway leader automatically updates VPC route tables to point hybrid pod CIDRs to the leader's primary ENI.
• Cilium VTEP integration: Uses a CiliumVTEPConfig custom resource to instruct Cilium agents on hybrid nodes how to route VPC-bound traffic.
• Leader election: Uses Kubernetes Lease-based leader election in an active-standby model. Failover typically occurs within 3–5 seconds.

EKS access entries provide a centralized way to manage Kubernetes API access using Amazon EKS APIs instead of the legacy aws-auth ConfigMap. An access entry associates an IAM identity (such as an IAM role or user) with specific Kubernetes permissions.

Key Features

• Centralized Management: Control access via EKS APIs, reducing the need to switch between AWS and Kubernetes APIs.
• Granular Permissions: Use access policies or Kubernetes groups to define fine-grained permissions.
• IaC Support: Define access configurations using CloudFormation, Terraform, or AWS CDK.
• Recovery: Restore cluster access via the EKS API if Kubernetes API access is lost.

How to attach permissions

You can grant permissions to an access entry using one of two methods:

1. Access Policies: Use pre-defined Kubernetes permission templates maintained by AWS.
2. Kubernetes Groups: Associate an IAM identity with a Kubernetes group, then use standard Kubernetes RBAC to define what that group can do within the cluster.

Amazon GuardDuty provides threat detection for Amazon EKS clusters through two primary features: EKS Protection and Runtime Monitoring.

EKS Protection

EKS Protection monitors Kubernetes audit logs to identify potential security risks, such as unauthenticated users attempting to tamper with cluster resources. When a threat is detected, GuardDuty generates a Kubernetes audit log finding.

Runtime Monitoring

Runtime Monitoring analyzes operating system-level, networking, and file events to detect threats within specific workloads.

Key requirements and limitations:

• Setup: To use Runtime Monitoring, you must install the GuardDuty agent in your cluster as an Amazon EKS add-on.
• Compatibility: Runtime Monitoring and the GuardDuty agent are not available for Amazon EKS Hybrid Nodes.
• Findings: Threats identified via this method generate a Runtime Monitoring finding.

The Amazon EFS Container Storage Interface (CSI) driver allows Kubernetes clusters on AWS to mount Amazon EFS file systems as persistent volumes. This enables serverless, elastic file storage sharing without managing storage capacity manually.

Key Considerations

• Compatibility: Not compatible with Windows-based container images or Amazon EKS Hybrid Nodes.
• Fargate: You cannot use dynamic provisioning with Fargate nodes; you must use static provisioning.
• Architecture: Version 1.3.2 or later supports Arm64 (including Amazon EC2 Graviton instances).
• TLS/FIPS: Version 1.4.2 or later supports using FIPS for mounting file systems.
• Driver Versions:
  • Dynamic provisioning requires driver version 1.2 or later.
  • Static provisioning works with version 1.1 on supported EKS versions.
• TLS Connections: Starting with version 2.0.0, the driver uses efs-proxy instead of stunnel. efs-proxy opens threads equal to $1 + \text{number of cores}$ on the node.