Search the Community

Introduction We are excited to announce general availability of Amazon Linux 2023 (AL2023) on Amazon Elastic Kubernetes Service (Amazon EKS). AL2023 is the next generation of Amazon Linux from Amazon Web Services (AWS) and is designed to provide a secure, stable, high-performance environment to develop and run your cloud applications. The standard AL2023-based EKS-optimized Amazon Machine Image (AMI) can be used with Karpenter, managed node groups (MNG), and self-managed nodes in all AWS Regions. It can be used on Amazon EKS versions 1.25 or greater in standard support and Amazon EKS versions 1.23 and 1.24 in extended support. The standard AL2023-based EKS-optimized AMI is available for both x86 and ARM64 variants. Accelerated AL2023 AMIs will be released at a later date. If you would like to continue to use the accelerated AMI, you should do so by using the AL2-based accelerated AMI. The standard AL2023-based EKS-optimized AMI helps you increase security and improve application performance. AL2023 includes preconfigured security policies to help you adhere to common industry guidelines that can be confirmed at launch time or run time. By default, any Amazon EC2 instances launched with the AL2023-based EKS-optimized AMI will automatically use Security Enhanced Linux (SELinux), Open Secure Sockets Layer version 3 (OpenSSL 3), and Instance Metadata Service Version 2 (IMDSv2). To learn more about how these protocols will help improve your security posture, see Comparing AL2 to Amazon Linux 2023. From a performance standpoint, the standard AL2023-based EKS-optimized AMI optimizes boot time to reduce the time from instance launch to running your applications. These optimizations span the Amazon Linux kernel and beyond. AL2023 offers an integrated experience with many AWS-specific tools such as Systems Manager and the AWS Command Line Interface (AWS CLI). The standard AL2023-based EKS-optimized AMI also uses Control Group version 2 (cgroup v2), which is a Linux kernel feature that hierarchically organizes processes and distributes system resources between them. Cgroup v2 offers several improvements such as a single unified hierarchy design in API, safer sub-tree delegation to containers, enhanced resource allocation management, and isolation across multiple resources. Together, these improvements help with unifying accounting of different memory allocations such as network memory and kernel memory. Cgroup v2 became available on Kubernetes starting with version 1.25, and now by default comes with AL2023. Before upgrading to AL2023 While there are security and performance benefits, there are also several package changes and we recommend you to test applications thoroughly before upgrading applications in production environments. For a list of all package changes in AL2023, refer to Package changes in Amazon Linux 2023. In addition to these changes in AL2023, you should be aware of the following: AL2023 introduces a new node initialization process nodeadm that uses a YAML configuration schema. If you are using self-managed nodes or MNG with a custom launch template, you will now need to provide additional cluster metadata explicitly when creating a new node group. An example of the minimum required parameters is as follows, where apiServerEndpoint, certificateAuthority, and service cidr are now requir --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr:10.100.0.0/16 In AL2, the metadata from these parameters was discovered from the Amazon EKS DescribeCluster API call as part of the bootstrap.sh script. With AL2023, this behavior has changed since the additional API call risks throttling during large node scale ups. This change does not affect customers that are using MNG without a custom launch template or Karpenter. For more information on certificateAuthority and service cidr, see DescribeCluster. Docker is not supported in AL2023 for all supported Amazon EKS versions. Support for Docker has ended and been removed from Amazon EKS version 1.24 or greater on AL2. For more information on deprecation, see Amazon EKS ended support for Dockershim. VPC CNI v1.16.2 or greater is required for AL2023 AL2023 requires IMDSv2 by default. IMDSv2 has several benefits that help improve security posture. It uses a session-oriented authentication method that requires the creation of a secret token in a simple HTTP PUT request to start the session. A session’s token can be valid for anywhere between 1 second and 6 hours. For more information on how to transition from IMDSv1 to IMDSv2, see Transition to using Instance Metadata Service Version 2 and Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure. If you would like to use IMDSv1, you can still do so by manually overriding the settings using Instance Metadata option launch properties. Note: For IMDSv2 the default hop count for MNG is set to 1. This means that containers will not have access to the node’s credentials via IMDS. If you would like to use IMDSv1, you can still do so by manually overriding the settings using instance metadata option launch properties. Using the standard AL2023-based Amazon EKS Amazon Machine Image The Amazon EKS-optimized Amazon Linux 2023 AMI is built on top of Amazon Linux 2023, and is configured to serve as the base image for Amazon EKS nodes. The AMI is configured to work with Amazon EKS and it includes the following components: kubelet AWS IAM Authenticator containerd To retrieve the AMI ID, you will need to query the AWS Systems Manager Parameter Store API. To do this, you need to first determine the AWS region where your node will be deployed in and the Kubernetes version of the cluster your node will join. You can then run the following AWS CLI command to retrieve the appropriate AL2023 AMI ID. At launch, the AL2023 AMI comes in two flavors: x86 standard and arm64 standard. AL2023_x86_64_STANDARD: 'amazon-linux-2023/x86_64/standard' AL2023_ARM_64_STANDARD: 'amazon-linux-2023/arm64/standard' Replace the AWS Region and Kubernetes version as appropriate. Note, you must be logged into the AWS CLI using an IAM principal that has the ssm:GetParameter IAM permission to retrieve the Amazon EKS-optimized AMI metadata. aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.29/amazon-linux-2023/x86_64/standard/recommended/image_id --region region-code --query "Parameter.Value" --output text For managed node groups (MNG) You can create a new MNG using the CreateNodeGroup Amazon EKS API and specifying the AMI family type, either AL2023_x86_64_STANDARD or AL2023_ARM_64_STANDARD. The new node group will be created with the latest AL2023 AMI. If you would like to use a specific AMI version, you can specify the AL2023 Amazon EKS-optimized AMI ID in a custom launch template. If you are using the Amazon EKS console to create a new MNG, you can select Amazon Linux 2023 from the drop down menu for AMI type: If you have an existing MNG, you can upgrade to AL2023 by either performing in-place upgrade or a blue/green upgrade depending on how you are using a launch template: If you are using a custom AMI with an MNG and you are specifying the AMI ID, you can perform an in-place upgrade by swapping the AMI ID in the launch template. You should ensure that your applications and any user data transfer over to AL2023 first, before performing this upgrade strategy. If you are using MNG with either the standard launch template or with a custom launch template that does not specify the AMI ID, you are required to upgrade using a blue/green strategy since at this time, you cannot edit the amiType in the MNG. A blue/green upgrade is an alternative strategy that is more involved since a new node group will be created with AL2023 as the AMI type. You will need to ensure that the new node group is carefully configured so that all custom user data from the AL2 node group is compatible with the new operating system. Once the new node group is ready, nodes in the old node group can be cordoned and drained so that pods are scheduled on the new node group. For more on custom user data, see Customizing managed nodes with launch templates. Starting with Amazon EKS version 1.30 or newer, new MNG’s will default to using the AL2023 Amazon EKS-optimized AMI. You can continue to use AL2 by choosing it as the AMI type when creating a new MNG. For Karpenter Karpenter users who want to use AL2023 should modify the EC2NodeClass amiFamily field with AL2023. By default, Drift is enabled in Karpenter. This means that once the amiFamily field has been changed, Karpenter will detect that the Karpenter-provisioned nodes are using EKS-optimized AMIs for the old AMI. Karpenter will then automatically cordon, drain, and replace those nodes with the new AMI. apiVersion: karpenter.sh/v1beta1 kind: NodePool metadata: name: default spec: template: spec: nodeClassRef: apiVersion: karpenter.k8s.aws/v1beta1 kind: EC2NodeClass name: default --- apiVersion: karpenter.k8s.aws/v1beta1 kind: EC2NodeClass metadata: name: default spec: # Required, resolves a default ami and userdata amiFamily: AL2023 Conclusion The Amazon EKS-optimized AL2023 AMI helps you improve the performance and security posture of your applications. The EKS-optimized AL2023 AMI is available today for MNG, Karpenter, and self-managed nodes. You can also customize your EKS-optimized AMIs using packer build steps listed in the amazon-eks-ami GitHub repo. To learn more about using Amazon Linux 2023 with Amazon EKS, see Amazon EKS-optimized Amazon Linux AMIs. For accelerated workloads, the Accelerated AL2023-based AMIs will be released at a later date. If you would like to continue to use the accelerated AMI, you should do so by using the AL2-based accelerated AMI. View the full article

