我有两个VPC，一个在我们东1，另一个在ap-northeast-1，在它们之间有一个OpenVPN隧道。
根据我的pingtesting，这两个地区之间的延迟时间约为160-180ms。 假设所有服务（数据库，caching，队列/工作人员等）都必须留在美国，而只有Web服务器将部署到JP。 通过JPnetworking服务器在美国访问这些服务将会有巨大的延迟。
AWS市场上有“WAN优化/加速”产品。 但我似乎无法从谷歌find很多信息。
任何人都有优化VPC之间的广域网链接的经验？ 我不确定我是否在正确的轨道上，是否还有其他方法可以实现同样的目标（减less延迟并确保区域之间的networking速度足够好）？
假设您的OpenVPN隧道与没有OpenVPN的站点之间的RTT相比，没有显着增加链路的往返时间（RTT），没有任何技术可以将实际的RTT实际上减less到低于底层链路。
你受到物理定律的限制（信号通过导线和光纤电缆的传播延迟，可能还有卫星和后面，尽pipe后者似乎不太可能，或者RTT会更糟），以及区域内和区域之间的中间路由器可以交换数据包。
使用非常圆的数字（7000英里x 2，在真空中光速的2/3），我会说〜113ms的延迟只是光线从一个地方到另一个地方的最佳时间再次。 没有什么可以消除。
压缩（类似于在飞机上包装更多的乘客，或者飞行更大的飞机）在单位时间内通过给定容量的链路获得更多的数据，但是没有单个乘客在运输中花费更less的时间。
以各种forms的caching也可以给出更快的数据检索的方便的错觉，但是未caching的数据不能以比正常更快的速度到达。
如果OpenVPN没有增加任何可观的额外的延迟（根据我的经验，这不应该是），那么你不会find一个神奇的子弹解决scheme。
您的应用程序的体系结构可能必须适应这种本质上基本的延迟，包括数据库读取副本，本地队列（甚至可能用于处理非关键数据库写入的最终执行）以及更高效的数据库访问。
所有WAN优化产品都是高速caching。 知道为什么不只是将标准caching，如memcached，mysql / percona奴隶服务器，nginix / varnish部署到日本VPC？ 我真的很想看看你部署的WAN优化产品，他们可能只是利用这种types的caching在一个漂亮的包。