亚马逊AWS官方博客

“建立声誉需要 20 年的时间，而毁掉声誉只需 5 分钟。” — Warren Buffett 在我的技术生涯中，我一直支持遵从性和安全需求。在某些情况下，这些要求是极其苛刻的 - 例如，当我的团队为国防部审核做准备时，花费了几个月的时间，超出了我们时间的 50%。但是，在几乎所有的情况下，我都能够促进使用自动化的解决方案来使我们的生活更轻松，同时提高我们的安全性和遵从性水平。现今，移至云为您提供了明显改善合规性工作的可能性，而不需要在人力和成本上有同样的显著提升。 我来解释一下 – 合规官通常负责评估和管理企业财务、组织和声誉的风险。在企业环境中，这是一项艰巨的任务，因为人员、流程和技术的复杂性，加上跨行业和地理区域的监管差异。 企业和合规性之间也存在着一种天然的紧张关系。企业必须进行产品创新并改善客户体验。另一方面，合规性团队专注于限制或防止风险暴露，这可能与引入新产品和新特性相冲突。这就是合规性团队经常寻求维持现状的原因。底线是企业和合规性之间的自然紧张关系 - 有时运行状况 - 可能会导致关系紧张并经常导致成本增加，以及减慢上市速度。 通常，合规性团队会进行年度合规性评估、撰写报告和设定补救目标。随后，为业务和技术团队提供对任何发现结果进行补救的时间安排。产品经理和技术领导者了解合规性的重要性，但他们通常将评估视为“练习”并且从价值生成中分散注意力。对他们来说，企业领导者担心年度合规性报告的结果，因为他们认为这些“非功能性”要求会将资源重定向到未来几个季度的战略路线图中未包含的事情上。此外，在开发过程中，合规性常常被作为事后的补充。但遗憾的是，经验告诉我们，如果放任不管，合规性问题最终可能会转化为技术债务。 尽管合规性过程通常被认为是繁重的，但结果可以为客户增加有意义的价值。实际上，根据法律和道德的考虑，合规性应该被看作是一种质量的度量，确保了良好的客户体验，特别是在审查包含了安全性、可靠性和响应性的情况下。您的云策略可在这里扮演重要角色 - 方式是转化企业和合规性利益相关者之间的关系，从而改善企业及其客户的结果。更具体地说，通过在产品或服务生命周期的早期包含合规性要求，您可确保您满足政策和法规目标，同时改善您的价值主张。 方法如下 – 首先，迁移到 AWS 是一种直接的节省。在我自己的云之旅中，我发现 AWS 责任共担模式可让我们获益。以前，我们必须管理物理基础设施才能确保法规遵从性。当我们不得不采购硬件以支持技术计划时，这就造成了额外的延迟。它也总是增加我们的运营负担，因为它通常意味着基础设施团队的工作更多，而不需要额外的人员。通过将我们的工作负载迁移到云，我们将维护一个安全的、合规的物理基础设施的责任转移给了 AWS，从而带来了我们永远无法提供的资源和专业知识。换句话说，我们能够提升我们的能力，同时减少我们必须自己保护的表面积。这为我们的运营团队腾出了时间来专注于其他的增值工作，例如，创建其他自动化。 AWS 责任共担模型 其次，将工作负载转移到云可鼓励更大的自动化。可以基于标准化的和经过批准的模板部署环境，然后可以进行版本控制。此概念称为“基础设施即代码”，安全性和合规性的好处是深远的。在将基础设施作为代码进行管理时，可使用脚本自动验证基础设施来确保遵循安全最佳实践。AWS 还支持在 AWS Config 中定义可自动验证的合规性规则。因此，在使用自动化时，合规性团队可在每次系统更改时验证法律和安全需求，而不是依赖于定期的系统审查。此外，合规性和安全性测试自动化可推入软件开发过程中，并有可能在部署到生产环境之前防止策略违规。最后，可以在每日的报告中捕捉到这些发现，并发送到一个将问题分配给某个特定个体的票证系统，甚至可以触发一个自动修复响应。例如，Capital One 已开发出名为云 Custodian 的规则引擎，此引擎用于在其云平台中定义策略并以编程方式强制实施策略。 第三，当自动化过程或手动审查发现问题时，可更轻松地部署补救措施。例如，在基础设施存在漏洞的情况下，基础设施模板可在代码中进行修改并将自动应用于所有未来的实现。如果应用程序中存在此问题，则可通过将修复部署到应用程序，或通过实现补偿控件 (例如，将规则添加到 AWS Web 应用程序防火墙) 来缓解风险。 随着时间的推移，您的云策略可形成一种积极的合规性文化，将合规性和安全性作为增值的以客户为中心的活动。当您的产品团队在产品待办事项列表中将合规性要求作为用户案例包含时，或当开发人员定期向其软件开发过程添加与合规性相关的测试时，您将实现此里程碑。 如果您已在 AWS 中实现合规性过程的自动化，或者您想要了解有关此主题的更多信息，请告诉我。与此同时，这里还有一些其他的资源可能会有所帮助 – 自动在 AWS 上执行管理 如何监控 AWS 账户配置更改和对 Amazon EC2 安全组的 API 调用 AWS 上的 DevSecOps […]

