我一直在使用AWS，我一直在使用eu-west-1和c＃代码我已经编写了正确的身份验证。总是意图使用多个区域，因此regionURL是一个配置选项;字面意思是字符串列表。到目前为止，该列表已经有1长。
应用程序的一般工作方式是：在枚举已配置的URL的循环中，它创建一个客户端并查找具有未运行的特定名称模式的实例，然后启动它。到目前为止，只配置了eu-west-1，因此在创建客户端时仅使用该regionURL，仅枚举该区域中已停止的实例
我最近开始将EC2实例添加到其他区域eu-central-1，因此我已将eu-central-1区域基本网址添加到配置中。我知道迭代配置的循环正常工作（我已经附加了调试器并检查字符串是否有尾随字符等等 - 一切看起来都很好），这些是配置的区域URL：
https://eu-west-1.ec2.amazonaws.com
https://ec2.eu-central-1.amazonaws.com
每当应用程序枚举区域URL时，它首先获得eu-west-1并且工作正常，但当循环到eu-central-1时，对.DescribeInstances（...）的调用将失败：
AWS无法验证提供的访问凭据
创建客户端的方式没有任何实际差异;这实际上是完全相同的代码，只适用于eu-west-1。我没有特别努力为代码中的任何内容提供凭据; web.config只包含AWSAccessKey和AWSSecretKey的键值对。我一直认为AWS SDK是作为应用程序的dll部分隐式访问它们的。
我是否需要在控制台中为区域启用凭据？事实上，区域网址在不同的订单中看起来很重要（我从亚马逊帮助文档中获取了central网址，wes网址一如既往）？
答案 0 :(得分：1)
我将AWS SDK从1.5升级到3.3版，更改了各种类的名称，以反映AWS命名空间架构的重大更改，但保留了所有相同的逻辑。
我还从指定配置中的区域URL切换到配置中的区域名称，因为在使用静态调用RegionEndpoint.GetBySystemName("eu-west-1")
这是唯一的变化，并且所有变化都自动开始; API密钥仍然仅在Web配置中指定，仍然在SDK自身发现它们的情况下运行，因为我不在我的代码中使用它们。