我们使用的服务的 API 将拒绝请求，除非源 IP 先前已被列入白名单。他们只给了我们 3 个插槽，这是一个问题，因为我们有超过 3 台机器需要使用 API。
解决此问题的最常用技术是什么？
注意：我不会尝试违反 3rd-party API 的条款和条件。我们正在使用ResellerClub，我联系他们要求更多插槽，但他们回答：
我请求您将您的服务器路由到几组 IP。
因此这个问题。
想法：
- 我在想我们可以通过运行一种充当中间人的代理来解决这个问题。我们没有向第 3 方发出 API 请求，而是向我们的代理发出请求，该代理将请求反弹给第 3 方，因此所有请求似乎都来自他们眼中的一个 IP。有没有做这种事情的通用软件？这样做似乎比下面的想法更简单，但我错了吗？
- 我应该研究使用“一个 NAT 实例”吗？例如http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html。它看起来很复杂 - 没有更简单的解决方案吗？（运行具有额外网络复杂性的额外实例是一种耻辱）。
- 既然我们使用了 Docker，那么Weave是否相关？
- 我们可以将静态 IP 附加到 VPC 网关吗？我看到使用 AWS Storage Gateway （来源）是可能的——但不确定常规的 vpc igw 吗？
我们的架构：我们使用 AWS 并让我们的实例在 ELB 后面运行的 VPC 中。我们经常在事先不知道 IP 地址的情况下启动新实例。我们在所有机器上运行相同的软件。这些机器运行 CoreOS，我们的应用程序在 Docker 容器中运行。
一个相当常见的基础设施是一个实际应用程序服务器都没有公共 IPv4 IP 地址的基础设施，它们将位于负载平衡器后面的 RFC 1918 专用网络范围内，并且它们发出的任何传出请求都是：
我想我会发布更新，因为该项目现在使用 NAT 实例成功完成。
现在 NAT 实例已全部设置完毕，最初的复杂感觉已经过去，实际上感觉非常简单 - 甚至比以前更干净（因为被迫使用私有子网是一种安全提升）。
AWS 的官方 NAT 实例设置说明运行良好：http ://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html 。我们使用 Amazon 提供的 AMI 来启动 NAT 实例。经历了这个过程，它让我意识到它是多么的“行业标准”，甚至可能是“最佳实践”。
缺点：
t2.small不是很贵，而且库存的 AMI 不需要修改，所以不是一个巨大的维护负担）。.ssh/config和阅读“ProxyCommand”，你可以让事情 100% 透明，这样使用就ssh server1可以了。