亚马逊AWS官方博客

随着 AWS 的发展，我们不断寻求方法来让它更好地提供价值。我们与供应商合作降低成本，并且不断地探索能够以更加高效、更具成本效益的方式来构建硬件和软件的方法。除了定期和经常性的减价之外，我们还向客户提供了各种选项，可以帮助他们优化对 AWS 的使用。例如，预留实例 (首次发布于 2009 年) 与按需定价相比，使得 Amazon EC2 用户能够获得显著的折扣，并且在特定可用区中使用时可预留容量。我们的客户使用多种战略来购买和管理其预留实例。一些客户偏好进行预付从而得到更高的折扣；一些客户则偏好无预付款，不过折扣较低 (折扣仍然很可观)。介于这两者之间的客户则对只需部分预付款，即可享受到介于这两种选项的折扣感到非常满意。为了满足各种各样的偏好，我们为大部分最新一代的实例类型增加了 3 年无预付标准预留实例。我们还降低了无预付保留实例、可转换预留实例和通用 M4实例 (包括按需实例和预留实例) 的价格。这是我们的第 61 次 AWS 降价。详细信息见此处 (所有更改和降价都立即生效)： 最新 3 年标准预留实例的无预付款选项-我们以前提供的无预付款选项为 1 年期的标准预留实例。现在，我们面向 C4、M4、R4、I3、P2、X1 和 T2 标准预留实例增加了 3 年期的无预付选项。 无预付预留实例降价-我们降低了 C4、M4、R4、I3、P2、X1 和 T2 实例类型的无预付 1 年标准实例和 3 年可转换预留实例的价格，根据实例类型、操作系统和区域，降幅最高可达 17%。下面提供了在多个代表性区域中面向 Linux 的无预付预留实例的平均降价： 美国东部 (弗吉尼亚北部) 美国西部 (俄勒冈) 欧洲 (爱尔兰) 亚太地区 (东京) 亚太地区（新加坡） […]

