Thread by @onurfz

Today during the #reInvent keynote, we have announced Amazon #EKS on #Fargate. So proud of my team! AWS customers can now run both native #ECS tasks as well as #Kubernetes pods on Fargate. In this thread, I'll try to explain our reasoning behind some major design decisions. 1/n

For #EKS on #Fargate, we wanted to give customers a native k8s experience. You can use your existing tooling to run pods on Fargate. Fargate operates at the task (ECS) and pod (K8S) level, so any higher level abstraction (deployments, replicasets, etc.) built on top works. 2/n

When designing #EKS on #Fargate, instead of building a one-off integration with Kubernetes, we've asked ourselves "What additional capabilities does Fargate need in order to become a service on which other multi-tenant serverless containers offerings can be built?". 3/n

The result is a set of awesome new capabilities that we will be talking about at #reInvent. Most notably, we are designing a new #Firecracker based multi-tenant data plane that unlocks many new capabilities. 4/n

Just like #ECS tasks, each #EKS pod gets its own dedicated hardware virtualized environment to run in, a dedicated ENI for all traffic to the customer VPC, and dedicated ephemeral storage space. AWS #Fargate handles all of the compute, network and storage setup automatically. 5/n

We also wanted to give customers a simple way to set rules for when and how they want to use #Fargate vs. EC2 worker nodes. The answer is the EKS Fargate Profile. A Fargate profile includes a name, a set of subnets to launch the profile in, and... 6/n

…a "pod execution role" (similar to existing ECS task execution role) that includes permissions (ECR image pull etc.) to run the pod, and a set of selectors that describe how to match pods. Each selector consists of a namespace and optional labels for finer granularity. 7/n

For example, you can create a profile to say "Launch all pods in 'test' namespace on Fargate" or "Launch all pods that are in 'myapp' namespace and have label='myapp' on Fargate. You also have more granular control at the pod level to force pods to run on Fargate or not. 8/n

The profile also bridges AWS IAM with K8S auth, so that the EKS cluster administrator, an AWS identity, can set which users are allowed to launch pods in which namespaces and subnets. 9/n

We implemented an admission webhook that matches profiles to pods and validates that pods can run on #Fargate. The Fargate scheduler then schedules pods on managed capacity with automatically provisioned CPU and memory resources as declared in the pod resource requirements. 10/n

We also integrated #Fargate with #AppMesh. In addition to the already supported #ECS tasks, all #EKS pods on Fargate can use AppMesh as their service mesh. We will continue to provide turnkey integrations with Fargate so that you can focus on your apps. 11/n

#Fargate provides a consistent environment for all #ECS tasks and #EKS pods. That includes the container runtime. We are happy to announce that Fargate is standardizing on @containerd. With our firecracker-containerd plugin, we will run containers as #Firecracker microVMs. 12/n

@containerd #ECS on #Fargate is a fully multi-tenant serverless container offering providing full task-level isolation by secure hardware virtualization for your workloads. Kubernetes is a single-tenant orchestrator, so although pods run hw-virtualized, cluster-level isolation applies. 13/n

@containerd Many of our customers have built their own multi-tenant apps and platforms safely on #Fargate. Check out the keynotes and breakout sessions at #reInvent to learn more from our customers about how they build on #Fargate. 14/n