# AWS, EKS & ECS Guidance

- For EKS, ECS or APEX skill requests (including one that names a single
  skill), load the skill named exactly `apex` first if it is installed: it
  routes to the matching skill and holds the shared APEX rules. The
  `/apex:*` commands of a v1 install, such as `apex:eks`, are not it. If it
  is not installed, use the matching skill directly; the router's extra
  rules are then not loaded, but the rules in this file still apply.
- Before any task, check for a relevant AWS or APEX skill.
  APEX skills are installed at `~/.claude/skills/` (Claude Code),
  `~/.kiro/skills/` (Kiro) or `~/.agents/skills/` (Codex, by a manual copy),
  or under `.claude/skills/` or `.kiro/skills/` in the project for an
  `npx apex-skills@1.3.0 --project` install. Prefer skill
  guidance over general knowledge.
- Prefer the AWS MCP Server for AWS interactions: it provides scoped
  IAM access and CloudTrail-compatible audit logging. If unavailable,
  use the AWS CLI directly.
- Prefer the EKS MCP Server for live cluster interactions: it provides
  Kubernetes API access (the self-hosted server is read-only unless run
  with `--allow-write`; the AWS-hosted server allows the write tools its
  IAM policy grants unless the MCP Proxy for AWS runs it with
  `--read-only`), upgrade insights, and cluster discovery. If the user
  wants live cluster reads and its tools are missing, ask the user
  whether they are willing and interested to install the EKS MCP Server:
  if yes, load the `eks-mcp-server` skill to set it up; if no, use
  kubectl and the AWS CLI directly, except for `eks-operation-review`,
  which needs the EKS MCP server and stops at its pre-flight (its runbook, Pre-flight Action 3).
- When uncertain about specific AWS details (API parameters, permissions,
  limits, error codes), verify against documentation rather than guessing.
  State uncertainty explicitly if you cannot confirm.
- When uncertain about specific EKS details (add-on versions, API parameters,
  Karpenter behavior, VPC CNI settings), verify against upstream source repos
  rather than guessing. Cross-reference the upstream repo to confirm the
  behavior still holds in the current release:
  - Karpenter: `github.com/aws/karpenter-provider-aws`
  - VPC CNI: `github.com/aws/amazon-vpc-cni-k8s`
  - AWS Load Balancer Controller: `github.com/kubernetes-sigs/aws-load-balancer-controller`
  - CoreDNS: `github.com/coredns/coredns`
  - EKS AMI: `github.com/awslabs/amazon-eks-ami`
  - EKS Terraform module: `github.com/terraform-aws-modules/terraform-aws-eks`
- When creating infrastructure, prefer infrastructure-as-code (Terraform with
  `terraform-aws-modules/terraform-aws-eks`, AWS CDK, or CloudFormation) over
  direct CLI commands.
- When working with infrastructure, follow AWS Well-Architected Framework
  principles.
- Never execute destructive operations (for example node drain, cluster or
  service delete, stack delete, force eviction) without explicit user
  confirmation.
- Never output secrets, credentials, or kubeconfig contents in responses.
- Avoid non-ASCII characters (including em dashes) in AWS resource names
  and descriptions. Use hyphens instead.