fix(modules/self-managed-node-group): Do not necessarily need SSM param with custom AMI

[rasta-rocket]

Description

Hey folks 👋

I face an issue when using the following example code:

data "aws_region" "current" {}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 21.0"

  name = "test"
  kubernetes_version = "1.33"
  addons = {
    coredns                = {}
    eks-pod-identity-agent = {}
  }

  vpc_id     = "xxxxxx"
  subnet_ids = "xxxxxxx"
  endpoint_public_access = false
  enable_cluster_creator_admin_permissions = true
  compute_config = {
    enabled = false
  }

  self_managed_node_groups = {
    mynodegroup = {
      ami_type                   = "CUSTOM"
      ami_id                     = "ami-xxxx"
      instance_type              = "xxxxx"
      enable_bootstrap_user_data = false
      user_data_template_path    = "${path.module}/user-data.sh"

      min_size = 1
      max_size = 2
      desired_size           = 1
      vpc_security_group_ids = ["xxxxx"]
    }
  }
}

Indeed I'm getting the following error:

│ Error: Invalid index
│ 
│   on .terraform/modules/eks/modules/self-managed-node-group/main.tf line 49, in data "aws_ssm_parameter" "ami":
│   49:   name = local.ami_type_to_ssm_param[var.ami_type]
│     ├────────────────
│     │ local.ami_type_to_ssm_param is object with 18 attributes
│     │ var.ami_type is "CUSTOM"
│ 
│ The given key does not identify an element in this collection value.

I've made a first deduction where I understand that reading the aws_ssm_parameter is not necessarily required when using a custom AMI
If you need more details do not hesitate to ping me 😉

Cheers ☀️

Motivation and Context

Breaking Changes

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[bryantbiggs]

can we start with a problem statement or some explanation as to why this is needed? typically, CUSTOM is not really valid in the context of this module (not sure why people still use Ubuntu AMIs when their is zero support for them and the EKS AMIs all just work out of the box and are fully supported by AWS)

[rasta-rocket]

can we start with a problem statement or some explanation as to why this is needed? typically, CUSTOM is not really valid in the context of this module (not sure why people still use Ubuntu AMIs when their is zero support for them and the EKS AMIs all just work out of the box and are fully supported by AWS)

@bryantbiggs I made an update on the PR description tell me if it is better like that 😉
Actually the issue is not necessarily with Ubuntu, we are using other base AMIs

Regarding the support of the custom AMI, this is something that is allowed by AWS and I didn't see any mention in the repos that prevent this use case, so quick question: is it something that you chose to not support ?

[bryantbiggs]

Actually the issue is not necessarily with Ubuntu, we are using other base AMIs

What base AMIs exactly? If you are taking an EKS provided AMI as your base AMI and then creating a new AMI from that, then you should simply use the AMI type for the base AMI.

For example, if you are taking the EKS AL2023 x86-64 AMI and making changes before creating a new AMI, then in your configuration just set ami_type = "AL2023_x86_64_STANDARD"