作者： Vivian Zhang（张芸） Serverless（无服务器）应用可以说是当前的行业热点，用户无需预配置或管理服务器，只需要部署功能代码，AWS Lambda会在需要的时候执行代码并自动缩放， 从每天几个请求到每秒数千个请求，轻松地实现FaaS （Function as a Service）。无服务器应用的使用场景非常广阔，从微服务架构，到批处理、流处理、运维自动化和移动计算。 实现Serverless应用，除了AWS Lambda还需要什么？ 我们来看一个典型的基于Lambda的无服务器应用。 当我们将作为计算和存储实体的Lambda函数、消息队列、DB去掉，可以看到下面这张图。 这张图上的箭头，就是上一张图里Lambda函数之间的流程，或者可以称为Lambda函数之间的“胶水”，它们起到了编排协调各个Lambda函数的作用。通常在应用中，我们会需要有这样的一些流程： 我想要顺序地执行方法。 我想要并行地运行这些方法。 我想要基于数据选择执行方法。 我想要重试某些方法。 我想要try/catch/finally。 我想要代码运行一定时间或者等待一段时间…… 通常我们可以通过方法调用、函数链、DB和消息队列来协调这些函数，实现流程。但是对于所采用的协调机制，我们都希望它具有以下功能： 可以自动伸缩； 不会丢失状态； 可以处理错误和超时； 可以简单的搭建和运维； 可以审计。 这里我们介绍一种方式，采用AWS Step Functions协调Lambda函数之间的流程。 AWS Step Functions AWS Step Functions是一个可视工作流服务，可用来轻松协调分布式应用程序和微服务的各个组件。用户从单个组件构建应用程序，每个组件都执行一个特定的功能，也就是Task（可以采用Lambda函数实现）。Step Functions提供了一种可靠的方法来协调这些组件并逐步完成应用程序中的这些功能，并且 提供了一个图形控制台，将应用程序的组件可视化为一系列步骤，它可以自动触发并跟踪每一个步骤，并在出现错误时重试，这样应用程序就可以每一次都按照预先设定的顺序执行。Step Functions会记录每一步的状态，因此当事情出错时，用户可以快速地诊断和调试问题。 要使用Step Functions构建应用，首先我们需要在Step Functions里创建State Machine（状态机），也就是对应每一个应用的工作流程。可以采用以下8种蓝图，包括7种预定义好的状态机和1种自定义的。创建好的状态机用JSON描述。 在每一个状态机里，我们需要定义一系列的State（状态），用来完成不同的功能： Task：在状态机中完成特定的功能，可以采用Lambda函数实现。 Choice：在各种执行分支中进行选择。 Fail和Success：停止一个执行，并设为Fail或者Success。 Pass：简单地将输入传给输出，或者注入一些数据。 Wait：提供一定时间的延迟，或者等待到特定的时间/数据。 Parallel：并行地执行分支。 可以看出，上一节中我们所需要的协调和流程在这些状态中都得到了支持。其中的Task状态是用来真正实现应用的功能，而其他状态用来处理功能之间的流程。比如说，下面是一个名为HelloWorld，执行Lambda函数的状态。 下图是一个拥有所有状态的状态机： 在Console里看到一个创建好的状态机是这样： 我们点击New Execution并且传入input数据，就可以启动该状态机的一次执行，并且可以从界面上查看执行的情况。 […]

