我正在寻找使用CloudFront进行蓝/绿部署的方法。
有没有人有从一个CloudFront分配到另一个的好的解决scheme，或者每个人真的只是创build他们的分布，然后再也不会碰它了吗？
我的CloudFront发行包含一个用于静态内容的S3 来源 （javascript等）和一个指向AWS ELB的自定义来源。
在正常情况下，我们根本不会对CloudFront分配进行任何更改。 我们通过在S3中更改静态内容文件的名称来在S3源中对我们的静态内容进行版本化，并在Elastic Load Balancer（ELB）下将部署滚动到EC2实例。 但是，有时我们需要对CloudFront分配本身进行testing和更改，或者对环境进行了足够大的更改，因此我们需要在新环境中指向新的ELB。
我尝试的第一个select是有两个单独的CloudFront Web分配 ，一个用于当前的或A环境，另一个用于我的新环境或B环境。 我尝试使用Route53 加权路由策略 ，其中为我的www.domain.com Route53logging添加了两条logging，一条指向CloudFront Distribution A，权重为1，另一条指向CloudFront Distribution B，权重为0.计划是在我想从分发A转移到分发B时更改权重。但是，一次只能有一个CloudFront分发注册www.domain.com 备用域名（CNAME），否则会出现以下错误：
com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a) 第二个选项是保留一个CloudFront Web分配。 我有S3和自定义起源指向我的A和B环境，然后更新CloudFront caching行为指向另一个来源，当我想从一个环境移动到另一个。 这是非常麻烦的，因为这些更新需要15-60分钟，没有可视性的更新进度，并根据您的变化的性质，您可能需要跟上这与一个CloudFront无效，所以你不服务caching的内容从旧的环境和新的内容。
谢谢你的build议！
两个Cloudfront分配
由于AWS允许在同一AWS账户中的通配符备用CNAME之间进行重叠，因此可以按照以下方式在两个云端分布之间切换：
但是，两个不同的分发DNS（* .cloudfront.net）可能会指向相同的边缘节点，这意味着您的内容服务的方式是将cloudfront.net CNAME与服务它的Edge节点进行匹配，然后通过匹配主机名。 在这种情况下，如果两个分布都使用相同的边缘节点（例如可以通过dig来进行检查），则剪切将不会干净。
例如，如果两个发行版共享一个或多个边缘节点，则带有Alt CNAME http://www.domain.com的发行版1将优先于具有更通用的* .domain.com的发行版2，直到CNAME从所有边缘节点中的发行版1configuration中移除。 因此，在过渡期间，从一个请求中获取的版本可能与另一个请求中的版本不同。
从臀部拍摄，需要多长时间才能在云端分布中切换原点？ 1）在ELB后面部署新的代码，预热它2）将这个ELB作为一个新的来源添加到你的云端分发中，同时删除旧的来源3）一旦切换，拆除旧的ELB后面的旧代码。
为了避免与CloudFront更新或DNS更新相关的延迟，您可以将ELB后面的自动缩放组交换。 1）在新的ASG中部署新的代码，对其进行预热2）使用这个新的ASG注册现有的ELB 3）从ELB 4）注销旧的ASG 4）一旦切换，拆除旧的ASG。
我也一直在研究这个话题，并有一个解决方法（见下文）。
背景：
CloudFront要求分配configuration中的CNAME在整个帐户中都是唯一的。 所以通过DNS控制蓝/绿到不同的分布是行不通的。 有一个黑客使用通配符，但不能保证提供正确的文件。 通过DNS和CloudFront控制蓝/绿色是不可行的。
此外，更改CloudFront中的任何configuration（包括CNAME）将导致等待15-60分钟，同时将更改传播到边缘服务器。 另外，不是一个理想的设置。
解决方法：
对于单页面的应用程序，这个configuration可能会诀窍：
现在configurationCloudFront以使用您的存储桶来提供文件。 在这一点上，这一切都归结于你caching设置。 由于CloudFront需要永久使用，请在我们的S3对象上设置CacheControl标头。 对于index.html，我们使用5分钟，其他一切，1天。 当需要切换时，交换S3目录名称。 在5分钟内，应用程序将为所有意图和目的而生活。
对于已经运行的应用程序，我们有内置于代码中的构build版本以及应用程序根目录下的构buildconfigurationjson文件。 然后，应用程序会偶尔请求json文件，检查版本，如果它过期，提示刷新。
限制
你不能很好地进行浸泡testing。 我想可以将index.html的TTL增加到几个小时或几天（取决于您的需要），这将有助于确保客户端在本地caching过期时获得新版本。