- Newest
- Most votes
- Most comments
You can validate the AMI ID to see if it is associated with Kubernetes 1.28:
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.28/amazon-linux-2023/x86_64/standard/recommended/image_id --region eu-central-1 --query "Parameter.Value" --output text
If it still returns the same AMI ID but fails to launch, double-check AWS documentation for any updates or changes related to AMIs and Kubernetes versions.
Hello,
You can also try this way:
// X86_64 based AMI managed node group
cluster.addNodegroupCapacity('custom-node-group', {
instanceTypes: [new ec2.InstanceType('m5.large')], // NOTE: if amiType is x86_64-based image, the instance types here must be x86_64-based.
amiType: eks.NodegroupAmiType.AL2023_X86_64_STANDARD,
});
The issue you're experiencing is likely due to a mismatch between the AMI ID and the Kubernetes version you're trying to use. While the command you used to retrieve the AMI ID is correct, there might be a discrepancy in how CDK is interpreting or using this information.
When creating an EKS cluster with CDK, it's often better to let CDK handle the AMI selection automatically based on the Kubernetes version you specify. This approach ensures compatibility and reduces the likelihood of version mismatches.
Instead of manually specifying the AMI ID, you can use the MngClusterProvider in your CDK code to create the managed node group. This approach allows you to specify the Kubernetes version and let CDK handle the AMI selection. Here's an example of how you could modify your code:
const mngClusterProvider = new bp.MngClusterProvider({ minSize: 1, maxSize: 10, desiredSize: 4, instanceTypes: [new ec2.InstanceType('m5.large')], amiType: eks.NodegroupAmiType.AL2_X86_64, nodeGroupCapacityType: eks.CapacityType.ON_DEMAND, version: KubernetesVersion.V1_28, }); blueprints.EksBlueprint.builder() .clusterProvider(mngClusterProvider) .build(app, "my-eks-stack");
In this example, you're specifying Kubernetes version 1.28 (KubernetesVersion.V1_28), and CDK will automatically select the appropriate AMI for this version.
If you still need to specify an AMI manually, make sure you're using the correct AMI ID for your specific region and Kubernetes version. The AMI IDs can vary between regions, so ensure you're using the correct ID for the eu-central-1 region.
Remember that EKS AMIs are frequently updated, so the AMI ID you retrieved might have been superseded by a newer version. It's always a good practice to let CDK manage these details to ensure compatibility and reduce the chances of such errors.
Sources
Simplify integration of your Amazon EKS cluster with Amazon EKS Blueprints for CDK | Integration & Automation
Calling the EKS optimized AMI public parameter in Parameter Store - AWS Systems Manager
I cannot accept this answer! Why I have to rewrite my code? I want to have the control about what I create. I know the problems with blueprins from Terraform, I do not want to run into this problems again.
So I follow the instructions from AWS. I use the help page from AWS and the output is wrong. So how to get an AMI for Kubernetes 1.28?
answered 2 years ago
Hello,
The error message you're receiving suggests that the AMI ID you're using (ami-01a76c3173c5943d4) is not compatible with the Kubernetes version 1.28 that you're trying to use for your EKS cluster.
1. Use the Latest AMI ID:
Instead of hardcoding the AMI ID, you can use the EksOptimizedAmi construct from the AWS CDK to automatically retrieve the latest AMI ID compatible with your Kubernetes version and region. This construct handles the AMI ID resolution for you, ensuring that you're using the correct and up-to-date AMI.
It seems there is an issue with the AMI ID provided by the AWS SSM parameter for Kubernetes 1.28 in the eu-central-1 region. Since you want to maintain control and not use abstractions, the best course of action would be to open a support case with AWS. Provide them with the details of the issue, including the SSM parameter path, region, and error message. AWS support should be able to investigate and provide you with the correct AMI ID or guidance to resolve the problem.
Relevant content
asked 2 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago

The AMI id is still the same. What I have to check in AWS documentation if I follow the documentation? Is it not possible to trust the AWS documenation?