hashicorp · tvoran · Oct 26, 2020 · Oct 22, 2020 · Oct 24, 2020 · Oct 24, 2020
diff --git a/website/pages/docs/auth/aws.mdx b/website/pages/docs/auth/aws.mdx
@@ -573,6 +573,10 @@ Policy](#recommended-vault-iam-policy) except it doesn't need any further
 Furthermore, in the master account, Vault must be granted the action `sts:AssumeRole`
 for the IAM Role to be assumed.
 
+### AWS Instance Metadata Timeout
+
+@include 'partials/aws-imds-timeout.mdx'
+
 ## Authentication
 
 ### Via the CLI

diff --git a/website/pages/docs/configuration/seal/awskms.mdx b/website/pages/docs/configuration/seal/awskms.mdx
@@ -112,6 +112,10 @@ encrypted data. Old keys must not be disabled or deleted and are used to decrypt
 Any new or updated data will be encrypted with the current key defined in the seal configuration
 or set to current under a key alias.
 
+## AWS Instance Metadata Timeout
+
+@include 'partials/aws-imds-timeout.mdx'
+
 ## Learn
 
 Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)

diff --git a/website/pages/docs/configuration/storage/dynamodb.mdx b/website/pages/docs/configuration/storage/dynamodb.mdx
@@ -155,6 +155,10 @@ If the table does not already exist, Vault will try to create it, with read and
 write capacities set to the values of `read_capacity` and `write_capacity`
 respectively.
 
+## AWS Instance Metadata Timeout
+
+@include 'partials/aws-imds-timeout.mdx'
+
 ## DynamoDB Examples of Vault Configuration
 
 ### Custom Table and Read-Write Capacity

diff --git a/website/pages/docs/configuration/storage/s3.mdx b/website/pages/docs/configuration/storage/s3.mdx
@@ -118,3 +118,7 @@ storage "s3" {
 ```
 
 [s3]: https://aws.amazon.com/s3/
+
+## AWS Instance Metadata Timeouts
+
+@include 'partials/aws-imds-timeout.mdx'
diff --git a/website/pages/docs/secrets/aws/index.mdx b/website/pages/docs/secrets/aws/index.mdx
@@ -457,6 +457,10 @@ See http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.ht
 Vault 0.5.1 or later is recommended when using STS tokens to avoid validation
 errors for exceeding the AWS limit of 32 characters on STS token names.
 
+### AWS Instance Metadata Timeouts
+
+@include 'partials/aws-imds-timeout.mdx'
+
 ## API
 
 The AWS secrets engine has a full HTTP API. Please see the

diff --git a/website/pages/docs/upgrading/upgrade-to-1.4.0.mdx b/website/pages/docs/upgrading/upgrade-to-1.4.0.mdx
@@ -23,3 +23,5 @@ for Vault 1.3.X compared to 1.4.0. Please read it carefully.
 @include 'partials/ldap-upndomain-issue.mdx'
 
 @include 'partials/okta-group-pagination.mdx'
+
+@include 'partials/aws-imds-timeout-upgrade.mdx'
diff --git a/website/pages/docs/upgrading/upgrade-to-1.5.0.mdx b/website/pages/docs/upgrading/upgrade-to-1.5.0.mdx
@@ -89,3 +89,5 @@ The workaround is to quote the strings in question, as in:
 ```
 
 @include 'partials/okta-group-pagination.mdx'
+
+@include 'partials/aws-imds-timeout-upgrade.mdx'
diff --git a/website/pages/partials/aws-imds-timeout-upgrade.mdx b/website/pages/partials/aws-imds-timeout-upgrade.mdx
@@ -0,0 +1,9 @@
+## AWS Instance Metadata Timeout
+
+In 1.4.0 Vault started using an updated AWS Go SDK which had support for v2 of
+the [EC2 instance metadata service][aws-ec2-imdsv2]. However, due to the way the
+SDK was configured in Vault, there can be a delay of around 2 minutes when Vault
+relies on the instance metadata service for credentials. A fix that reduces the
+delay went into 1.5.5: [#10133](https://github.com/hashicorp/vault/pull/10133).
+
+[aws-ec2-imdsv2]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
diff --git a/website/pages/partials/aws-imds-timeout.mdx b/website/pages/partials/aws-imds-timeout.mdx
@@ -0,0 +1,24 @@
+~> Affects Vault 1.4 and later
+
+Anytime Vault uses the [instance metadata service][aws-ec2-mds] on an EC2
+instance, such as for getting credentials from the instance profile, there may
+be a delay with the introduction of [v2 of the instance metadata service
+(IMDSv2)][aws-ec2-imdsv2]. The AWS SDK used by Vault first attempts to connect
+to IMDSv2, and if that times out, it falls back to v1. In Vault 1.4, this
+timeout can take up to 2 minutes. In Vault 1.5.5 and later, it can take up to 2
+seconds with this fix: [#10133](https://github.com/hashicorp/vault/pull/10133).
+
+The timeout occurs in situations where there is a proxy between Vault and
+IMDSv2, and the instance hop limit is set to less than the number of "hops"
+between Vault and IMDSv2. For example, if Vault is running in docker on an EC2
+instance with the instance hop limit set to 1, the AWS SDK client will attempt
+to connect to IMDSv2, timeout, and fall back to IMDSv1 because of the extra
+network hop between docker and IMDS.
+
+To avoid the timeout behavior, the hop limit may be [adjusted on the underlying
+EC2 instances][aws-ec2-imdsv2-config]. With the docker example, setting the hop
+limit to 2 will allow the AWS SDK in Vault to connect to IMDSv2 without delay.
+
+[aws-ec2-mds]: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
+[aws-ec2-imdsv2]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
+[aws-ec2-imdsv2-config]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#configuring-instance-metadata-options
Original file line number	Diff line number	Diff line change
Expand Up		@@ -23,3 +23,5 @@ for Vault 1.3.X compared to 1.4.0. Please read it carefully.
		@include 'partials/ldap-upndomain-issue.mdx'

		@include 'partials/okta-group-pagination.mdx'

		@include 'partials/aws-imds-timeout-upgrade.mdx'
Original file line number	Diff line number	Diff line change
Expand Up		@@ -89,3 +89,5 @@ The workaround is to quote the strings in question, as in:
		```

		@include 'partials/okta-group-pagination.mdx'

		@include 'partials/aws-imds-timeout-upgrade.mdx'