Today we are announcing the availability of the fourth quarterly update for Amazon Linux 2024, AL2023.4 as well as the Amazon Linux 2023 EKS optimized AMI. Amazon EKS customers can now use the standard AL2023-based EKS optimized Amazon Machine Image (AMI) with Managed Node Groups, self-managed nodes, and Karpenter, and is available across all supported version of Amazon EKS. To learn more about using Amazon Linux 2023 with EKS, see Amazon EKS optimized Amazon Linux AMIs. View the full article

Amazon EC2 now enables you to tag your Amazon Machine Images (AMIs) when you create an AMI from an EBS snapshot, or when you copy an AMI within the same or different AWS Regions. Tags are simple key-value pairs that you can assign to AWS resources such as AMIs to easily organize, search, and identify resources, create cost allocation reports, and control access. View the full article

In the ever-evolving landscape of IT infrastructure, the ability to create custom images efficiently and consistently is a game-changer. This is where HashiCorp Packer comes into play, a powerful tool that revolutionizes the image creation process across platforms such as AWS, Azure, and GCP, among others. This blog post, based on the Hashicorp Packer course offered by KodeKloud, serves as a comprehensive guide to mastering HashiCorp Packer... View the full article

Amazon EC2 has enabled the Amazon Machine Image Block Public Access (AMI BPA) setting by default for all new AWS accounts and all existing AWS accounts that have not owned a public AMI since July 15, 2023. AMI BPA restricts an AWS account from accidentally sharing an AMI publicly within an AWS Region, which helps improve the security and privacy posture for customers. View the full article

Starting today, customers can disable their unused or obsolete Amazon Machine Images (AMIs; pronounced ah-mee). Disabling an AMI changes its state to disabled, makes the AMI private if it was previously shared, and prevents any new EC2 instance launches from that disabled AMI. Customers creating, managing, and consuming AMIs at-scale can now simplify and streamline their workflows with this new capability. View the full article