Author: Jeff Barr

AWS 为您提供构建高度可靠的系统所需的组件：多区域（每个都有多个可用区)、Amazon CloudWatch（指标、监控和警报）、Auto Scaling、负载均衡、多种形式的跨区域复制等等。如果您根据架构完善的框架中提供的指南将这些组件构建在一起，即使单个组件出现故障，您的系统应该也能继续运行。 但是，只有执行了正确的测试后，您才会知道情况确实如此。混沌工程（以“灾难大师”Jesse Robbins 在Amazon.com 早期所做的开创性工作为基础，随后由 Netflix Chaos Monkey 发扬光大）这一相对较新的领域着重于通过创建破坏性事件、观察系统的响应方式以及实施改进来向应用程序施加压力。除了指出需要改进的领域之外，混沌工程还可帮助发现需要进一步监控和发出警报的盲点、发现曾经隐藏的实施问题，并为您提供提高运营技能的机会，同时缩短恢复时间。要了解有关此主题的更多信息，请首先从我的同事 Adrian Hornsby 撰写的混沌工程 – 第 1 部分开始。 隆重推出 AWS Fault Injection Simulator (FIS) 今天，我们隆重推出AWS Fault Injection Simulator (FIS)。这项新服务将通过注入故障并让您了解发生的情况，来帮助您对 AWS 工作负载执行对照实验。您将了解系统如何应对各种类型的故障，而且您还将更好地了解故障模式。您可以首先在预生产环境中运行实验，然后逐步将其作为 CI/CD 工作流的一部分运行，最终在生产环境中运行。 每个 AWS Fault Injection Simulator (FIS) 实验针对一组特定的 AWS 资源并对其执行一系列操作。我们将推出对 Amazon Elastic Compute Cloud (EC2)、Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service […]

我们在 2018 年末推出首批 Graviton 支持的 EC2 实例，并且仅在一年后便宣布推出后续 Graviton2 处理器。双 SIMD 单元、对 int8 和 fp16 指令的支持以及代际之间的其他架构改进，这一切让 Graviton2 成为极具成本效益的主力处理器。 现在，您可以从通用型（M6g 和 M6gd）、计算优化型（C6g、C6gn 和 C6gd）、内存优化型（R6g 和 R6gd）和突发型 (T4g) 实例中进行选择，这些实例都由快速、高效的 Graviton2 处理器提供支持。我们的客户使用这些实例来运行应用程序服务器、游戏服务器、HPC 工作负载、视频编码、广告服务器等。多个基准测试（包括这个和这个）表明，这些基于 Graviton2 的实例比现有 EC2 实例具有更好的性价比。 新的 X2gd 实例 我很高兴宣布不断增加的 Graviton2 支持实例的最新动态！ 在每个 vCPU 的内存方面，新 X2gd 实例是内存优化型 R6g 实例的两倍，专为内存耗尽的工作负载而设计。其中包括内存中数据库（Redis 和 Memcached）、开源关系数据库、电子设计自动化的设计与验证、实时分析、缓存服务和容器。 X2gd 实例提供八种尺寸，也有裸机形式。规格如下： 名称 vCPU 数量 内存 (GiB) […]

AWS Identity and Access Management (IAM) 是 AWS 的一个重要的基本组成部分。您可以创建 IAM 策略和服务控制策略 (SCP)，定义对特定 AWS 服务和资源的所需访问权限级别，然后将策略附加到 IAM 委托人（用户和角色)、用户组或 AWS 资源。随着 IAM 助您实现精细控制，您有责任正确使用它，几乎一直寻求建立最低权限访问。IAM 教程将帮助您了解更多信息，IAM Access Analyzer 将帮助您识别与外部实体共享的资源。我们最近推出了 IAM Access Analyzer 的更新，允许您在部署权限更改之前验证对 S3 存储桶的访问。 新策略验证 今天，我很高兴地宣布，我们正在向 IAM Access Analyzer 添加策略验证。这项强大的新功能将帮助您构建 IAM 策略和 SCP，这些都采用经过时间考验的 AWS 最佳实践。 验证专为开发人员和安全团队而设计，在策略附加到 IAM 委托人之前执行。我们执行了 100 多项检查，每项检查旨在改善您的安全状况并帮助您大规模简化策略管理。每次检查的结果都包括详细信息和具体建议。 您可以从 IAM 控制台中的 JSON 策略编辑器访问验证，也可以通过命令行 (aws accessanalyzer validate-policy) 和您自己的代码 […]

