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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/aws/aws-containers/downloadUnzip 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_skilltool: The skill is not installed on the local filesystem. You MUST fetch each reference viaretrieve_skillwith thefileparameter (e.g.file="references/ecs.md"orfile="references/action-logs.md"). Do NOTfile_readthese 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 need | Action |
|---|---|
| Elastic Kubernetes Service (EKS) or general Kubernetes | Read eks.md |
| Elastic Container Service (ECS) | Read ecs.md |
| Elastic Container Registry (ECR) | Read ecr.md |
| Elastic Beanstalk | Read 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
- ATTRIBUTION.mdAdded by AutoGineer893 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer67 B
- SKILL.md6.5 KiB
- references/action-logs.md13.1 KiB
- references/beanstalk-configuration.md5.3 KiB
- references/beanstalk-platforms.md3.2 KiB
- references/beanstalk.md664 B
- references/ecr.md6.0 KiB
- references/ecs-gateway.md3.3 KiB
- references/ecs-gpu-sharing.md2.4 KiB
- references/ecs-managing-compute.md10.4 KiB
- references/ecs-workloads.md12.1 KiB
- references/ecs.md1.6 KiB
- references/eks-auto-mode.md4.1 KiB
- references/eks-capabilities.md1.2 KiB
- references/eks-control-plane.md4.0 KiB
- references/eks-load-balancer-controller.md13.3 KiB
- references/eks-managing-compute.md10.9 KiB
- references/eks-networking.md2.9 KiB
- references/eks.md1.2 KiB
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:
Kubernetes
Ingress→ provisions an Application Load Balancer (ALB) (Layer 7, HTTP/HTTPS).Kubernetes
Serviceof typeLoadBalancerwith theservice.beta.kubernetes.io/aws-load-balancer-type: externalannotation → provisions a Network Load Balancer (NLB) (Layer 4, TCP/UDP/TLS).Kubernetes Gateway API (
Gateway+*Route) → provisions an ALB or NLB depending on theGatewayClass. 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.GlobalAccelerator(CRDaga.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.
Project docs: https://kubernetes-sigs.github.io/aws-load-balancer-controller/
Latest release: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/
Versioned docs:
https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.X/or/v3.X/(substitute the installed minor version)Ingress annotations: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/
Service annotations: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/
Gateway API guide: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/gateway/gateway/
Global Accelerator guide: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/globalaccelerator/aga-controller/
Ingress → Gateway migration: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress2gateway/
IAM policy JSON:
https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/<tag>/docs/install/iam_policy.jsonGlobal Accelerator IAM policy:
https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/<tag>/docs/install/aga_controller_iam_policy.jsonAWS user guide: https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
EKS Best Practices — Load Balancing: https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html
Helm chart: https://github.com/aws/eks-charts/tree/master/stable/aws-load-balancer-controller
GitHub releases (use to confirm latest version):
gh api repos/kubernetes-sigs/aws-load-balancer-controller/releases?per_page=5
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.xrequires 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 APIv1.5.0.Global Accelerator integration is built into LBC
>=v2.17.0and requires installing theGlobalAcceleratorCRD plus enabling theGlobalAcceleratorControllerandEnableRGTAPIfeature 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-controllerEKS 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 viaAWS_CONTAINER_CREDENTIALS_FULL_URI; unlike IRSA, no OIDC provider oreks.amazonaws.com/role-arnservice-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: 80Use 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: TCPGateway 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: 200Multi-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: 128Endpoint 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=enabledPods 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 needkubernetes.io/role/internal-elb=1. Without these, the controller logscouldn't auto-discover subnets.target-type: iprequires the VPC CNI — pod IPs must be routable from the load balancer. Withinstancemode, 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
httpPutResponseHopLimitof1blocks pods (one extra network hop) from reaching IMDS, so the controller crashes on startup with errors likefailed to introspect region from EC2Metadataorfailed 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); setregion/vpcIdinstead.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 theLoadBalancerConfigurationCRD.IngressClass over annotation: Prefer
spec.ingressClassName: alb(with anIngressClassresource pointing to controlleringress.k8s.aws/alb) over the legacykubernetes.io/ingress.class: albannotation.Gateway TLS via certificateRefs is not supported. Configure certs through
LoadBalancerConfigurationor 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-govoraws-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.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-containers.zip