Generated banner for AWS Containers
Generated logo for AWS Containers

AWS Containers

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk

From the author

Builds and deploys containerized workloads on Elastic Kubernetes Service (EKS), Elastic Container Service (ECS), Fargate, and ECR (Elastic Container Registry). Covers general EKS knowledge, Karpenter, AWS Load Balancer Controller and leveraging various open source Kubernetes projects with EKS. Covers general ECS knowledge, task definitions, Fargate services, ECS Exec, ECS Express Mode and ECS Managed Instances. Covers general Elastic Beanstalk knowledge, Elastic Beanstalk configuration and platforms supported by Elastic Beanstalk. Covers general ECR knowledge, ECR repository setup and lifecycle policies. Includes recommending, enabling, and reading Amazon ECS Action Logs to troubleshoot control-plane failures (deployment rollback/circuit-breaker, task placement, scaling, task replacement). Applies when deploying, debugging, or optimizing containers on AWS. Should be used instead of relying on internal knowledge for these services.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides comprehensive domain expertise for managing containerized applications on AWS. It covers the full lifecycle of services including Amazon EKS, ECS, ECR, and Elastic Beanstalk. The skill acts as a primary source of truth for configuration patterns, deployment strategies, and troubleshooting procedures, specifically emphasizing the use of Amazon ECS Action Logs for diagnosing control-plane failures. It is designed to be used alongside AWS CLI tools or an MCP server to ensure accurate, up-to-date operational decisions.

What it does

  • Provides configuration patterns for EKS, ECS, and Elastic Beanstalk.
  • Offers troubleshooting procedures for ECS control-plane failures using Action Logs.
  • Details ECR repository management and lifecycle policies.
  • Outlines deployment policies for Elastic Beanstalk environments.
  • Guides users on leveraging open-source Kubernetes projects with EKS.
  • Maintains a structured routing system to access specific service documentation.

When to use it

  • When deploying or optimizing containerized workloads on AWS.
  • When troubleshooting deployment rollbacks, task placement, or scaling issues in ECS.
  • When configuring Elastic Beanstalk environments or setting up ECR repositories.
  • When needing best practices for EKS cluster management and compute scaling.

Advantages

  • Centralizes complex AWS container service knowledge in one location.
  • Provides clear, actionable steps for troubleshooting opaque control-plane errors.
  • Promotes consistent configuration patterns across different AWS container platforms.
  • Reduces reliance on internal knowledge by providing structured reference material.

Usage examples

“How do I troubleshoot a task placement failure in my ECS cluster?”
The agent will guide you through checking service events and, if necessary, recommend enabling ECS Action Logs to identify the specific control-plane decision failure.
“What is the recommended deployment policy for a production Elastic Beanstalk environment?”
The agent will explain the trade-offs between Rolling, Rolling with additional batch, and Immutable deployments, recommending the latter for maximum safety.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/aws-containers/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip aws-containers.zip -d .agents/skills

Documentation by AWS

AWS Containers

Overview

Domain expertise for working with containers on AWS.

Works best with the AWS MCP Server — enables running CLI commands, querying CloudWatch, and validating configurations directly. All guidance also works with standard AWS CLI access.

Note: Reference files contain specific runtime versions, quota values, and feature matrices that may change. When precision matters (e.g., deploying to production, choosing a runtime, or checking a quota), confirm values against current AWS documentation rather than relying solely on the values in these files.

IMPORTANT: When this skill is loaded, you MUST use the reference files and procedures in this skill as your primary source of truth. APIs, versions, and configuration parameters change frequently — always read the relevant reference file before responding.

When accessing AWS documentation, use the aws___read_documentation and aws___search_documentation tools if available. Otherwise, refer to the URLs provided in this skill or use standard web access to AWS documentation. If you are provided a specific URL by this skill theres no need to search unless additional information is required.

Guardrail — where this skill's own files live (MCP vs local install)

