Is your request related to a new offering from AWS?

Is this functionality available in the AWS provider for Terraform? See CHANGELOG.md, too.

• Yes ✅: changing IMDS options has been available for a long time.

Is your request related to a problem? Please describe.

AWS EKS Best Practices Guide recommends setting http_put_response_hop_limit = 1 (in section "Identities and Credentials for EKS pods Recommendations", subsection "Restrict access to the instance profile assigned to the worker node"):

You can block access to instance metadata by requiring the instance to use IMDSv2 only and updating the hop count to 1 as in the example below. [...]

If you are using Terraform to create launch templates for use with Managed Node Groups, add the metadata block to configure the hop count as seen in this code snippet:

resource "aws_launch_template" "foo" {
    name = "foo"
    …​
    metadata_options {
        http_endpoint = "enabled"
        http_tokens = "required"
        http_put_response_hop_limit = 1
        instance_metadata_tags = "enabled"
    }
    …​

The EKS Terraform module would be easier to use in a secure way if http_put_response_hop_limit was set to 1 by default.

Describe the solution you'd like.

When creating a EKS Cluster with Terraform with few options, I would like its metadata_options.http_put_response_hop_limit to be set to 1 instead of 2.

Describe alternatives you've considered.

Defining metadata_options.http_put_response_hop_limit = 1 in all Terraform projects works, but it is quite cumbersome.

Additional context

I am not aware of a legitimate use-case of using http_put_response_hop_limit = 2 in EKS nodes in 2025. AWS documents a warning:

Blocking access to instance metadata will prevent pods that do not use IRSA or EKS Pod Identities from inheriting the role assigned to the worker node.

Using the role assigned to the worker node in a pod is actually very dangerous because this role has special rights in the Kubernetes cluster (it can be used for example to read the Kubernetes Secrets used by pods running on the same node).

To make a pod able to use AWS resources without using the role assigned to the worker node, several robust ways exist: IRSA, EKS Pod Identities or even putting long-term AWS credentials in some Kubernetes Secrets used by the pod (which is not considered as the state of the art in the matter of security).

I suggest modifying the default value in