Require IMDSv2 on your EC2 instances and disable IMDSv1 to harden access to instance metadata. This plan walks through discovering where IMDSv1 is still allowed, guiding you to choose which instances and launch mechanisms to harden, applying stricter metadata options across EC2 and Auto Scaling, and then validating both the security posture and application behavior.
The work is organized in three phases:
This phase builds a detailed inventory so you can make informed decisions about where and how to enforce IMDSv2.
You collect EC2 instance details across all in-scope regions, including IDs, names, state, types, networking, and key tags. For each instance, you review and document its metadata options (such as httpTokens, httpEndpoint, hop limit, IPv6 support, and metadata tags exposure). From this, you determine which instances currently allow IMDSv1 versus those that already enforce IMDSv2 or disable metadata entirely. Instances are grouped or tagged logically (for example, by application or environment), and the final inventory is saved for later use.
You identify all relevant launch templates and the specific versions that are actively used (default versions and those referenced by Auto Scaling or other services). For each version, you capture its metadata configuration and decide whether it permits IMDSv1 or enforces IMDSv2 / blocks metadata. Templates that rely on defaults rather than explicit settings are flagged. Each template is linked to its primary usage (such as a particular workload or Auto Scaling group), and a consolidated record is prepared for later configuration updates.
You list all in-scope Auto Scaling launch configurations and record their core settings (AMI, instance type, security groups, key pair). You then capture any available metadata-related options and infer whether IMDSv1 is effectively allowed or blocked, considering both explicit settings and service defaults. Each launch configuration is mapped to the Auto Scaling groups that use it, and any clearly obsolete configurations are noted for potential cleanup. The result is an inventory of launch configurations and their metadata behavior.
You enumerate Auto Scaling groups across regions and document their key properties (capacity settings, networking, load balancer associations, and identifying tags). For each group, you identify whether it uses a launch template or a launch configuration and link it to the specific template version or configuration. Using the earlier metadata inventories, you then tie each Auto Scaling group to the metadata behavior that applies to its instances, and categorize groups by business criticality or environment. A summary is prepared showing, per group, whether IMDSv1 is currently allowed.
Using the collected inventories, you review workloads, applications, and tools that might depend on IMDSv1-specific behavior or lack IMDSv2 token support. For each such workload, you document its owner, environment, criticality, and the nature of its dependency on IMDSv1. You indicate whether a temporary exception is needed and for how long, and clearly list instances or Auto Scaling groups that must not be hardened immediately. This exception list is approved by the relevant stakeholders and will be referenced during configuration.
You review the full inventories of EC2 instances, launch templates, launch configurations, and Auto Scaling groups—alongside the approved exception list. Guided by this information, you:
You confirm that exception workloads are excluded or explicitly handled, and finalize an approved list of all target resources for the configuration phase.
This phase applies hardened metadata options across your EC2 environment, focusing on making IMDSv2 mandatory and eliminating IMDSv1.
Using the approved target list, you update each in-scope instance’s metadata options so that IMDSv2 is required (by setting tokens to required). Where the goal is to keep metadata available, you keep the metadata endpoint enabled while enforcing token usage; where the goal is to fully block metadata, you disable the endpoint. You review and adjust the hop limit, IPv6 support, and metadata tags settings to align with organizational security standards. Any instances that cannot be updated are identified and documented, and a post-change record confirms the final metadata options.
For each selected launch template, you decide whether to modify an allowed version or create a new hardened version in line with your change management practices. Hardened versions are configured so that:
You then review which Auto Scaling groups or services reference these templates and record which ones should switch to the hardened versions. A final record lists all hardened template versions and their metadata behavior to ensure that future instances from these templates will require IMDSv2 and not allow IMDSv1.
For each selected legacy launch configuration, you create a new hardened configuration that replicates the necessary settings (AMI, instance type, security groups, key pair) while tightening instance metadata behavior to require IMDSv2 and block IMDSv1 as far as the service supports. Where per-configuration metadata controls are limited, you set the most restrictive available settings and plan to rely on EC2 or template-level hardening as needed. You map each original configuration to its hardened replacement and associate the relevant Auto Scaling groups with their future configuration updates. Superseded configurations are documented for later decommissioning.
You take the identified Auto Scaling groups and update them to reference hardened launch templates or hardened launch configurations. Throughout this process, you ensure scaling capacities remain unchanged unless otherwise planned, and optionally follow staged rollout steps if your organization prefers gradual adoption. After updates, each group is checked to confirm it no longer points to legacy configurations. You maintain a record showing each group’s previous and new configuration and confirm that the new configuration enforces IMDSv2 and blocks IMDSv1 as intended.
This phase verifies that IMDSv2 is effectively enforced across existing and newly launched instances, and that applications still operate correctly.
You re-check the metadata settings for each EC2 instance that was targeted for updates. For each instance, you verify that:
Instances that do not match the expected configuration are investigated, remediated where possible, or documented as exceptions. You then produce a validation report summarizing metadata settings for all in-scope instances and confirming that IMDSv1 is effectively unavailable where required.
Using the list of hardened launch templates, launch configurations, and updated Auto Scaling groups, you validate that newly launched instances inherit the intended hardened settings. For a representative sample, you:
Any discrepancies between expected and actual settings are investigated and either resolved or recorded as exceptions. You document the test launches, instances examined, and observed metadata behavior for audit and future reference.
Finally, you review workloads and applications running on affected instances and Auto Scaling groups and perform or coordinate functional testing. The goal is to ensure that applications can still retrieve any needed metadata via IMDSv2 where allowed and that disabling metadata does not introduce critical issues. You reassess workloads that previously needed IMDSv1 exceptions to see whether those exceptions are still required. Any application problems are documented with affected resources and initial troubleshooting notes. When testing is complete and acceptable, you capture user sign-off confirming that application behavior remains satisfactory under the new IMDSv2 enforcement model.