---

name: aws-eks compatibility: opencode completeness: 95 content-types:

• guidance
• examples
• do-dont
• config description: '"Deploys managed Kubernetes clusters with EKS for container orchestration" auto-scaling, networking, and integrations with AWS services for production Kubernetes workloads.' license: MIT maturity: stable metadata: domain: cncf output-format: manifests related-skills: aws-cloudwatch, aws-ecr, aws-iam, aws-vpc role: reference scope: infrastructure triggers: eks, container orchestration, k8s, cluster, pods, namespaces, ingress, kubernetes namespace archetypes:
  • educational
  • strategic anti_triggers:
  • brainstorming
  • vague ideation
  • non-containerized architecture response_profile: verbosity: medium directive_strength: low abstraction_level: strategic version: "1.0.0"

---

EKS (Elastic Kubernetes Service)

Deploy and manage production-grade Kubernetes clusters with automatic control plane updates, high availability, and deep AWS service integration.

TL;DR Checklist

• Use managed node groups for automatic scaling
• Enable multiple AZs for high availability
• Configure RBAC with IAM Roles for Service Accounts (IRSA)
• Use AWS Load Balancer Controller for ingress
• Enable cluster logging to CloudWatch
• Configure network policies for security
• Use Fargate for serverless pods
• Enable Pod Security Policy or Pod Security Standards
• Monitor cluster metrics with CloudWatch
• Regular cluster and node updates

---

When to Use

Use EKS when:

• Running containerized microservices
• Needing Kubernetes orchestration
• Requiring managed Kubernetes (no control plane management)
• Building scalable container applications
• Integrating with AWS services from containers

---

When NOT to Use

Avoid EKS when:

• Simple workloads better served by Fargate only
• Self-managed K8s preferred (use EC2 + kubeadm)
• Minimal operational overhead needed (use App Runner)

---

Purpose and Use Cases

Primary Purpose: Provide fully managed Kubernetes control plane with integration to AWS services, eliminating control plane management overhead.

Common Use Cases:

1. Microservices — Deploy service mesh (Istio/Linkerd)
2. Data Processing — Run Apache Spark, Hadoop jobs
3. CI/CD Pipelines — Build runners, artifact processing
4. API Services — High-scale REST/gRPC APIs
5. Batch Jobs — Scheduled batch processing

---

Architecture Design Patterns

Pattern 1: EKS Cluster with Managed Node Groups

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  # EKS Cluster IAM Role
  EKSServiceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: eks.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSServiceRolePolicy

  # EKS Cluster
  EKSCluster:
    Type: AWS::EKS::Cluster
    Properties:
      Name: production-cluster
      Version: 1.27
      RoleArn: !GetAtt EKSServiceRole.Arn
      ResourcesVpcConfig:
        SubnetIds:
          - subnet-0123456789abcdef0
          - subnet-0123456789abcdef1
          - subnet-0123456789abcdef2
        SecurityGroupIds:
          - sg-0123456789abcdef0
        EndpointPrivateAccess: true
        EndpointPublicAccess: true
      Logging:
        ClusterLogging:
          - LogTypes:
              - api
              - audit
              - authenticator
              - controllerManager
              - scheduler
            Enabled: true
      Tags:
        Environment: production

  # Node Group IAM Role
  NodeGroupRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser

  # Managed Node Group
  NodeGroup:
    Type: AWS::EKS::NodeGroup
    Properties:
      ClusterName: !Ref EKSCluster
      NodeRole: !GetAtt NodeGroupRole.Arn
      Subnets:
        - subnet-0123456789abcdef0
        - subnet-0123456789abcdef1
        - subnet-0123456789abcdef2
      ScalingConfig:
        MinSize: 2
        MaxSize: 10
        DesiredSize: 3
      InstanceTypes:
        - t3.medium
        - t3.large
      DiskSize: 100
      Tags:
        Name: production-nodes

Key Elements:

• EKS cluster with managed control plane
• Multi-AZ for high availability
• Managed node group with auto-scaling
• CloudWatch logging enabled
• IAM roles for service and nodes

Pattern 2: IRSA (IAM Roles for Service Accounts)