今年早些时候，我谈论了 Cloud Directory – 用于分层数据的云原生目录以及它如何存储大量强类型分层数据。由于 Cloud Directory 可扩展到数亿个对象，因此它非常适合许多云和移动应用程序。在我的原始博客文章中，我已经说明每个目录如何具有一个或多个架构，以及每个架构如何又具有一个或多个分面。每个分面为对象定义所需的和允许的属性集。 类型化链接简介 现在，我们通过增加对类型化链接的支持，来增强 Cloud Directory 模型的表现力。您可以使用这些链接在层次结构中创建对象-对象关系。可以为每个目录定义多种链接 (每种链接类型均是与目录关联的其中一个架构中的单独分面)。除了类型之外，每个链接还可具有一组属性。类型化链接可帮助确保不会无意中删除目前与其他对象有关系的对象，从而保持参考数据的完整性。假定您具有包含位置、工厂、楼层、房间、机器和传感器的目录。上述每个项均可表示为 Cloud Directory 中的一个维度，它在层次结构中具有丰富的元数据信息。您可以定义和使用类型化链接以通过各种方式将对象联系在一起，并创建导致维护要求、服务记录、担保和安全信息的类型化链接，以及链接上用于存储有关源对象和目标对象之间的关系的其他信息的属性。随后，您可以根据链接类型和链接中的属性值来运行查询。例如，您可以找到过去 45 天内未清除的所有传感器，或已超过保修期的所有电机。您可以查找指定楼层的所有传感器，也可以查找给定类型的传感器所在的所有楼层。 使用类型化链接 要使用类型化链接，您只需使用 CreateTypedLinkFacet 函数将一个或多个类型化链接分面添加到架构。然后，调用 AttachTypedLink，并传入源对象和目标对象、类型化链接分面和链接的属性。其他有用函数包括 GetTypedLinkFacetInformation、ListIncomingTypedLinks 和 ListOutgoingTypedLinks。要了解更多信息和查看完整函数列表，请查看 Cloud Directory API 参考。就像为对象执行的操作一样，您可以使用属性规则来约束属性值。您可以约束字符串和字节数组的长度、将字符串限定为一组指定的值并将数目限定为特定范围。我的同事分享了一些示例代码来说明如何使用类型化链接。以下是 ARN 和分面名称： String appliedSchemaArn = “arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo/schema/demo_organization/1.0”; String directoryArn = “arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo”; String typedLinkFacetName = “FloorSensorAssociation”; 第一个代码段按以下顺序创建名为 FloorSensorAssociation 的类型化链接分面，带有 sensor_type 和 maintenance_date 属性 (属性名和值是链接标识的一部分，因此顺序很重要)： client.createTypedLinkFacet(new CreateTypedLinkFacetRequest() […]

本篇博文首先简单介绍了机器学习，并给出了Apache Mahout项目的背景情况以及推荐系统中需要注意的一些细节，然后我们会构建一个电影推荐系统并写一个简单的web服务来提供给客户端查询结果。最后我们会列出学习和参与到Mahout社区中的一些方法。 机器学习 机器学习植根于人工智能，这意味着机器学习工具具有对数据问题的认知和自动决策能力，但是目前的机器学习算法并不包含真正意义上的计算思想。尽管如此，机器学习经常采用某种类型的自动化决策，并采用迭代的方式来最大化或最小化与模型性能相关的特征值。 机器学习领域包含许多主题和方法，通常有分类、聚类以及推荐等。 分类是基于其他已知（独立）变量的组合来预测未知（从属）变量的过程，例如预测银行的客户流失或某项音乐服务的订阅者数量。在这两种情况下，我们使用关于客户的已知变量来预测他们停止使用相关服务的趋势。 下表列出了几个可能的已知变量： 变量类型 例子 用户信息 城市、州、年龄、性别 行为方式 银行客户消费习惯、用户播放特定艺术家音乐的频率 环境因素 银行客户的费用评估、用户播放音乐时遭遇缓冲的频率 在进行分类工作时，我们通常针对包含从属变量真实取值的数据进行训练，然后通过比较留存测试数据的预测值和真实值的差距来评估模型的性能。 聚类是寻找事物集合和分组的过程。在几何学中，我们经常讨论N维空间中的聚类向量。举个例子，下面图中在二维空间中展示了四对由向量代表的人，每一个维度是一种支出类别，在本例中是娱乐支出和杂项支出。 左上角图中显示两人的支出数量是相近的，但是消费习惯则完全指向了不同的方向，所以这两人是不相似的。基于同样的原因，左下图中的两人就拥有相近的消费习惯。当然通常我们在分类时引入的维度是多于两个的，甚至是成千上万的维度，并且从数学上可以推广到任意有限的维度空间。 聚类的关键在于我们用来定义相似性的距离度量或者测量方法。一些常用的方法如欧几里德距离、余弦相似度（相似向量间的夹角的余弦值接近0，反之则接近1）以及Tanimoto系数（两个向量相同点占两个向量所有点的比例）。 推荐系统通常接收数据输入，通常是基于行为的数据，然后预测用户最终会倾向于哪个选项。过去十年推荐系统的流行很大程度上得益于Netflix Prize的推广，它在2006年到2009年间奖励给那些击败Netflix现有推荐系统的人。 推荐系统的性能以预测值和真实值之间的比较来得出，在生产系统中通常还结合A/B测试来进行优化。 Apache Mahout 大多数的Hadoop发行版本都包含了Apache Mahout，这其中就有Apache Bigtop和EMR。本质上Apache Mahout是一个机器学习的算法库，包含分类、聚类以及推荐等多种工具，可以被用于计算相似性和生成用户推荐等目的。Mahout使用Hadoop的Mapreduce框架来执行具体的计算过程，现在也支持新的计算框架，比如UC Berkeley’s AMPLab的Spark。 Mahout第一次bug修复发生在2008年1月，直到本篇博文写就之时，总共有1700个Jira tickets，其中54个依然是open状态。时至今日，社区中的贡献者和用户仍然在不停地针对代码和文档进行优化工作。 推荐系统 大多数人感觉到推荐系统的存在是从网页开始的，后台推荐系统会将结果显示在用户浏览网页的某一部分之上。这些包含推荐结果的网页帮助用户找到想买的商品、想听的音乐、想看的电影、想雇佣的人，甚至是约会的对象。 GroupLens研究团队于上个世纪90年代早期构建了USENET文章推荐系统，自此推荐系统技术开始了快速发展。随着时间的推移，推荐对象本身也发生了变化，除了新的文章，还有大量的在线行为值得分析，比如用户在网页上的点击链接行为；点赞和档案浏览；购物行为以及听音乐和看电影。 这些发展提供了基于用户行为进行推荐的可能性，能够帮助我们进一步改进推荐系统。 在USENET示例中，用户扫描作者和主题的文章列表，点击，阅读和关闭文章。 在线零售网站，购物者搜索产品，浏览产品页面，点击照片放大，阅读评论，并将产品添加到购物车。 在流媒体音乐网站上，音乐消费者搜索艺术家或专辑，播放曲目，通过曲目快速播放，并将艺术家添加到收藏夹，流媒体视频网站的工作方式类似。 在专业或个人联系的社交网站上，用户搜索并与其他人互动。 每个示例包括用户以某种方式与某些类型的项目进行交互的用户。 构建推荐系统 为了说明如何在EMR上通过Mahout建立分析型作业，我们决定构建一个电影推荐系统。我们会使用用户打分的电影评分数据，这些数据由GroupLens团队提供。推荐系统最终会为每一位用户推荐自己最感兴趣的电影。 1.  登录AWS账户 2.  配置EMR ruby客户端 3.  启动EMR集群 ./elastic-mapreduce –create –alive –name mahout-tutorial […]

在 AWS，每个新产品的规划环节都是围绕客户展开的。我们竭尽全力倾听和学习，利用我们了解到的信息构建未来发展的路线图。在路线图中，有大约 90% 的项目源于客户的要求，专为满足客户与我们分享的特定需求和要求而设计。我坚信，正是这种由客户推动的创新帮助我们连续 7 年锁定 Gartner 云基础设施即服务 (IaaS) 魔力象限中领导者象限的右上角位置，实现最高的执行能力以及最充分的愿景完成度：要了解更多信息，请阅读完整报告。其中包含了大量细节，很好地总结了我们的客户在挑选云提供商时所考虑的功能和因素。 -Jeff    

Amazon Workspaces 允许您通过 Web 和各种桌面和移动设备访问云中的虚拟桌面。WorkSpaces 的这种灵活性使它非常适用于用户能够使用现有设备 (即 BYOD，也称为自带设备) 的环境。在这些环境中，组织有时需要对访问 WorkSpaces 的设备进行管理。例如，他们可能需要根据客户端设备的操作系统、版本或补丁级别控制这些设备的访问，从而满足合规性或安全性策略要求。 托管设备身份验证 今天我们发布了 WorkSpaces 的设备身份验证。现在，您可以使用数字证书管理 Apple OSX 和 Microsoft Windows 客户端访问。您还可以选择允许或阻止 iOS、Android、Chrome OS、Web 和零客户端设备的访问。您可以实施策略，控制您希望允许和阻止的设备类型，这种控制可以一直细化到补丁一级。访问策略是针对每个 WorkSpaces 目录设置的。设置策略后，会评估客户端设备连接 WorkSpaces 的请求，并进行阻止或允许。要利用此功能，您需要使用 Microsoft System Center Configuration Manager 或移动设备管理 (MDM) 工具将证书分发到您的客户端设备。 以下是通过 WorkSpaces 控制台设置访问控制选项的方式： 以下是客户端未授权连接的情况： 现已推出 此功能现已在支持 WorkSpaces 的所有区域推出。 -Jeff

借助 Amazon Lightsail，您只需单击几次即可在 AWS 上启动虚拟私有服务器。[ls_i] 的价格为每月 5 美元起，它可处理繁重工作并使您能够轻松构建和托管应用程序。正如我的 re:Invent 博客文章 (Amazon Lightsail – 兼具 AWS 的强大功能与 VPS 的简易性) 中所述，您可以从菜单中选择配置，并启动预先配置了基于 SSD 的存储、DNS 管理功能和静态 IP 地址的虚拟机。 自我们在 11 月推出 Lightsail 以来，许多客户都使用它来启动虚拟私有服务器。举例来说，莫纳什大学借助 Amazon Lightsail 以简单且经济高效的方式快速为大量 CMS 服务重新建立一个平台。他们已迁移 50 种工作负载，并且目前正在考虑创建基于 Lightsail 的内部 CMS 服务，以允许全体教职员工和学生通过自助方式创建自己的 CMS 实例。如今，我们正在将 Lightsail 扩展到另外 9 个 AWS 区域，并推出了新的全球控制台。 新区域 在 re:Invent 大会上，我们宣布在 美国东部(弗吉尼亚北部)区域提供 Lightsail。在5月早些时候，我们增加了对美国和欧洲的其他几个区域的支持。现在，我们在亚太地区中的 4 […]

今天，我们宣布全面推出 AWS Lambda 对 AWS X-Ray 的支持。您可能已经从 Jeff 的 GA 文章中了解到，X-Ray 是 AWS 推出的一项服务，用于分析分布式应用程序的执行和性能行为。传统调试方法对于基于微服务的应用程序效果不佳，在这些应用程序中，有多个独立的组件在不同的服务上运行。利用 X-Ray，您可以通过对应用程序中的延迟进行细分，来快速诊断错误、速度下降和超时问题。稍后我将详细介绍如何构建和分析一个基于 Lambda 的简单应用程序，以演示您如何能够在自己的应用程序中使用 X-Ray。如果您想立即开始使用，可以通过导航到现有 Lambda 函数的配置页面并启用跟踪，来轻松地为函数启用 X-Ray： 或者在 AWS 命令行界面 (CLI) 中更新函数的 tracing-config (请务必同时传入 –function-name )： $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ 如果激活跟踪模式，Lambda 将尝试跟踪您的函数 (除非上游服务明确说明不跟踪)。如果不激活跟踪模式，仅当上游服务明确说明需要跟踪时，才跟踪您的函数。一旦启用跟踪，您将开始生成跟踪，并将获得应用程序中资源的可视化表示形式以及它们之间的联系 (边缘)。需要注意的一点是，X-Ray 守护进程会占用 Lambda 函数的一些资源。如果您已接近内存限制，Lambda 将尝试终止 X-Ray 守护程序，以免引发内存不足错误。 下面让我们通过快速构建一个使用几种不同服务的应用程序来测试这种新的集成。 作为一个二十多岁且拥有智能手机的年轻人，我有大量 图片 自拍照 (一万多张！)，我想如果能够分析所有这些照片，那就太棒了。我们将使用 Java 8 运行时编写一个简单的 […]

2014 年秋季，我们在法兰克福启动了 AWS 区域，并于第二年开放了针对该区域的 AWS Marketplace。我们在德国的客户类型和规模各不相同，有初创公司、中端市场企业、大型企业和公共部门。这些客户很好地利用了这一新区域，来构建和运行在德国、欧洲等地提供服务的应用程序和业务。他们依赖于 AWS 提供的广泛的安全功能、认证和保障，以便根据内部和法律要求及法规帮助保护客户数据。我们在德国的客户还利用位于柏林、德累斯顿和慕尼黑的销售、支持和架构资源及专业技能。柏林的 AWS 技术峰会于今天召开，我们借此机会宣布了一些重大消息。总结如下： 在法兰克福推出第三个可用区 在法兰克福推出 Amazon Lightsail 为 Amazon Polly 添加一种新语音 在法兰克福推出第三个可用区 我们将于 2017 年年中在 [fra] 区域另外设立一个可用区 (AZ)，以应对 AWS 使用量的持续增长。这将使我们在全球 16 个地理区域内的可用区数量达到 43 个。我们还计划今年晚些时候在法国和中国的新 AWS 区域设立五个可用区 (有关更多信息，请参阅 AWS 全球基础设施地图)。 德国的 AWS 客户已经在计划利用新的可用区。例如： 西门子希望通过在所有可用区镜像他们的服务，来获得更大的灵活性。这还将允许他们将所有数据存储在德国。 Zalando 将会做同样的事情，在所有可用区镜像他们的服务，并计划将更多应用程序迁移到云中。 在法兰克福推出 Amazon Lightsail Amazon Lightsail 允许您在几分钟内启动预先配置了 SSD 存储、DNS 管理功能和静态 IP 地址的虚拟机 (请阅读 Amazon […]

1. 背景介绍 AWS WAF ，全称是Web Application Firewall ，即Web 应用程序防火墙，可以帮助用户保护Web 应用程序免受常见的Web漏洞攻击。通常这些攻击会损害Web应用的安全性，影响可用性，消耗过多的资源，增加成本，还降低响应速度和用户体验。 WAF可以让用户创建定制规则进行流量筛选，阻隔恶意访问，保障正常请求。比如，可以根据 IP 地址、HTTP 标头、HTTP 正文或 URI 字符串来筛选 Web 请求，这样便能阻止诸如 SQL 注入或跨站点脚本等常见攻击模式。 和其它诸多 AWS 服务一样，WAF 的所有功能也可以通过AWS管理控制台或API进行配置。这便利了用户团队的不同角色，不论是开发人员、DevOps工程师还是安全审查专家都可以方便使用，从开发到部署的全过程系统地管理Web应用的安全。 WAF 和AWS的Web相关服务紧密结合，目前支持CloudFront和Application Load Balancer。AWS WAF 让您能够创建集中化的规则集合，而后部署到多个网站上。用户通常有多个网站和 Web 应用程序，使用WAF可以只定义一组规则并复用于多个应用程序上。WAF也是AWS全托管的服务，用户无需担心其扩展和可用性。只需在正确的资源上启用WAF，无需部署任何额外软件即可完成部署。并且只需要部署一次，即可以全球的边缘节点全部生效。 作为防火墙，WAF当然也少不了监控和报警。WAF 可以让用户设置条件来监视哪些请求。提供准实时地 Web 流量监测报告，并以此信息来创建新的规则或使用 Amazon CloudWatch 的进行报警。 今天，我们以WAF实现防盗图这个常见应用场景，帮助大家快速上手，体验其强大和便捷。 2. 部署与配置WAF 现在主流的Web应用都使用了无cookie域名来加速静态内容，我们这里也进行类似的部署，如网站域名是 example.com，图片服务使用另一个域名 example_img.com。禁止盗图的效果可以从下表来概述。 调用图片的域名 响应效果 *.example.com 200 OK 其它非法域名 403 Forbidden WAF目前支持CloudFront和Application […]

作者：Sadegh Nadimi                翻译：郝森 在过去的几年里，AWS专业服务团队已经指导和帮助企业完成数百个迁移项目。今年，我们建立了一个专门的专家团队，称作专业服务大规模迁移团队，专注于协助客户开始大规模迁移（数百个应用）。 客户经常困惑有哪些最佳实践，使应用快速稳健的迁移到AWS. 虽然每个企业的组织架构和业务目标不同，但是大规模迁移团队已经掌握一些模式和实践，帮助每种类型的企业。以下是一个不完全的清单： 迁移前阶段 1. 为未来IT和业务交集的部分，制定一个清晰的愿景。想象这个愿景将怎样影响组织的战略；更广泛的宣传，使大家明确的知道战略对组织非常重要。 2. 规划并分享一个云治理模型。识别更广泛的团队的角色和职责，满足企业信息安全的最小访问特权和职责分立等原则，保障企业目标的达成将有很长的一段路要走。它同样使增强安全管控纳入到更好的控制。在使内部用户进入使用云服务的洪流之前，需要回答很多问题。我应该有多少AWS帐户？谁可以使用什么？你怎么样授予权限？在云治理来临时，AWS可以告诉你每种方法的最佳实践、优势、限制。 3. 在此过程中，尽早的培训员工。团队掌握AWS的相关知识越多，迁移就越顺畅；内部的云布道师越多，就更容易的消除障碍。在组织做一个决定，即决定在AWS之上的最终IT全景视图，这些工作应该尽早展开。 4. 花时间和精力规划AWS之上的运维管理。研究需要调整的流程，有帮助的云运维工具，以及增强团队力量的各级别运维管理培训。思考那些使你关注更宏观图景的运维管理，确保你的环境与业务战略更好的协同。 5.了解当前拥有的IT资产，以及每批迁移中都包含哪些资产。这使你完全量化和衡量你的成功入云过程。花时间找到正确的资产发现工具，更新你的应用清单。这些使迁移规划较为顺畅，使迁移过程中忽略关联关系的风险最小化。 6. 为迁移之旅选择合适的合作伙伴。应该寻找那些既有技术技能和实施经验，又有灵活方法和项目管理框架的合作伙伴。你可能已经有一个具备云能力的合作伙伴，在选择之前，留出时间对合作伙伴进行审查，要求提供参考案例。思考你计划采用的云运维模型，合作伙伴是否可以帮助协同这个模型（建设持续交付持续集成管道，管理服务）。 迁移阶段 7. 从较小的和简单的开始。换句话说，选择一些速赢的方案。你的员工对使用AWS服务越舒服，那么干系人就会越快看到收益，那么在内部推动上就越容易。你需要做到持续和透明，我们已经看到很多组织通过一系列速赢方案而实现成功。 8. 自动化。云灵活性的实现有赖于自动化。花时间重新审视那些流程，并建立一些新的在迁移过程中有用的流程。如果不是所有的方面都能自动化，仔细决定哪些可以，让团队完成。 9. 把云当作转型。通过调整内部流程，使其拥抱技术变化。运用天然的转型优势，与干系人就新的工作模式达成协同。质疑那些总是说“我们一直这样做”的人。 10. 在可能的情况下，更多的运用全托管服务。比如包括Amazon RDS, AWS Directory Service, 和Amazon DynamoDB。由AWS处理日常的维护活动，使你的团队专注于你的客户事务。 迁移后阶段 11. 全面监控。当你的应用实现健壮的架构，综合监控战略将确保你得到所有的细节。考虑到效率和成本的相互制约，你的环境运行状况如何，数据驱动的洞察力将使你做出更聪明的业务决策。 12. 使用云原生的监控工具。在AWS上，有很多工具都可以提供应用级别的洞察和监控能力。运用最适合业务的工具，从长期看，运维人员将会感谢你，业务负责人也会拥有更清晰的数据为决策提供支持。 13. 采用AWS企业支持服务。AWS技术客户经理和帐单管家，是企业支持服务包的一部分，是非常有价值的资源。他们可以是你虚拟云团队的一部分，提供一个AWS中心接触点，和事件升级路径，同时也是技术信息和指导的宝贵资源。 大规模迁移（一次性迁移数百个应用） 14. 建立一个以迁移活动为中心，由团队、工具和流程组成的健壮的迁移工厂。在第一批迁移工作之前，记录并向组织分享相关细节。采用一个灵活的模式，加速应用迁移到AWS的过程；采用一个合适的保障措施，保障关键迁移里程碑的执行，防范相关风险，例如员工休假，或为特殊负载设计的工具发生故障。 15. 提供领导力以及设定迁移工厂的相关标准。考虑建立项目管理团队，总体管理迁移活动，保障合适的交流和沟通，以及变更过程。建立一个云卓越中心，作为撬动整个迁移工程的支点组织。卓越中心提供技术指导，或者更清晰的规定，它的成员自身也要参加迁移工程。总之，伴随迁移工厂，必须设立项目管理团队和卓越中心，确保迁移项目成功。 16. 在整体项目开始后，制定一个新团队成员加入流程。这其实是另外一种形式的培训。需要建立一个专门团队，评估和批准迁移工厂所用的工具。为了优化迁移结果，考虑任命一个更小的团队，在卓越中心之上，寻找对于自我环境中独特的工作效能和模式。鉴于敏捷批次的范围和节奏的不同，迁移可能是数月，甚至是数年才能完成。应该把迁移工厂看作持续发展和进步的一个有机体。 17. 明智的将有天赋的专家分布于敏捷批次团队。对于AWS服务和数据中心应用，确保有足够宽度上和广度上的能力，处理敏捷批次中遇到的小问题。如果在一个敏捷批次中没有合适的资源，可能导致不统一的决策，进而在后续敏捷迁移批次中产生混乱。 18. 当为一个特殊应用决定迁移策略时，考虑不同的标准。如考虑业务目标、路线图、风险情况、成本等。在高阶层次上，你可以决定保持现状平移应用入云，或者在模式上做一些调整。无论是哪种选择，尽可能采纳弹性和节约成本的最佳实践，并对支撑基础架构进行抽象。有一些共同选择是自动扩展、负载均衡、多可用区场景和准确容量估算的EC2实例。如果有意义，随时让你的团队采用AWS最佳实践，并尽快开始优化。 19. 找到模式并设计蓝图。在团队进行规划活动时，基于选定的战略，迁移模式将是确定的。针对这些模式，设计可重用的蓝图，将加快工作负载迁移的速度。不要忘记与迁移团队分享这些蓝图。这可以帮助进行迁移活动的同事，使他们专注于速度和效率，而不用为决定如何迁移有相似特征的应用而担心。 20. 应用测试。迁移工厂的一个关键活动是整合和验证部署到云端的工作负载。每一个应用组件将通过一系列预定义的和文档记录的测试。如果要求应用负责人在项目的早期就提供测试计划，将会比较顺利的得到业务负责人的签字通过。理想情况下，应该有一个模板，以供所有应用负责人提出特定的测试需求。这将帮助验证活动顺利执行，使业务负责人放心，他们的应用在AWS上运行与在数据中心中运行是类似的，甚至是更好的。 […]