在 15 年前的今天，我在博文中宣布推出 Amazon Simple Storage Service (S3)。在该文中，我明确指出这种服务要通过 API 访问，它面向开发人员，此外还简要介绍了一些关键功能，并分享了定价信息。许多开发者发现了那篇文章，然后就开始使用 S3 API 编写代码来存储和检索对象，剩下的就是我们都知道的历史了！ 今天我要很高兴地宣布，S3 存储的对象数量已经超过 100 万亿（1014，也就是 100000000000），而且经常达到峰值，每秒要处理数千万个请求。这几乎相当于全球每一个人在这里存储了 13000 个对象，或者在浩瀚宇宙的大约两万亿个星系中，每个星系都在我们这里存储了 50 个对象（根据这份 2021 年的估计数据）。 简单的开端 回顾那次发布，我们当时做了很多决定，事实已经证明，那些决定是正确的，可以帮助开发者在几分钟内轻松理解并开始使用 S3： 我们从一个简单的概念模型开始：唯一命名的存储桶，可以容纳任意多个对象，每个对象都由一个字符串键标识。最初的 API 也同样简单：创建存储桶、列出所有存储桶、放入对象、获取对象以及放入访问控制列表。这种简单的机制帮助我们避开了“单向门”，给我们留下了根据客户反馈改进 S3 的充足空间。所有这些决定至今仍然有效，在发布会当天编写的代码时至今日仍然可以正常运行。 在讨论了许多不同的定价模式之后（在《Working Backwards》这本书中有详细说明），我们选择了一种跟随成本的定价模式。因为当时 Colin 和 Bill 说： 如果实施跟随成本的定价模式，那么如果无论开发人员通过何种方式使用 S3，他们都会以符合自身要求的方式加以使用，并且会努力最大限度地降低成本，这也会降低我们的成本。这样就不会有系统层面的博弈，我们也不必去费心估计难以捉摸的“普通客户”会如何使用 S3 来设定要支付给我们价格。 根据跟随成本的模式，我们多次降低 S3 的每 GB 每月价格，并且还引入了存储类别，这让您可以进一步减少为存储不那么常用的数据（S3 Glacier 和 S3 Glacier Deep Archive）以及可以在必要情况下重建的数据（S3 单区 – […]

AWS 进驻日本已有很长时间！ 2011 年 3 月，我们开设了亚太地区（东京）区域，2012 年添加了第三个可用区 (AZ)，随后又在 2018 年添加了第四个。自该区域启动以来，日本及世界各地的客户在该区域托管了各种各样的应用程序！ 2018 年，我们开设了大阪本地区域，为日本客户提供工作负载灾难恢复选项。大阪本地区域距离东京 400 公里，采用位于单个数据中心内的隔离式容错设计。 从本地转为标准 我很高兴地宣布，大阪本地区域现已扩展为标准 AWS 区域，包括三个可用区。与往常一样，AWS 可用区旨在提供物理冗余，并能够承受停电、互联网中断、洪水和其他自然灾害的干扰。 我们目前提供以下服务，更多服务尚在筹备之中：Amazon Elastic Kubernetes Service (EKS)、Amazon API Gateway、Auto Scaling、Application Auto Scaling、Amazon Aurora、AWS Config、AWS Personal Health Dashboard、AWS IQ、AWS Organizations、AWS Secrets Manager、AWS Shield Standard（区域）、AWS Snowball Edge、AWS Step Functions、AWS Systems Manager、AWS Trusted Advisor、AWS Certificate Manager、CloudEndure Migration、CloudEndure Disaster Recovery、AWS CloudFormation、Amazon CloudFront、AWS […]

