如何以编程方式区分/控制Azure内部流量与出站流量？

Question

背景

我是开发者 - 加速器平台的首席架构师，名为Ball。 Ball旨在提供具有类似云的可扩展性的授权处理，在Windows Azure上运行时通过Web内容管理进行生产。它解决的问题是为后端（.NET）和前端Web（jQuery，JSON）提供易于插件的全分布式体系结构。

该平台可管理大规模的数据/内容。它的本机存储设计是Key-Value blob-storage，因此其可扩展性设计为TB级。它支持实例之间的灵活通信 - 两个端点都在Azure中运行。

我们现在正在插入用户可定义的内容集成 - 从而解决问题。

问题/疑问

该架构已经使用低级请求管理，并且已经插入以通过HTTP模块/处理程序实现来监控流量/成本。但是，我没有找到任何干净的参考，如何确保并保证网络呼叫保持在数据中心内 - 并且我知道Azure基础架构也同意流量在数据中心内。

目前的生产使用将导致每日数据流量（每个客户）立即达到千兆字节，我们需要从启动时起就做到这一点。考虑到架构的成本效率，如果它通过出站流量费率收费，它将成为迄今为止最大的组件。

我不打算删除他们申请的费用。如果客户在不同数据中心的AWS或Azure上运行他们自己的Ball实例，则会出现出站流量组件 - 无论如何。

解决方案的当前状态

Ball拥有网络级别的授权堆栈。虽然技术上可以在内部网络中控制实例内部流量，但逻辑上会使事情变得复杂，我相信应该通过出站网络接口级别控制来解决。如果有一个很好的类似参考的答案（或者我们在这个链中构成一个）它应该适用于所有必须成本优化网络出站流量的分布式架构案例。

我发现当前的解决方案围绕由IP地址检测数据中心特定的流量，基于以下列表： http://msdn.microsoft.com/en-us/library/windowsazure/dn175718.aspx

虽然技术上可以使用这些列表，但它最多只能信任“不会导致成本”。

Techwise the Ball是使用.NET 4.5和最新的Azure SDK for .NET构建的。对于devops-automation，Powershell计划在路线图上，因此任何Azure管理级别配置也可以应用于解决方案。

我附加了一些架构图像，以阐明单个Ball内的架构设计以及分布式Ball实例的网络。

Answer 1

我刚收到MSFT消息人员的回复，截至今天（2014年2月13日），Azure平台未公开所需的功能。

所以回答有关如何将此信息作为“支持平台”的回答是：不可能。

我认为已经很少有涉及基于IP地址的逻辑（不那么信任）或添加外部注册表的解决方法，可以手动检查/更新将在某个数据中心内调用的已知方。虽然变通办法（希望）足以满足某些情况，但只要您在我们的数据中心内，他们就无法获得“我们公开分享此数据”的解决方案。

我不会将此标记为已接受的答案，因为它甚至不包括解决方法规范。我稍后会回来填写我们如何解决它。