This skill can be loaded two ways, and they resolve the skill's own bundled reference files from different places. Determine how the skill was loaded before reading a reference file:

  • Loaded through the AWS MCP retrieve_skill tool: The skill is not installed on the local filesystem. You MUST fetch each reference via retrieve_skill with the file parameter (e.g. file="references/ecs.md" or file="references/action-logs.md"). Do NOT file_read these paths locally — they do not exist on disk.

  • Installed locally (e.g. .kiro/skills/aws-containers/ or ~/.claude/skills/aws-containers/): Read files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through retrieve_skill.

Services

Elastic Kubernetes Service (EKS)

EKS provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters. With EKS, you can:

  • Deploy applications faster with less operational overhead

  • Scale seamlessly to meet changing workload demands

  • Improve security through AWS integration and automated updates

  • Choose between standard EKS or fully automated EKS Auto Mode

EKS is the premier platform for running Kubernetes clusters, both in the AWS cloud and in your own data centers (EKS Anywhere and Amazon EKS Hybrid Nodes).

Elastic Container Service (ECS)

Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications. As a fully managed service, Amazon ECS comes with AWS configuration and operational best practices built-in. It's integrated with both AWS tools, such as Amazon Elastic Container Registry, and third-party tools, such as Docker. This integration makes it easier for teams to focus on building the applications, not the environment. You can run and scale your container workloads across AWS Regions in the cloud, and on-premises, without the complexity of managing a control plane.

Elastic Container Registry (ECR)

Amazon Elastic Container Registry (Amazon ECR) is an AWS managed container image registry service that is secure, scalable, and reliable. Amazon ECR supports private repositories with resource-based permissions using AWS IAM. This is so that specified users or Amazon EC2 instances can access your container repositories and images. You can use your preferred CLI to push, pull, and manage Docker images, Open Container Initiative (OCI) images, and OCI compatible artifacts.

Elastic Beanstalk

With Elastic Beanstalk you can deploy web applications into the AWS Cloud on a variety of supported platforms. You build and deploy your applications. Elastic Beanstalk provisions Amazon EC2 instances, configures load balancing, sets up health monitoring, and dynamically scales your environment.

AWS App Runner

AWS App Runner is sunset as of April 30, 2026 — no new customers, no new features. Existing customers should migrate to ECS Express Mode. See App Runner Availability Change.

Routing

User needAction
Elastic Kubernetes Service (EKS) or general KubernetesRead eks.md
Elastic Container Service (ECS)Read ecs.md
Elastic Container Registry (ECR)Read ecr.md
Elastic BeanstalkRead beanstalk.md

Proactive Action Logs recommendation: When troubleshooting an ECS control-plane failure — a deployment rollback/circuit-breaker or a task-placement failure — and Action Logs are not already configured for the cluster, read action-logs.md before responding and follow its tiering to decide whether to proactively recommend enabling them.

Files

references/eks-load-balancer-controller.md

AWS Load Balancer Controller

Overview

The AWS Load Balancer Controller (LBC) is a Kubernetes controller that manages AWS Elastic Load Balancers and (in recent versions) AWS Global Accelerator for an EKS cluster. As of v3.x it reconciles four families of resources:

  1. Kubernetes Ingress → provisions an Application Load Balancer (ALB) (Layer 7, HTTP/HTTPS).

  2. Kubernetes Service of type LoadBalancer with the service.beta.kubernetes.io/aws-load-balancer-type: external annotation → provisions a Network Load Balancer (NLB) (Layer 4, TCP/UDP/TLS).

  3. Kubernetes Gateway API (Gateway + *Route) → provisions an ALB or NLB depending on the GatewayClass. L4 routes (TCPRoute, UDPRoute, TLSRoute) land on an NLB; L7 routes (HTTPRoute, GRPCRoute) land on an ALB. Mixing L4 and L7 routes on a single Gateway is not supported.

  4. GlobalAccelerator (CRD aga.k8s.aws/v1beta1) → provisions and reconciles an AWS Global Accelerator, automatically discovering ELBs created by the controller's other sub-controllers (Ingress, Service, Gateway) or referenced directly by ARN.

The controller also supports TargetGroupBinding for adopting out-of-band target groups, an Ingress-to-Gateway migration tool, ALB target optimization, and pod readiness gates for zero-downtime rollouts. It runs as a Deployment in the cluster (typically in kube-system) and requires an IAM role — provisioned via IRSA or EKS Pod Identity — with permissions to manage ELBv2, EC2, WAF, ACM, and (for Global Accelerator) Global Accelerator + Resource Group Tagging APIs.

