Amazon EKS on AWS Fargate (AMS SSPS) - AMS Advanced User Guide
Amazon EKS on AWS Fargate in AWS Managed Services FAQs

Amazon EKS on AWS Fargate (AMS SSPS)

AWS Fargate is a technology that provides on-demand, right-sized compute capacity for containers (to understand containers, see What are Containers?). With AWS Fargate, you no longer have to provision, configure, or scale groups of virtual machines to run containers. This removes the need to choose server types, decide when to scale your node groups, or optimize cluster packing.

Amazon Elastic Kubernetes Service (Amazon EKS) integrates Kubernetes with AWS Fargate by using controllers that are built by AWS using the upstream, extensible model provided by Kubernetes. These controllers run as part of the Amazon EKS-managed Kubernetes control plane and are responsible for scheduling native Kubernetes pods onto Fargate. The Fargate controllers include a new scheduler that runs alongside the default Kubernetes scheduler in addition to several mutating and validating admission controllers. When you start a pod that meets the criteria for running on Fargate, the Fargate controllers running in the cluster recognize, update, and schedule the pod onto Fargate.

To learn more, see Amazon EKS on AWS Fargate Now Generally Available, also Amazon EKS Best Practices Guide for Security (includes "Recommendations" such as "Review and revoke unnecessary anonymous access" and more).

Tip

AMS has a change type, Deployment | Advanced stack components | Identity and Access Managment (IAM) | Create OpenID Connect provider (ct-30ecvfi3tq4k3), that you can use with Amazon EKS. For an example, see Identity and Access Management (IAM) | Create OpenID Connect Provider.

Amazon EKS on AWS Fargate in AWS Managed Services FAQs

Q: How do I request access to Amazon EKS on Fargate in my AMS account?

Request access by submitting a Management | AWS service | Self-provisioned service | Add (review required) (ct-3qe6io8t6jtny) change type. This RFC provisions the following IAM role to your account.

  • customer_eks_fargate_console_role.

    After it's provisioned in your account, you must onboard the role in your federation solution.

  • These service roles give Amazon EKS on Fargate permission to call other AWS services on your behalf:

    • customer_eks_pod_execution_role

    • customer_eks_cluster_service_role

Q: What are the restrictions to using Amazon EKS on Fargate in my AMS account?

  • Creating managed or self-managed EC2 nodegroups is not supported in AMS. If you have a requirement for using EC2 worker nodes, reach out to your AMS Cloud Service Delivery Manager(CSDM) or Cloud Architect(CA).

  • AMS does not include Trend Micro or preconfigured network security components for container images. You are expected to manage your own image scanning services to detect malicious container images prior to deployment.

  • EKSCTL is not supported due to CFN interdependencies.

  • During cluster creation, you will have permissions to disable cluster control plane logging. For more information, see Amazon EKS control plane logging. We advise that you enable all important API, Authentication, and Audit logging on cluster creation.

  • During cluster creation, cluster endpoint access for Amazon EKS clusters are defaulted to public; for more information, see Amazon EKS cluster endpoint access control. We recommend that Amazon EKS endpoints be set to private. If endpoints are required for public access, we recommend that they be set to public only for specific CIDR rangers.

  • AMS does not have any method to force and restrict images used to deploy to containers on Amazon EKS Fargate. You're enabled to deploy images from Amazon ECR, Docker Hub, or any other private image repository. Therefore, there is a risk of deploying a public image that may perform malicious activity on the account.

  • Deploying EKS clusters through the cloud development kit (CDK) or CloudFormation Ingest is not supported in AMS.

Q: What are the prerequisites or dependencies to using Amazon EKS on Fargate in my AMS account?

In order to use the service, the following dependencies must be configured:

  • For authenticating against the service, both KUBECTL and aws-iam-authenticator must be installed; for more information, see Managing cluster authentication.

  • Kubernetes rely on a concept called "service accounts." In order to utilize the service accounts functionality inside of a kubernetes cluster on EKS, a Management | Other | Other | Update RFC is required with the following inputs:

  • We recommend that Config rules be configured and monitored for

    • Public cluster endpoints

    • Disabled API logging

    Monitoring and remediating these Config rules will be your responsibility.

If you want to deploy an ALB Ingress controller, submit a Management | Other | Other Update RFC to provision the necessary IAM role to be used with the ALB Ingress Controller pod. The following inputs are required for creating IAM resources to be associated with ALB Ingress Controller (include these with your RFC):

  • [Required] Amazon EKS Cluster name

  • [Optional] OpenID Connect provider URL

  • [Optional] Amazon EKS Cluster namespace where the application load balancer (ALB) ingress controller service will be deployed. [default: kube-system]

  • [Optional] Amazon EKS Cluster service account (SA) name. [default: aws-load-balancer-controller]

If you want to enable envelope secrets encryption in your cluster (which we recommend), provide the KMS key IDs you intend to use, in the description field of the RFC to add the service (Management | AWS service | Self-provisioned service | Add (ct-1w8z66n899dct). To learn more about envelope encryption, see Amazon EKS adds envelope encryption for secrets with AWS KMS.