AWS 161: ECS Anywhere, EKS Anywhere, and hybrid container placement
Why this lesson matters
Place containers on external infrastructure while understanding registration, connectivity, supported operating systems, load-balancing limits, lifecycle, and local responsibility.
Hybrid container products differ mainly in control-plane location and who operates the machines. ECS Anywhere registers external hosts into a Regional ECS control plane. EKS Hybrid Nodes register customer hosts into a Regional EKS control plane. EKS Anywhere creates a self-contained Kubernetes cluster on customer infrastructure, including disconnected/air-gapped options. These are not interchangeable branding choices.
What you will be able to do
By the end, you can:
- explain ecs anywhere, eks anywhere, and hybrid container placement in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Place containers on external infrastructure while understanding registration, connectivity, supported operating systems, load-balancing limits, lifecycle, and local responsibility. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for ECS Anywhere and EKS Anywhere. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for ECS Anywhere and EKS Anywhere. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid unsupported operating systems, expecting ordinary ECS load balancing for external instances, or assuming AWS repairs local hardware. |
How the request flows
+------------------------------+
| AWS or local control plane |
+------------------------------+
|
v
+----------------------------------+
| Outbound management connection |
+----------------------------------+
|
v
+-------------------------------+
| External host and container |
+-------------------------------+
|
v
+-----------------------------------------------+
| Local network, logs, and lifecycle evidence |
+-----------------------------------------------+For ECS Anywhere and EKS Anywhere, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for ECS Anywhere and EKS Anywhere. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for ECS Anywhere and EKS Anywhere. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use Anywhere options when workloads must run on owned infrastructure and the team accepts the local operating responsibility. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid unsupported operating systems, expecting ordinary ECS load balancing for external instances, or assuming AWS repairs local hardware. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
ECS Anywhere
An external Linux server/VM first becomes a Systems Manager managed instance and then registers its ECS/SSM agents and container runtime into one ECS cluster using a short-lived activation. Tasks use the EXTERNAL launch type and supported bridge/host/none networking - not awsvpc. Current service load balancing, ECS service discovery, capacity providers, EFS configuration and other features have explicit limitations. Therefore it is strongest for outbound processing or locally fronted applications, not a drop-in Fargate replacement.
AWS owns the ECS Regional scheduler/API; the customer owns host hardware, OS/kernel/runtime, agents/upgrades, local network/load balancer, storage, capacity and physical availability. SSM rotates external-instance credentials, while task/execution roles need their own configuration. Loss of AWS connectivity affects control/credentials/image/log paths and new scheduling even if already-running local processes continue temporarily. Test current supported OS/architecture dates - 2026 removed support for several old Linux/Windows releases.
EKS Hybrid Nodes versus EKS Anywhere
EKS Hybrid Nodes keep the EKS control plane in an AWS Region and connect supported on-premises hosts using nodeadm, private network connectivity and temporary credentials from SSM hybrid activations or IAM Roles Anywhere. The customer configures compatible OS/runtime, node/pod CIDRs, firewall/routes, CNI, ingress/load balancing, storage and add-ons. Regional endpoint/control-plane latency and WAN availability remain dependencies. Current gateway/Cilium options can simplify pod routing but have encryption and deployment limitations that must be examined.
EKS Anywhere creates and lifecycle-manages Kubernetes clusters on supported customer infrastructure. The management/workload control planes and etcd can remain local, including curated packages and air-gapped registry workflows. The customer owns physical/virtual capacity, load balancer, network, storage, OS/hypervisor integration, backup of cluster/application state and upgrade sequence; AWS support/subscription and optional connectivity do not turn it into Regional EKS.
| Requirement | Starting direction |
|---|---|
| existing ECS operating model, few outbound local workers | ECS Anywhere |
| one AWS-managed EKS control plane spanning cloud and connected on-prem nodes | EKS Hybrid Nodes |
| local/air-gapped Kubernetes control plane and independent operation | EKS Anywhere |
| AWS-managed hardware/services physically on premises | Outposts, not “Anywhere” by default |
For all options, define local ingress, DNS/service discovery, registry mirror/cache, secret/identity continuity, logs during outage, durable volumes, clock/PKI, vulnerability feeds, upgrade rings, spare capacity and reconciliation after WAN recovery. Do not schedule one stateful replica across a lossy link and call it hybrid HA.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open ECS Clusters, Container instances and supplied EKS Anywhere cluster evidence; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws ecs list-clusters --output table
aws ecs list-container-instances --cluster replace-with-cluster --filter 'attribute:ecs.capability.external' --output table
aws ecs describe-container-instances --cluster replace-with-cluster --container-instances replace-with-external-container-instance-arn --output jsonExpected interpretation
An external ECS instance must maintain outbound management connectivity and uses EXTERNAL capacity. EKS Anywhere is customer-operated Kubernetes on owned infrastructure.
Practical work
Design a factory deployment with three external Linux hosts. Compare ECS Anywhere and EKS Anywhere for control plane, outbound path, inbound traffic, upgrades, disconnected operation, storage, observability, and failure ownership.
Add EKS Hybrid Nodes. Draw normal and 24-hour WAN-loss paths, then test expired activation/certificate, unsupported OS, agent/runtime mismatch, registry unavailable, control-plane latency, local load-balancer failure, full disk, host loss, split-brain/state reconciliation and upgrade rollback. Name which workloads continue, which stop scheduling and where logs/alerts remain available. Include on-prem hardware/people/network/support plus cloud control/data-transfer cost.
Diagnose this topic from its own evidence
ECS external task pending requires external-instance connected/active state, attributes, resources, launch type and placement; no inbound traffic requires local LB/DNS because ELB integration is unsupported. EKS Hybrid NotReady begins with nodeadm, IAM access entry/credentials, API network and CNI. EKS Anywhere begins with local management cluster/control plane/etcd, machine health and provider-specific controllers. Always decide whether failure is local host, WAN, AWS Regional control or workload before replacing nodes.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Place containers on external infrastructure while understanding registration, connectivity, supported operating systems, load-balancing limits, lifecycle, and local responsibility.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for ECS Anywhere and EKS Anywhere.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for ECS Anywhere and EKS Anywhere.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid unsupported operating systems, expecting ordinary ECS load balancing for external instances, or assuming AWS repairs local hardware.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when the learner accurately distinguishes all three control-plane locations, feature restrictions and responsibility boundaries; designs disconnected behavior, local ingress/storage/security/upgrade/recovery; and tests current OS/connectivity limitations. Fail if ECS Anywhere is assumed to have normal ELB/awsvpc, EKS Hybrid is called air-gapped, or EKS Anywhere is described as an AWS-operated Regional control plane.