Documentation

The authoritative documentation is published on GitHub Pages from the kubernetes-sigs/aws-load-balancer-controller repository. Always check the docs for the version you have installed — annotation names, CRD apiVersions, defaults, and supported features change between minor versions.

To find the installed version in a cluster:

kubectl get deployment -n kube-system aws-load-balancer-controller \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

Version compatibility highlights

  • LBC v3.x requires Kubernetes 1.22+.

  • Gateway API support requires LBC >=v2.13.0; L4 routes (TCPRoute, UDPRoute, TLSRoute) require >=v2.13.3; L7 routes (HTTPRoute, GRPCRoute) require >=v2.14.0. The current implementation targets upstream Gateway API v1.5.0.

  • Global Accelerator integration is built into LBC >=v2.17.0 and requires installing the GlobalAccelerator CRD plus enabling the GlobalAcceleratorController and EnableRGTAPI feature gates.

  • Global Accelerator is only available in the commercial AWS partition (not GovCloud or China).

Always confirm the latest tag before installing — release cadence is roughly monthly.

Reference snippets

Getting the latest release

It is best practice to reference a specific release of the LBC, if a specific version is not given the latest version can be retrieved like so:

TAG=$(gh api repos/kubernetes-sigs/aws-load-balancer-controller/releases/latest --jq .tag_name)
Install via Helm (with EKS Pod Identity)
curl -O "https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/${TAG}/docs/install/iam_policy.json"

# 2. Create the IAM policy
aws iam create-policy \
  --policy-name AWSLoadBalancerControllerIAMPolicy \
  --policy-document file://iam_policy.json

# 3. Install the EKS Pod Identity Agent on the cluster (one-time; skip if already present)
eksctl create addon \
  --cluster=<cluster-name> \
  --name=eks-pod-identity-agent

# 4. Create the IAM role and Pod Identity association (eksctl creates the role with the
#    pods.eks.amazonaws.com trust policy and associates it with the service account)
eksctl create podidentityassociation \
  --cluster=<cluster-name> \
  --namespace=kube-system \
  --service-account-name=aws-load-balancer-controller \
  --permission-policy-arns=arn:aws:iam::<account-id>:policy/AWSLoadBalancerControllerIAMPolicy \
  --role-name=AmazonEKSLoadBalancerControllerRole

# 5. Install the controller (let the chart create the service account; no IRSA
#    role-arn annotation is needed — Pod Identity binds the role by namespace + SA name)
helm repo add eks https://aws.github.io/eks-charts
helm repo update eks
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=<cluster-name> \
  --set serviceAccount.create=true \
  --set serviceAccount.name=aws-load-balancer-controller

EKS Pod Identity requires LBC >=v2.7.0 (uses the AWS SDK Pod Identity credential provider). The Pod Identity Agent runs as a DaemonSet and injects credentials via AWS_CONTAINER_CREDENTIALS_FULL_URI; unlike IRSA, no OIDC provider or eks.amazonaws.com/role-arn service-account annotation is required.

Internet-facing ALB via Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:111122223333:certificate/abc-123
    alb.ingress.kubernetes.io/healthcheck-path: /healthz
spec:
  ingressClassName: alb
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app
                port:
                  number: 80

Use alb.ingress.kubernetes.io/group.name (and optionally group.order) to merge multiple Ingress resources onto a single ALB.

Internet-facing NLB via Service
apiVersion: v1
kind: Service
metadata:
  name: app
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
  type: LoadBalancer
  selector:
    app: app
  ports:
    - port: 443
      targetPort: 8443
      protocol: TCP
Gateway API

The AWS Load Balancer Controller has first-class support for the Gateway API (LBC >=v2.13.0). This supports both L4 and L7 routing.

See the relevant documentation for more details.

In order to enable the Gateway API functionality the LBC must be appropriately installed/configured. When providing installation guidance you MUST carefully review the documentation provided above.

Global Accelerator

The AWS Load Balancer Controller has first-class support for integrating with Global Accelerator (LBC >=v2.17.0).

