This Guidance uses the Amazon Elastic Kubernetes Service (Amazon EKS) control plane to provision clusters with Amazon Elastic Compute Cloud (Amazon EC2) managed node groups. The nodes are built using a launch template. By providing you with a consistent and repeatable way to build clusters through the Amazon EKS API, the amount of human error and lead time are both reduced.

Also, for containers running on the Amazon EKS cluster, you can export logs and metrics to Amazon CloudWatch, which allows for observability on the cluster to proactively identify issues.

An AWS KMS key is created implicitly by Terraform scripts when an Amazon EKS cluster is launched. That key is used to encrypt Kubernetes secrets stored in Amazon EKS (including Docker registry credentials to pull images, TLS keys, and other certificates used by Agones and Open Match). This implements envelope encryption, which is considered a security best practice for an in-depth security strategy.

Amazon GuardDuty is another service designed to protect accounts and can be configured with this architecture. It surfaces security risks by analyzing audit logs and runtime activity on the Amazon EKS cluster. Amazon EKS is also used for runtime monitoring in GuardDuty to detect potential threats in the game servers and matchmaking components.

Global Accelerator also supports a secure infrastructure. It gives you the ability to have fine-grained control over source ports, protocols, and client affinity. This allows traffic to flow from game clients on the internet to game servers running on Amazon EC2 worker nodes and launched by Amazon EKS. You can restrict access from source IPs that are not safe.

Since Global Accelerator is used, you also benefit from AWS Shield Standard protection to mitigate distributed denial-of-service (DDoS) attempts. With Shield Standard, only valid traffic from safe client IPs is allowed to flow through the accelerator and reach endpoint groups for the game containers.

Network Load Balancer and Classic Load Balancer provide ingress (routing traffic from outside the cluster) to deployments running inside the Amazon EKS cluster. Ingress traffic is routed to a Kubernetes service that terminates traffic on a Kubernetes pod. Network Load Balancer and Classic Load Balancer provide fixed ingress endpoints in the Regions for each Amazon EKS cluster where internet traffic is routed from Global Accelerator. Containers on Amazon EKS clusters can be upgraded in a rolling fashion while Network Load Balancer and Classic Load Balancer continue to redirect traffic to the services without disruption.

Network Load Balancer provides ingress for the frontend service on the primary Amazon EKS cluster. With Network Load Balancer, you can scale your frontend by running multiple pods for the deployment and expose the frontend service as targets through the load balancer. If one frontend pod crashes or is unavailable, then Network Load Balancer will route traffic to the next available pod.

Classic Load Balancer provides ingress for the allocator service running on the secondary Amazon EKS cluster. With Classic Load Balancer, you can scale the allocator service by running multiple pods for the deployment and exposing them as targets through the load balancer. If one allocator pod crashes or is unavailable, then the Classic Load Balancer will route traffic to the next available pod.

Since Amazon ECR is integrated directly with Amazon EKS, it simplifies the delivery of Agones and Open Match containers that are deployed on the Amazon EKS cluster. Amazon ECR eliminates the need to operate and scale the infrastructure required to store and pull container images for the game containers, Agones, and Open Match components. Regardless of the size of the Amazon EKS clusters in terms of pods, Amazon ECR will scale to the deployment. Amazon ECR provides the ability to pull and push images in the same Region where the Amazon EKS clusters live, which provides the best performance in terms of latency and data transfer costs.

The Amazon EKS worker nodes running game servers can be configured to run on Amazon EC2 Spot Instances. Amazon EKS worker nodes running Agones and Open Match components can leverage Savings Plans. Nodes that run the game servers and Kubernetes kube-system can also potentially use AWS Graviton Processors-based instances.

You can save up to 90% on the compute costs for game server hosting when using Spot Instances to run game servers. You can optimize the compute costs for Agones and Open Match containers by up to 72% with Graviton instances covered by Savings Plans.

The AWS Carbon Footprint Tool allows you to track and measure carbon emissions from Amazon EKS clusters and improve the impact of worker nodes to support sustainable workloads.

With these services, you can manage and track carbon emissions to prevent waste and achieve sustainable computing. They optimize the usage of Amazon EKS worker nodes at the Region level and provide mechanisms to quickly react when carbon emissions goals are not met.