作者：Jaeyoung Choi 和 Kevin Li | 原文链接 这是由国际计算机科学研究院的 Jaeyoung Choi 和加州大学伯克利分校的 Kevin Li 所著的一篇访客文章。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。 当您拍摄照片时，现代移动设备可以自动向图像分配地理坐标。不过，网络上的大多数图像仍缺少该位置元数据。图像定位是估计图像位置并应用位置标签的过程。根据您的数据集大小以及提出问题的方式，分配的位置标签可以是建筑物或地标名称或实际地理坐标 (纬度、经度)。 在本文中，我们会展示如何使用通过 Apache MXNet 创建的预训练模型对图像进行地理分类。我们使用的数据集包含拍摄于全球各地的数百万张 Flickr 图像。我们还会展示如何将结果制成地图以直观地显示结果。 我们的方法 图像定位方法可以分为两类：图像检索搜索法和分类法。(该博文将对这两个类别中最先进的方法进行比较。) Weyand 等人近期的作品提出图像定位是一个分类问题。在这种方法中，作者将地球表面细分为数千个地理单元格，并利用带地理标记的图像训练了深层神经网路。有关他们的试验更通俗的描述，请参阅该文章。 由于作者没有公开他们的训练数据或训练模型 (即 PlaNet)，因此我们决定训练我们自己的图像定位器。我们训练模型的场景灵感来自于 Weyand 等人描述的方法，但是我们对几个设置作了改动。 我们在单个 p2.16xlarge 实例上使用 MXNet 来训练我们的模型 LocationNet，该实例包含来自 AWS Multimedia Commons 数据集的带有地理标记的图像。 我们将训练、验证和测试图像分离，以便同一人上传的图像不会出现在多个集合中。我们使用 Google 的 S2 Geometry Library 通过训练数据创建类。该模型经过 12 个训练周期后收敛，完成 […]

作者：Randall | 原文链接 今天，我们高兴地宣布，适用于 Windows 的 Amazon EC2 Elastic GPU 正式推出。Elastic GPU 是一种 GPU 资源，可以挂载到 Amazon Elastic Compute Cloud (EC2) 实例来提升应用程序的图形性能。Elastic GPU 提供 medium (1GB)、large (2GB)、xlarge (4GB) 和 2xlarge (8GB) 几种大小，可以作为 G3 或 G2 等 GPU 实例类型 (用于 OpenGL 3.3 应用程序) 的成本更低的替代方案。您可以将 Elastic GPU 用于多种实例类型，灵活地为应用程序选择适当的计算、内存和存储资源，使之达到平衡。您现在就可以在 us-east-1 和 us-east-2 区域预配置 Elastic GPU。 对于 eg1.medium，Elastic GPU 的起始价仅为每小时 […]

作者：Jeff Barr | 原文链接 今天，我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能：数据库快速克隆。利用 Aurora 的底层分布式存储引擎，您可以快速、经济地创建数据库的写入时复制克隆。 在我的职业生涯中，我经常需要花时间等待一些有代表性的数据样本，以便用于开发、试验或分析。如果我有一个 2TB 的数据库，则在执行任务之前，等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内，我也仍需花几个小时等待快照副本完成，然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。 借助 Aurora 的分布式存储引擎，我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针，存储引擎可实现数据库快速克隆。然后，当您更改源或克隆中的数据时，写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着，以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。 创建克隆所花的时间与数据库大小无关，因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠，因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群，具有所有相同的持久性保证。 接下来，我们克隆一个数据库。首先，选择一个 Aurora (MySQL) 实例，并从“Instance Actions”中选择“create-clone”。 接下来，将克隆命名为 dolly-the-sheep 并对其进行预配置。 大约 5 分 30 秒后，我的克隆已变为可用状态，然后，我开始进行一些大型架构更改，但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作，因此，与传统 MySQL 相比，架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试，则随后可以创建克隆的克隆，甚至是三次克隆，依次类推，同时我还能继续更改自己的克隆。这里需要注意的是，从 RDS […]

作者：Jeff Barr / 原文链接 去年，我介绍了有关新型 AWS 应用程序负载均衡器的信息，并展示了如何针对 EC2 实例以及在容器中运行的微服务，用它进行第 7 层 (应用程序) 路由。 在向 AWS 迁移的这个漫长过程中，有些客户会构建混合应用程序。这些客户告诉我们，他们希望使用单个应用程序负载均衡器，在现有本地资源以及 AWS 云中运行的新资源组合中分配流量。其他客户则希望将流量分配到分散在两个或多个 Virtual Private Cloud (VPC) 中的 Web 或数据库服务器中，在同一实例上托管 IP 地址不同但端口号相同的多项服务，并为不支持服务器名称指示 (SNI) 的客户端提供基于 IP 的虚拟托管支持。还有一些客户则希望在同一实例上 (或许是在容器内) 托管某项服务的多个实例，同时使用多个界面和安全组来实施精细访问控制。 这些情况会出现在各种混合、迁移、灾难恢复和本地使用情形及场景中。 路由到 IP 地址 应用程序负载均衡器现在可以将流量直接路由到 IP 地址，以满足这些使用情形。这些地址可以与 ALB 位于同一 VPC 中、位于同一区域中的对等 VPC 中、位于与 VPC 连接的 EC2 实例上 (通过 ClassicLink)，或者位于 VPN 连接或 AWS […]