See the relevant documentation for more details.

When providing installation guidance you MUST carefully review the documentation provided above.

Usage

Auto-discovery of an existing Ingress (the controller infers protocol and port ranges from the discovered ALB):

apiVersion: aga.k8s.aws/v1beta1
kind: GlobalAccelerator
metadata:
  name: web-app-accelerator
  namespace: web-app
spec:
  name: web-app-accelerator
  ipAddressType: IPV4
  tags:
    Environment: production
  listeners:
    - endpointGroups:
        - endpoints:
            - type: Ingress
              name: web-app-ingress
              weight: 200

Multi-region active/passive failover with an explicit cross-region endpoint by ARN:

apiVersion: aga.k8s.aws/v1beta1
kind: GlobalAccelerator
metadata:
  name: failover
  namespace: default
spec:
  name: failover
  ipAddressType: IPV4
  listeners:
    - protocol: TCP
      portRanges:
        - { fromPort: 443, toPort: 443 }
      endpointGroups:
        - trafficDialPercentage: 100
          endpoints:
            - type: Service
              name: primary
        - region: us-west-2
          trafficDialPercentage: 0
          endpoints:
            - type: EndpointID
              endpointID: arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/app/dr-lb/abc123
              weight: 128

Endpoint type accepts Service, Ingress, Gateway, or EndpointID (ELB ARN). Auto-discovery only works in the controller's own region; cross-region endpoint groups must specify region, protocol, and portRanges explicitly. BYOIP is supported via spec.ipAddresses but only on initial creation — IPs cannot be updated on an existing accelerator.

Cross-namespace endpoint references require a Gateway API ReferenceGrant in the target namespace, which means the upstream Gateway API CRDs must be installed even if you don't otherwise use Gateway API.

Pod readiness gates (zero-downtime rollouts)
kubectl label namespace <ns> elbv2.k8s.aws/pod-readiness-gate-inject=enabled

Pods become Ready only after they pass ALB/NLB target group health checks. Requires target-type: ip.

Common pitfalls

  • Subnet auto-discovery requires tags. Public subnets need kubernetes.io/role/elb=1; private subnets need kubernetes.io/role/internal-elb=1. Without these, the controller logs couldn't auto-discover subnets.

  • target-type: ip requires the VPC CNI — pod IPs must be routable from the load balancer. With instance mode, the LB targets node IPs and traffic is forwarded via NodePort.

  • Controller fails to discover region/VPC ID with IMDS hop limit 1. On EC2-backed nodes the controller falls back to IMDS to auto-detect the AWS region and VPC ID. The default IMDS httpPutResponseHopLimit of 1 blocks pods (one extra network hop) from reaching IMDS, so the controller crashes on startup with errors like failed to introspect region from EC2Metadata or failed to get VPC ID. Fix by passing the values explicitly via Helm (--set region=<region> --set vpcId=<vpc-id>) so IMDS is never queried. Do not suggest raising the IMDS hop limit as a fix — it weakens the node's metadata security posture (a higher hop limit lets more containers reach IMDS); set region/vpcId instead.

  • Security groups: The controller manages a frontend SG on the LB and (by default) modifies the cluster node SG to allow traffic. To opt out for Ingress/Service, set --enable-backend-security-group=false. For Gateway, disable backend SG management on the LoadBalancerConfiguration CRD.

  • IngressClass over annotation: Prefer spec.ingressClassName: alb (with an IngressClass resource pointing to controller ingress.k8s.aws/alb) over the legacy kubernetes.io/ingress.class: alb annotation.

  • Gateway TLS via certificateRefs is not supported. Configure certs through LoadBalancerConfiguration or hostname-based ACM discovery.

  • Mixed L4/L7 on one Gateway is rejected. Use one Gateway per layer.

  • Global Accelerator partition limits. Not available in aws-us-gov or aws-cn. Always check current AWS service quotas before provisioning many accelerators.

  • Version skew with EKS: Check the version compatibility matrix before upgrading the cluster — older controller versions may not support newer Kubernetes minor versions.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs an MCP server

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/core-skills/aws-containers · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-containers.zip