kubernetes/kops · critical

error reading instance-id from AWS metadata: %v

Error message

error reading instance-id from AWS metadata: %v

What it means

nodeup's Run() reads the EC2 instance-id via the vfs layer at metadata://aws/meta-data/instance-id when bootConfig.CloudProvider is AWS. This error wraps any failure of that read — typically the EC2 Instance Metadata Service (IMDS) was unreachable, returned an error, or the metadata vfs backed by nodeup's local metadata context failed. Without the instance-id, nodeup cannot identify the node for warm-pool/lifecycle handling, so it aborts bootstrap.

Source

Thrown at upup/pkg/fi/nodeup/command.go:252

		if err != nil {
			return fmt.Errorf("error building key store path: %v", err)
		}

		modelContext.KeyStore = fi.NewVFSKeystoreReader(p)
		keyStore = modelContext.KeyStore
	} else {
		return fmt.Errorf("KeyStore not set")
	}

	if err := modelContext.Init(); err != nil {
		return err
	}

	switch bootConfig.CloudProvider {
	case api.CloudProviderAWS:
		instanceIDBytes, err := vfs.Context.ReadFile("metadata://aws/meta-data/instance-id")
		if err != nil {
			return fmt.Errorf("error reading instance-id from AWS metadata: %v", err)
		}
		modelContext.InstanceID = string(instanceIDBytes)

		// Check if WarmPool is enabled first, to avoid additional API calls
		if len(modelContext.NodeupConfig.WarmPoolImages) > 0 {
			modelContext.ConfigurationMode, err = getAWSConfigurationMode(ctx, modelContext)
			if err != nil {
				return err
			}
		}

		modelContext.MachineType, err = getMachineType(ctx)
		if err != nil {
			return fmt.Errorf("failed to get machine type: %w", err)
		}

		// If Nvidia is enabled in the cluster, check if this instance has support for it.
		nvidia := modelContext.NodeupConfig.ContainerdConfig.NvidiaGPU

View on GitHub (pinned to 4c8573c808)

Solutions

1. Verify the machine is a real EC2 instance and IMDS is enabled: curl -s http://169.254.169.254/latest/meta-data/instance-id
2. If using IMDSv2, check the hop limit is >= 2 when nodeup runs behind a container/proxy (aws ec2 modify-instance-metadata-options --http-put-response-hop-limit 2)
3. Check no iptables/security-group rule blocks traffic to 169.254.169.254
4. If testing locally, run nodeup against the correct cloud provider or use --target dryrun on a real instance instead of forcing CloudProvider=AWS

Example fix

// before: nodeup running in a docker container on EC2 with default IMDSv2 hop limit 1
// after: raise hop limit so containerized nodeup can fetch metadata
aws ec2 modify-instance-metadata-options --instance-id i-0abc123 \
  --http-tokens required --http-put-response-hop-limit 2

curl -s --max-time 2 http://169.254.169.254/latest/meta-data/instance-id || echo 'IMDS unreachable'

if err := nodeupCmd.Run(ctx); err != nil {
    if strings.Contains(err.Error(), "error reading instance-id from AWS metadata") {
        // wait and re-run: IMDS may be transiently unavailable during boot
        time.Sleep(5 * time.Second)
        return retryNodeup()
    }
    return err
}

When it happens

Trigger: bootConfig.CloudProvider == api.CloudProviderAWS and vfs.Context.ReadFile("metadata://aws/meta-data/instance-id") returns an error (IMDS unreachable, IMDSv2 hop limit exceeded, metadata disabled on the instance, or missing metadata mapping in the vfs context).

Common situations: Running nodeup outside a real EC2 instance (e.g. in a container, CI, or on-prem); IMDS disabled or set to require tokens with a low hop limit behind a proxy/NAT; network firewall blocking 169.254.169.254; using the AWS provider on a non-AWS machine during testing.

Related errors

• failed to load AWS config: %w
• failed to get local-ipv4 address from ec2 metadata: %w
• failed to get machine type: %w
• error loading AWS config: %v
• finding primary network interface: %w

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/7496fe73a7f7e249. Report an issue: GitHub.