Edmunds.com 全面迁移到 AWS 的相关经验 伙伴系统这个概念已经使用了数十年，应用范围涵盖生活的许多方面，包括学习、工作和探险。无论涉及哪一方面 (比如大学新生与其学长配对、空军飞行员与其僚机驾驶员或者您的周末潜水伙伴)，大多数伙伴系统不外乎两个目的。一个是安全性，通常出现在需要双方相互照顾的体育或危险活动中。另一个是新入学的学生或新来的员工与经验更丰富的伙伴配对以便获得培训和指导，以免出现常见的新手错误，从而自信满满地快速进步。 就我个人来讲，如果 2012 年在我开始全面向云迁移时拥有云伙伴，一定能帮我解决不少难题并省去实验的麻烦。当时，我是北美地区最大的汽车购物网站之一 Edmunds.com 的首席信息官。 但与现在不同的是，当时很难从正在成功迁移的其他公司找到大量伙伴系统资源。如果具备大规模全面的参考案例 (除 Netflix 之外)、托管迁移计划或成熟的咨询合作伙伴生态系统，则迁移工作会容易得多。幸运的是，现在有大量专注于云迁移的人员、流程和技术，这意味着，组织再也不用像我们当时迁移 Edmunds.com 那样孤军奋战了；而且，加快云使用率和更大限度节省成本的相关专业技术水准也在不断提升，这使全面迁移战略变得比以往更加可行。 作为一名终身冲浪爱好者，我可以告诉您，如果有伙伴系统的帮助，即使在危险条件下，冲浪也不是什么了不起的事情。单打独斗被认为是终极精神追求。而如今，如果我要去世界上的陌生地方冲浪，则更愿意采用更加实用的方法。在登上冲浪板之前，我会试着找一位曾经去过那里的“伙伴”，从他那里了解所需的所有海浪相关信息。例如，珊瑚礁有多浅？有鲨鱼出没吗？哪种潮汐状况最适合冲浪？听取了这些方面的建议并学习了别人的经验后，我心中的疑虑通常会打消不少，而且冲浪体验也会得到提升。 最近，我加入了一个前任首席信息官 (他们构成 AWS 企业战略团队) 团体。我们的目标是帮助技术高管思考和拟定其云优先策略，为此我们所采取的一种方法是：制定和简化新型迁移加速计划，以利用我们所积累的知识 (经验是没有压缩算法的)。作为前任首席信息官和 AWS 客户，我们曾经负责过自己的云迁移工作，并在此过程中帮助过各种类型和规模的企业完成了转型，我们的经历就像我到一个新地方冲浪时从伙伴那里获得提示和建议一样。 回想一下，我从 Edmunds.com 迁移经历中得到了三点重要启示；正如您将看到的，即使我们在 2016 年初关闭了最后一个 Edmunds.com 数据中心，我们经历的过程也仍然与大部分企业迁移当前所经历的云采用阶段非常接近 — 我们将完全停止运营这个高性能数据中心 实际上，这不是当时的确切想法。作为当时的首席信息官，我的主要目标是交付技术能力，以超前满足业务需求。在进行云迁移前的 7 年里，我们不知疲倦地工作，开发出了一种被认为极其高效的基础设施运营和 DevOps 实践。但是，这种效率需要企业付出代价，尽管它提供了每日自动发布能力和前所未有的可靠性。这种代价就是，公司需要将越来越多的有限资源分配给支持代码 (私有云和 DevOps 工具集)，从而导致没有足够的资源用于面向客户的应用程序代码 (新的客户功能和服务)。我们需要一种新的模式来控制支持代码与客户代码的比率，而不用牺牲任何功能。 2011/2012 年出现的新兴云趋势为企业提供了一种备选方案，它强调与单个公司孤军奋战相比，公有云 (尤其是 AWS 的规模) 能提供更好的基础设施和更优质的服务，而且价格更具竞争力。然而事实却不容乐观，围绕它的新闻层出不穷，报道内容无外乎：与成熟的本地安装相比，云更加昂贵且不太稳定。Netflix 早期曾采用 AWS，当时的情况有力地证明了这一论点：较成熟的大型企业可以在云中运行关键操作；但当时，我们无法为 Edmunds.com 业务找出更类似的参考实施。 同行参考在当时对我们来说极其重要，因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。 […]

