AWS与Terraform集成报错：已存在的密钥对触发InvalidKeyPair.NotFound错误

核心本质 #

AWS返回InvalidKeyPair.NotFound错误的底层逻辑只有两个：API请求发送到的账号+区域组合下不存在对应名称的密钥对，或是请求中携带的密钥对名称与实际存在的名称不完全匹配。你已经排除了显性的区域配置、拼写错误问题，可按照以下优先级排查隐性问题：

• 最常见原因：Terraform使用的AWS凭证与控制台登录账号不一致
  多数学员本地会配置多套AWS凭证，若未在AWS Provider中显式指定profile参数，Terraform默认调用~/.aws/credentials中[default]条目对应的账号凭证，和当前登录控制台的实验账号不是同一个，自然找不到对应密钥。

  验证方法：在学员的Terraform项目目录执行aws sts get-caller-identity，对比返回的账号ID与控制台右上角显示的账号ID是否一致。

• 第二优先级排查：环境变量隐式覆盖了Provider配置的区域
  环境变量AWS_DEFAULT_REGION的优先级高于provider.tf中指定的region参数，若学员本地环境变量配置了其他区域，会导致API请求发送到错误区域。

  验证方法：Linux/macOS执行echo $AWS_DEFAULT_REGION，Windows cmd执行echo %AWS_DEFAULT_REGION%，确认输出区域与实验要求一致。

• 第三优先级排查：密钥对名称存在不可见字符
  学员在控制台创建密钥对时，可能不小心在名称前后输入了空格、换行符或其他不可见Unicode字符，控制台显示时会自动隐藏这类字符，导致你看到的名称和代码中写的access-key-pair看似一致，实际并不匹配。

  验证方法：执行aws ec2 describe-key-pairs输出当前账号当前区域下所有密钥对的原始名称，直接复制返回的名称替换代码中的key_name参数值，验证是否能正常创建。

• 特殊场景排查：密钥对类型不兼容
  若学员创建的是ED25519类型的密钥对，而实例使用的是较老版本的Windows Server或自定义Linux AMI，部分区域的旧版AWS API会误判密钥对不存在，可让学员重新创建RSA类型的密钥对验证。

内容的提问来源于stack exchange，提问作者Josh Edgar