Resources:
  # OIDC Provider for IRSA
  EKSOIDCProvider:
    Type: AWS::IAM::OIDCProvider
    Properties:
      Url: !Sub 'https://oidc.eks.${AWS::Region}.amazonaws.com/id/${EKSClusterOID}'
      ClientIdList:
        - sts.amazonaws.com

  # Service Account Role
  ServiceAccountRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Federated: !Sub 'arn:aws:iam::${AWS::AccountId}:oidc-provider/oidc.eks.${AWS::Region}.amazonaws.com/id/${EKSClusterOID}'
            Action: sts:AssumeRoleWithWebIdentity
            Condition:
              StringEquals:
                'oidc.eks.${AWS::Region}.amazonaws.com/id/${EKSClusterOID}:sub': 'system:serviceaccount:default:app-sa'

  # Application Policy
  AppPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: app-s3-access
      Roles:
        - !Ref ServiceAccountRole
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - s3:GetObject
              - s3:PutObject
            Resource: arn:aws:s3:::app-bucket/*

Key Elements:

• OIDC provider for service account federation
• Pod can assume IAM role without credentials
• Fine-grained permissions per service account

---

Integration Approaches

1. Integration with ECR

EKS + ECR provides:

• Container image registry
• Pod pulls images directly from ECR
• No Docker Hub dependency

2. Integration with AWS Load Balancer Controller

ALB/NLB integration enables:

• Kubernetes Ingress resources map to ALBs
• Service type LoadBalancer creates NLBs
• Native AWS load balancing

3. Integration with CloudWatch

CloudWatch + EKS provides:

• Cluster metrics and logs
• Application performance insights
• Operational dashboards

4. Integration with VPC

VPC integration provides:

• Pod networking in VPC subnets
• Security groups for pod-level control
• Network policies for microsegmentation

---

Common Pitfalls

❌ Pitfall 1: Single AZ Cluster

Problem: AZ failure causes complete outage.

Solution:

• Deploy node groups across 3+ AZs
• Use managed node groups for auto-scaling

❌ Pitfall 2: No RBAC

Problem: Cluster access uncontrolled; security risk.

Solution:

• Enable RBAC (default)
• Use IRSA for pod permissions
• Restrict cluster access via security groups

❌ Pitfall 3: Pod Security Uncontrolled

Problem: Containers run as root; privileged pods.

Solution:

• Enable Pod Security Standards
• Enforce restricted policy
• Regular security audits

❌ Pitfall 4: No Log Aggregation

Problem: Cluster issues hard to troubleshoot.

Solution:

• Enable control plane logging
• Stream to CloudWatch
• Archive to S3 for long-term

---

Best Practices Summary

Category	Best Practice
Availability	Multi-AZ node groups; managed updates
Security	RBAC; IRSA; network policies; PSS
Scaling	Cluster Autoscaler; HPA for pods
Monitoring	CloudWatch logs; Prometheus/Grafana
Updates	Regular cluster and node updates

---

Related Skills

Skill	Purpose
cncf-aws-ecr	Container image storage
cncf-aws-vpc	Networking for pod communication
cncf-aws-iam	IRSA and role management
cncf-aws-cloudwatch	Cluster monitoring

---

Core Workflow

1. Assess Requirements — Understand the use case, scale, integration needs, and existing infrastructure. Checkpoint: Document requirements, constraints, and success criteria.

2. Design Architecture — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. Checkpoint: Verify the architecture addresses all requirements and follows CNCF conventions.

3. Implement & Configure — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. Checkpoint: Validate all YAML against schema and test in a staging environment.

4. Deploy & Monitor — Apply manifests to the cluster, verify component health, and confirm observability is working. Checkpoint: Confirm all pods/services are running, probes passing, and metrics/alerts configured.

---

Constraints

MUST DO

• Include at least one complete working YAML manifest example
• Note when content is auto-generated vs. manually verified
• Reference relevant CNCF project documentation

MUST NOT DO

• Deploy manifests without testing in a staging environment first
• Use deprecated API versions (e.g., apps/v1beta1)
• Omit resource limits and requests in Kubernetes manifests