作者：Iris Fu 和 Cambron Carter 这是一篇由工程总监 Cambron Carter 和 GumGum 的计算机视觉科学家 Iris Fu 联合发布的访客文章。用他们自己的话说，“GumGum 是一家在计算机视觉领域具有深厚专业知识的人工智能公司，能帮助客户充分发挥网络、社交媒体及广播电视每天生产的图像和视频的价值。” 目标物检测的最新技术  检测是许多经典计算机视觉问题之一，已随着卷积神经网络 (CNN) 的采用而得到显著改善。随着 CNN 越来越多地用于图像分类，许多人都依靠粗糙和昂贵的预处理程序来生成候选区域 (region proposal)。通过诸如“选择性搜索”之类的算法根据区域的“客体性”(它们包含目标物的可能性) 生成候选区域，这些区域随后被馈送到训练用于分类的 CNN。虽然这种方法能得到准确结果，但需要很高的运行成本。Faster R-CNN，You Only Look Once (YOLO) 和 Single Shot MultiBox Detector (SSD) 等 CNN 架构通过将定位任务嵌入到网络中来折中解决该问题。 除了预测等级和置信度，这些 CNN 还尝试预测包含某些目标物的区域极值。在本文中，这些极值只是矩形的四个角点，通常称为边界框。先前提到的检测架构需要已经用边界框注释的训练数据，即，该图像包含一个人，而且此人在该矩形区域内。以下是分类训练数据和检测训练数据： 超级帅气又非常能干的工程师 我们开始对使用 Apache MXNet 和 Caffe 来训练 SSD 的体验进行比较。明显动机是以分布式方式训练这些新架构，而不降低准确性。有关架构的更多信息，请参阅“SSD: Single Shot MultiBox Detector”。 训练工具  对于这组实验，我们尝试了几款 […]

作者：王宇 摘要： Amazon EC2 Systems Manager(SSM)是一套资源管理、配置的工具集，它不仅能够帮助客户完成AWS云中资源的管理，还能够将客户私有云中的资源统一纳入管理范围，是混合云架构中的管理利器。 IT资源在混合场景下应该如何管理？ 对于要不要使用公有云资源的问题对于今天的企业来说已经不再是一个问题了，问题变成了要怎么用，怎么管，以及怎么和现有的企业IT环境进行整合。当前，大量企业客户都存在着部分应用或资源已经上云，而企业自己的数据中心中仍然保留着一部分的应用或资源，如何将这两部分的资源统一管理起来，做到有效的协同，是一个关键问题。而传统的网管或资源管理系统往往还无法支撑这个混合场景下的管理需求。 AWS在云资源管理问题上有着完整的解决方案 AWS从云资源的准备、配置、监控、合规、优化这五个方面提供了完整的云资源管理闭环工具集，今天我们介绍的Amazon EC2 Systems Manager(SSM)是在配置管理环节中的一个最常用的管理工具集。 Amazon EC2 Systems Manager(SSM)工具集 Run Command –远程执行常规管理任务 State Manager –定义和维护操作系统和应用程序的一致配置 Parameter Store – 运维参数的集中管理，如密码和连接字符串 Maintenance Window -在明确定义的时间窗口中安排运维任务，以尽量减少停机时间 Inventory –收集，查询和审计详细的软件清单信息 Patch Management –使用自定义的规则和预先安排的维护窗口维护操作系统补丁程序 Automation –使用简化的工作流自动执行日常运维任务 Run Command Run Command能够通过远程发送命令的方式来管理AWS云以及客户自己数据中心中的IT资源。与以往的Run Command相比，现在还可以控制命令执行的并发数量。 这在远程执行命令时可以有效避免在同一时间使用太多共享资源的问题，例如内部更新或统一执行软件补丁程序。 State Manager State Manager通过“Document”的定义，能够定义和维护操作系统和应用程序的一致配置。 创建一个“Document”，将它与一组目标实例关联，然后创建一个关联策略来指定什么时间和什么频率来应用这个“Document”。 使用标签指定目标可使这个关联应用到未来创建的实例中，并允许它在动态的，自动缩放的环境中按预定义的方式工作。还可以通过选择它并点击Apply Association Now来立即运行这个关联： Parameter Store Parameter Store是一个数字词典，它简化了要分发到实例的许可证密钥，密码和其他数据的存储和管理。 […]