Amazon S3 Glacier 存储类别非常适合于每季度至少访问一次的信息数据存档和长期备份（Amazon S3 Glacier Deep Archive 则更适合于极低频率访问的数据）。 Amazon S3 Glacier 将数据存储在三个可用区 (AZ) 中，每个可用区与其他可用区在物理上相隔一定距离，但不超过 100 公里（60 英里）。您可以用低至每 TB 每月 4 美元的价格存储存档和备份，然后在需要访问时从三种检索选项中进行选择（加急、标准和批量）。 我们的客户将此存储类别用于媒体资产工作流程、根据数据保留要求归档医疗保健和金融服务数据、科学数据存储、数字保存以及作为磁带的替代品。要了解更多信息，请查看我们的案例研究 Nasdaq、Reuters、Teespring、BandLab 和 Celgene。 现在变得更加经济高效 除了耐用性和安全性之外，S3 Glacier 存储类别现在还比以前更加经济高效。自 2021 年 3 月 1 日起，我们将所有 AWS 区域 S3 Glacier 的 PUT 和生命周期请求费用降低了 40%。其中包括 AWS GovCloud (美国) 区域、AWS 中国（北京）区域（由 Sinnet 运营）以及 AWS 中国（宁夏）区域（由 NWCD 运营）。请参阅 […]

Amazon Redshift 已在各种规模上提供了比任何其他云数据仓库高出 3 倍的性价比。我们是通过设计自己的硬件和使用机器学习 (ML) 来实现这一目标的。 例如，我们在 2019 年底推出了面向 Amazon Redshift 的基于 SSD 的 RA3 节点 (Amazon Redshift Update – Next-Generation Compute Instances and Managed, Analytics-Optimized Storage)，并在去年 4 月 (Amazon Redshift update – ra3.4xlarge Nodes) 和去年 12 月（Amazon Redshift 发布具有托管存储的 RA3.xlplus 节点）添加了额外的节点大小。除了高带宽网络外，RA3 节点还融入了复杂的数据管理模型。正如我在启动 RA3 节点时所说的那样： 每个实例上都有一个基于 SSD 的大容量、高性能存储缓存，由 S3 提供支持，用于进行扩展、实现高性能和持久性。存储系统使用多条提示，包括数据块温度、数据阻塞和工作负载模式来管理缓存，以获得高性能。数据自动放置在适当的层级中，您无需进行任何特殊操作便能从缓存或其他优化中获益。 我们的客户使用 RA3 节点来维护非常大的数据集，并且正在看到很好的结果。从数字互动娱乐到跟踪媒体购买的展示量和效果，Amazon Redshift […]

当我们在 2009 年推出 Amazon CloudWatch（用于 Amazon EC2 的新功能：Elastic Load Balancing、Auto Scaling 和 Amazon CloudWatch）之后，它跟踪了 EC2 实例的性能指标（CPU 负载、磁盘 I/O 和网络 I/O），并以一分钟为时间间隔将它们汇总，然后将它们存储两星期。当时，它用于监控实例运行状况以及驱动 Auto Scaling。如今，CloudWatch 已演变成一项全面和复杂得多的服务。最近新增的一些功能包括具有 1 分钟粒度并适用于所有 EBS 卷类型的指标、CloudWatch Lambda Insights 以及 Metrics Explorer。 AWS 合作伙伴利用 CloudWatch 指标创建了各种监控、警报和成本管理工具。为了访问这些指标，合作伙伴创建了轮询队列，这些队列为它们的每个客户调用了 ListMetrics 和 GetMetricData 函数。 必须根据每个合作伙伴客户创建的 AWS 资源数量以及为每个资源检索的 CloudWatch 指标数量，成比例扩展这些队列。此轮询是每个合作伙伴都必须完成的无差别繁重工作。它不会增加任何价值，而且需要投入原本可以通过其他方式善加利用的宝贵时间。 新的指标流 为使 AWS 合作伙伴和其他各方更快、更轻松地大规模访问 CloudWatch 指标，我们正在推出 CloudWatch 指标流。系统并不执行轮询（这可能导致 5 到 […]

今天，我们将推出 AWS CloudShell，目标是让获得启用 AWS 的 shell 提示的过程变得简单而安全，尽可能减少摩擦。使用 CloudShell 运行的每个 shell 环境都安装并配置了 AWS 命令行界面 (CLI) (v2)，因此您可以运行新鲜出炉的 aws 命令。这些环境还包括 Python 和 Node 运行时，将来还会有更多。

今天，我们推出了预览版的 Amazon Location，你可以立即开始使用。Amazon Location Service 采用十分经济的按使用量付费定价模式，你只需支付常见备选方案几分之一的价格，即可访问多家服务提供商提供的地图和基于位置的服务。