作者：焦杨 故事背景 笔者长期在AWS从事架构师工作，人送焦导的外号。经常遇到客户抱怨：“我选了比原来大的机器，比原来快的硬盘，可EC2的IO怎么就是上不去，到底卡在哪里了啊？你们架构师到底怎么干活的啊？”，好了，今天我也不想再背这个锅了，我们一起把这个事儿好好说道说道。 基本原理 一开始，我们先来看看磁盘上的数据是怎么到达外网的。 第一步操作系统接到IO命令，然后驱动磁盘，从磁盘上读入数据到内存处理， 最后从网卡送出，通过交换机路由器送出到外部网络。 要更好的IO性能，硬件层面上看无非三板斧 换个更块的硬盘 换个更快的网卡和交换机 更快的CPU、足够的内存、足够优化的 那到了AWS上，又变成什么样了呢？ 云上的图 你可能看出来了： 物理机变成了EC2 instance。 磁盘为了更灵活和更可靠，把它从机器里拿出来变成了EBS。 外部的交换机/路由器由于VPC的存在，对用户变成透明的了。 稍微想想，发现实质完全没有变化。那是不是我们就可以用原有的三板斧解决性能问题了呢？ 焦导的回答是：“完全没错，但是不足够”。 大家知道，公有云服务商为了保证服务质量，避免所谓的“吵闹的邻居”问题，也为了避免意外操作导致的超额费用，引入了大量的QoS特性。这里边既有我们熟悉的各个service的hard和soft的limit，也有对外暴露的各种配置选项。为了要实现高IO的目的，我们有必要对这些QoS特性有清晰的了解。 还是上边的那个图，把其中的关键部分标上号，下边一一说明 列举分析 1. EC2网络 AWS向客户提供SDN的VPC网络，屏蔽了交换机、路由器等网络基础设施。但是对单个EC2 实例的网络出口带宽是有明确的限制的。 你可能会说这不就是网卡限制吗？多加几个网卡不就行了。 请注意，增加多个网卡并不能增加单个EC2的总出口带宽。 更加详细的数据请查看这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html 2 存储网络 默认情况下，刚才提到的EC2总带宽，包含了进出EC2实例的所有流量。熟悉网络的同学应该知道，这里边包含了EC2间的计算流量、访问存储设备的存储流量等的各种流量。 要优化性能，拿出单独的网络来走存储流量就可以了。这也就是我们通常说的计算、存储流量分离技术。在AWS里，我们把这个叫做”EBS优化“。 当然了，对于一些早期机型（i2,c3等），在使用了万兆网络的情况下。因为这根管子已经足够粗，流量混在一起问题也不是很大。 EC2机型EBS优化的更多信息，可以在这里找到http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html 3 磁盘性能 要想获得高IO，选择合适的磁盘应该是最基本的了吧。是看重IOPS而选择SSD型，还是看重连续读写的磁盘吞吐而选择HDD，这是你要做出的关于磁盘的第一个决定。 这里要特别注意的几个点： 单卷IOPS的具体值和容量正相关，对于GP2而言，基准值为3IOPS/GB 对单卷有IOPS和吞吐量的限制， 两个因素同时起作用 对连接了多个卷的实例，总体IOPS和吞吐量也分别有限制 另外需要注意的是，对于使用最多的GP2类型SSD，存在着读写突增特性（链接），无论多小的磁盘短时间内IOPS都可以到达3000，具体就不再展开说了。 参考这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EBSVolumeTypes.html 4 存储队列 卷存储队列是指等待设备处理的 I/O 请求的队列，它的长度表明了有多少I/O请求还没有得到执行。队列过长，读写延迟加大，队列过短，读写任务不饱满。要让EBS全速工作起来，需要有足够的任务，也就是说要让EBS始终处于忙碌的状态。 基于这个认识，有必要根据工作负载的具体状况，实时观察存储队列长度的情况。对工作负载进行适当调整，以便发挥底层设备的最大能力。 这个指标可以通过Cloudwatch的VolumeQueueLength 来观察。 http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-io-characteristics.html […]