亚马逊AWS官方博客

您在很早以前就能够标记 AWS 资源并逐个标签地查看费用细分。训练营、认证和认证考试成本分配功能于 2012 年发布 (参阅客户账单的 AWS 成本分配)，此后我们不断地添加更多服务支持，最新支持的服务为 DynamoDB (Amazon DynamoDB 成本分配标签简介)、Lambda (AWS Lambda 支持标签和成本分配) 和 EBS (全新 – AWS 快照的成本分配)。 现在，我们将发布适用于 Amazon Simple Queue Service (SQS) 的基于标签的成本分配。您现在可以将标签分配到您的队列并使用它们在任何需要的级别管理您的成本：应用程序、应用程序阶段 (针对通过队列进行通信的松散耦合的应用程序)、项目、部门或开发人员。在标记您的队列后，您可以使用 AWS 标签编辑器来搜索具有相关标签的队列。 下面是我要将三个标签 (应用程序、阶段和部门) 添加到我的一个队列的方法： 此功能现已在所有 AWS 区域推出，您可以立即开始使用！要了解有关标记的更多信息，请阅读标记您的 Amazon SQS 队列。要了解有关通过标签进行成本分配的更多信息，请阅读使用成本分配标签。要详细了解如何使用消息队列为现代应用程序构建松散耦合的微服务，请阅读我们的博客文章 (利用 Amazon SQS 和 Amazon SNS 构建松散耦合、可扩展的 C# 应用程序)，并观看我们最近的网络研讨会使用 Amazon SQS 和 Amazon SNS 解耦和扩展应用程序的录像。 […]

距 AWS re:Invent 召开只有短短 40 天了，我的同事和我希望分享一些提示，帮助您充分利用在拉斯维加斯停留的这段时间。与往常一样，我们的侧重点是培训和教育，但我们会穿插一些业余时间的娱乐和休闲活动，让您适当放松心情。 地点，地点，地点 re:Invent Campus 将覆盖整个拉斯维加斯大道，在美高梅大酒店 (MGM Grand,)、阿里亚酒店 (Aria)、梦幻酒店 (Mirage)、威尼斯人酒店 (Venetian)、宫殿酒店 (Palazzo)、金沙博览馆 (Sands Expo Hall)、林尼克酒店 (Linq Lot) 和安可酒店 (Encore) 举行活动。每个场地都会举办特定主题的活动： 美高梅大酒店 (MGM Grand,) – 业务应用程序、企业、安全性、合规性、身份和 Windows。 阿里亚酒店 (Aria) – 分析与大数据、Alexa、容器、物联网、人工智能与机器学习以及无服务器。 梦幻酒店 (Mirage) – 训练营、认证和认证考试。 威尼斯人酒店 (Venetian) / 宫殿酒店 (Palazzo) / 金沙博览馆 (Sands Expo Hall) – 架构、AWS Marketplace 和服务目录、计算、内容分发、数据库、开发运营、移动、网络和存储。 林尼克酒店 (Linq Lot) […]

“成竹在胸。” — Stephen R. Covey 在上一篇文章中，我断言今天的技术执行官需要扮演首席变革管理官 (CCMO™) 的角色，领导其组织完成企业云之旅。本文将探讨与该职责相关的三个主题中的第一个：合并业务与技术 (统一管理)。另两个是提供明确的目的 (对下管理) 和制定 (或打破) 新的规则 (管理执行)，我将在后续文章中进行讨论。 今天，成功的技术高管必须帮助他们的行政助理了解技术如何适应 — 甚至推动 — 其业务发展。如果组织理解这一点，您的执行团队就会意识到您对组织的业务目标负有领导责任，您是执行团队的重要成员。 当前的业务领域受到一些新兴公司的冲击，创建和运营这些公司的高管和企业家不仅了解如何将技术应用于其业务，还将确定在整个行业中发挥作用的角色技术。例如，运营酒店业务的 AirBnb、提供汽车相关服务的 Uber、实现家庭自动化的 Nest Labs、提供存储服务的 Dropbox 等。虽然这给传统企业带来了压力，但也为世界各地的 IT 高管们创造了机会。与从事技术工作的人员相比，没有人比他们更了解如何运用技术来满足市场日益增长的需求。对于大部分职业生涯都是在大公司中度过的我们来说，这一点尤其正确。我们说着相同的企业术语，了解哪些限制条件是硬性的，哪些是可变通的，也知道如何跟您的每位高管沟通。公司不能再指望让技术高管们在幕后默默工作就能取得成功。 而且，由于云承担了传统上与企业 IT 相关的许多千篇一律的繁重工作，今天的 IT 主管可以将更多的时间和资源投入到推动业务发展和保持组织竞争力的活动中。云是这些新兴颠覆性力量使用的关键工具。使用这种工具不意味着为您提供发展业务所需的想法，但这样可为所有人提供更多的可能性，让竞争环境更加公平。 下面是一些提示，供准备引领组织踏上云之旅的您参考： 关爱同事 迁移到云并不只是一次技术转变。它是一次业务变革，管理层的所有人都应该关心这一点。您的工作是考虑执行团队及其职能会受到哪些影响，或可能会受到云之旅的哪些影响。 我无法在一篇文章里介绍太多类型的高管，但是： 首席财务官通常关注如何降低前期成本以及只支付所用费用的能力。我发现每月成本变化时常会引起一些摩擦，但总拥有成本始终较低，特别是当您摆脱了容量规划和维护活动的负担时。与您的财务主管密切合作，预测支出、管理资源利用率、错开预留实例 (RI) 的购买时机 (因为您更熟悉自己的环境)，并考虑如何利用劳动力成本 (因为随着时间的推移，您的资源会越来越多地专注于产品开发和创造资产)。 首席营销官通常关注如何保持公司品牌的新鲜度，以及应对不断变化的市场形势。如果您的品牌网站能够一天更新数次而不是一月才更新一次，会产生什么样的影响？能够无限扩展的数据仓库如何帮助首席财务官更好地了解客户？如果试错成本很低甚至不需要付出成本，他们可以对一小部分用户尝试哪些试验？ 人力资源副总裁希望看到您适当地关爱员工，了解您如何聘用具有新技能的员工。充分利用 AWS 培训和认证，在您自己培训课程中采用我们的培训专业知识。在关于该主题的后续文章中，将探讨如何指导您的员工 – 小心剧透 – 只要愿意学习，您团队中的每一个人都能为您的云之旅做出贡献。此外，请与其他要迁移到云的公司建立合作关系，了解他们如何聘用新角色以及如何管理现有员工的职责转变。例如，DevOps 文化如何融入您的组织，运行您构建的内容意味着什么？ 首席执行官关注以上所有事务，以及公司如何保持竞争力。运用您从其他高管处获得的信息塑造完整的愿景，并展示如何利用现代技术在同样的限制条件下完成以前无法实现的任务。 在道琼斯，我设定了一个目标：每个月邀请几名高管一起就餐。就餐期间，我什么都不做，只听他们有什么抱怨。然后，我根据掌握的信息调整我们的策略，并确保向他们传达其影响力会如何改变我们的方向。这是一个展现对高管需求的关心、建立信任并获得他们支持的简单愉悦 (如果您喜欢社交和美食) 方法。运用这个方法的关键在于：您不仅要倾听，还要根据获得的信息采取行动。 寻求帮助 您不必独负重担。您可以将客户经理看作旅途中的领队。他们会很乐意与您及您的执行团队合作，帮助传达讯息并从迁移到云的过程中获益，使其与您的业务保持一致。如果您需要的影响力超出了客户经理的专长范围，他们会寻找合适的人员，不管是在 AWS 内部还是外部。我们很乐意为您创造机会，让您能够与志同道合的人同行 — 不只是在我们倡导的活动中，而是您旅途中的任意时刻。我在担任上一个职位时，跟其他公司做过一些交流，与其他高管交流不仅能够获得启发，还可验证自己的想法。 AWS 合作伙伴网络和 AWS 培训和认证也是加快您的云之旅的绝佳资源。在讲述最佳实践时，我会更详细地介绍。但是，我发现很多公司会与人力资源部门合作，将基于我们计划的 AWS […]

就算没有故意保送上垒规则，他的队友还是会保送他上垒，队友只需要装作无意地故意保送他上垒就行了。您心里知道的远比眼睛看到的东西要多得多。-George Brett 我经常说我认为采用云技术能够给企业带来变革，但这是个需要时间的旅程。虽然每一个企业的云之旅都将是独一无二的，但我发现变革最快的企业都采用了深思熟虑和有条理的方法。这篇文章概述了 AWS 企业解决方案架构师 Peter Buonora 的一些想法。言归正传。

文本转语音技术可将任何数字文本转换为多媒体体验，让用户能够在处理多任务或进行其他活动时收听新闻、博客文章、甚至是 PDF 文档。借助 Amazon Polly，您可以转换 RSS 源或电子邮件，以音频文件形式存储合成语音。 目前，Amazon Polly 控制台支持粘贴长度不超过 1500 个字符的文本、选择语言和区域以及选择语音。之后，您可以聆听转换后的文本或将其下载为 MP3 文件。此外，您还可以使用 AWS 命令行界面 (AWS CLI) 从 AWS 管理控制台执行转换。 复制少量要试听的文本，然后打开控制台。 1. 在搜索框中键入 Polly。 2. 要试用 Amazon Polly 服务，请在 Plain text 选项卡中粘贴文本并聆听输出。 如果要使用 Amazon Polly 将书籍等长格式文本转换为语音，则需要将文本切分成 1500 字符长的数据块。如果 AWS CLI 命令能够接受不限大小的文本文件作为输入并自动转换成 MP3 文件，岂不是更好？

本文是我们的系列中的第二篇博客文章，旨在指导您制作 1/16 比例的无人驾驶车辆。您还可收听我们的 Twitch 网络直播以回顾这些博客文章中讨论过的概念。在跟随我们操作之后，您可以将您自己的车辆带进 re:Invent Robocar Rally 2017 的赛道，也可以使用我们提供的车辆。 在我们的第一篇博客文章中，我们制作了一辆 Donkey car 并将导航服务器部署到您的 Amazon EC2 实例上。在本篇博客文章中，我们将布置一个赛道并教您的车辆使用 Amazon EC2 Systems Manager 和 AWS IoT 进行驾驶。如果您已经关闭了 Donkey Server EC2 实例，现在请将它打开并获取其公共 IP 地址。获取公共 IP 地址后，我们会将您的车连接到 EC2 Systems Manager 以远程访问它。之后，我们会将您的车连接到 AWS IoT 以跟踪可用来与好友比较圈速的遥测数据。 赛道布置 教您的车驾驶的第一步是布置赛道。准备好赛道后，您需要驾驶您的车辆在赛道上跑第一圈以开始训练其神经网络。我们要使用的车的速度相当快并且转弯半径不太大，因此您需要从没有急弯的赛道开始。 除此之外，您布置的赛道的大小受您的可用空间和您手头的胶带数的限制。您可在设计中尽情发挥创意，但要确保将各个角度的左转和右转考虑进去以便让您的神经网络接触多种不同的情况。请记住，您的车辆使用其前置摄像头观察您布置的赛道，因此您需要确保能够轻松区分胶带与地面。 赛道设计提示和技巧 与具有各种光亮和阴影水平的室外赛道相比，室内赛道提供的持续照明产生更好的效果。 您的车通常具有最小 30 度的转弯半径，因此在设计拐角的弯度时应记住这一点。 您可使用白色丝带和蓝色喷涂胶带制作临时赛道。 您还可使用一条白线作为赛道。行为克隆方法将学习沿着线驾驶。 无光表面胶带的效果比光面胶带的更好。

从今天开始，可以从 Amazon VPC 内部连接到您的 Amazon Elasticsearch Service 域，而无需 NAT 实例或 Internet 网关。Amazon ES 的 VPC 支持易于配置、非常可靠，还可以提供额外的保护层。凭借 VPC 支持，Amazon ES 与其他服务之间的所有流量都可以留在 AWS 网络中，从而与公共 Internet 隔离。您可以使用现有 VPC 安全组管理网络访问，也可以使用 AWS Identity and Access Management (IAM) 策略提供额外保护。Amazon ES 域的 VPC 支持不收取额外费用。 入门 在您的 VPC 中创建 Amazon Elasticsearch Service 域很容易。只需要遵照正常创建集群的所有步骤，然后选择“VPC 访问”。 就是这样。无需其他步骤。现在就可以从 VPC 中访问您的域了！ 需知信息 为了支持 VPC，Amazon ES 至少在您 VPC […]

我首次介绍 Amazon Lightsail 是通过去年的一篇博客文章：Amazon Lightsail – 兼具 AWS 的强大功能与 VPS 的简易性。Lightsail 自去年推出以来，数千名客户已使用它启动了基于 Linux 的虚拟专用服务器，从而开启了 AWS 之旅。 今天，我们又增加了对基于 Windows 的虚拟专用服务器的支持。您可以启动运行 Windows Server 2016、Windows Server 2012 R2 或 Windows Server 2016 (结合 SQL Server 2016 Express) 的 VPS，并在几分钟内投入正常运行。您可以使用 VPS 生成、测试及部署 .NET 或 Windows 应用程序，而无需安装或运行任何基础设施。只需一两次点击，备份、DNS 管理和运行指标，一切尽在掌握。 提供五种规模的服务器，512 MB 到 8 GB 的 RAM，1 或 2 个 vCPU，以及高达 80 […]

“人生最难的就是要学会哪座桥可以过，哪座桥可以烧。”–David Russell 在以首席信息官的身份负责多个基于云服务的业务解决方案的交付工作时，我开始对混合架构有了一些自己的看法。在过去的 5 个月里，我有幸与大公司的首席信息官和首席技术官进行了数十次对话，这进一步加深了我对这个主题的想法。与此同时，我阅读了许多讨论混合架构的文章和博客，我看不出行业对采用云技术的混合架构是否达成了共识。 公司出于各种不同的原因采用云技术。云采用者已获得敏捷性提高、成本降低和全球影响力扩大等优势。对于我接触过的许多首席信息官来说，实际上可归结于它能够将宝贵资源充分转化为能够促进业务发展的资源。换句话说，将与管理基础设施相关的千篇一律的繁重工作转化为与构建其品牌知名产品和服务相关的活动。 也就是说，大多数企业的 IT 组织已经建立了他们今天所运营的基础设施和管理模式。我接触过的许多首席信息官希望尽快将这一基础设施迁移到云，但必须认识到，有意义的云采用是一个需要时间的过程。在迁移到云的过程中，公司需要一种能够保持系统正常运行同时充分利用其现有投资的方法。在我撰写的有关企业云之旅的文章中，我讨论过公司应该如何使用 AWS Virtual Private Cloud (VPC) 和 Direct Connect 将其本地基础设施拓展到 AWS 上，以创建混合架构。对我来说，这是最有意义的混合架构，也是许多公司在最大限度地利用云的优势时所采取的步骤。 除此之外，关于混合架构的对话就变得有些复杂了。我在市场评论中发现了三个趋势，初看起来挺有道理，但稍一深入分析，就会发现这些观点站不住脚。这三个误区是： 误区一：混合架构是永久目的地。用“永久”来形容这一观点有些太过绝对了。拥有大量陈旧系统的大型公司将运行混合云架构一段时间 (可能是以年计数)。每个组织的云之旅会有所不同，每个人都将按照自己喜欢的步伐前进。但是，我认为未来不会有太多公司运营自己的数据中心。其淘汰过程可能需要 3 年以上的时间，但我确信这一定会在 15 年内实现。能够加速这一转型的因素至少有四个： 1. 云提供商实现的规模经济效应将随着采用范围的扩大而不断增长。这些优势终会通过这样或那样的方式令云消费者受益。 2. 云技术的创新步伐是前所未有的。2014 年，AWS 发布了超过 515 项增强功能，近 3 年来创新速度几乎翻了一番。 3. 公司运行业务所依赖的技术 (如电子邮件、生产力、人力资源、CRM 等) 越来越多地构建在云中。 4. 有助于企业迁移到云的技术和业务的数量正在迅速增长。您看看 AWS Marketplace 和 AWS 合作伙伴网络就知道了。 误区二：混合架构允许您在本地基础设施与云之间无缝迁移应用程序。表面上看起来好像很有吸引力，但这个前提有一个根本性的缺陷。它假定云和本地基础设施具有同样的能力。我知道很多公司都具备管理其基础设施的能力。与此同时，有很多公司是想要获得其数据中心不具备的功能和特性才迁移到云的，这些功能和特性有：真正的弹性、安全性、随用随付、持续不断的创新流等。您在设计应用程序的架构时，如果想要在自己的数据中心和云间无缝切换，则您的应用程序的功能就只能限定为数据中心和云都具备的功能集合。 误区三：混合架构允许您跨多个云提供商无缝地代理您的应用程序。我认为，这个论点有一个细节值得探讨。公司正在使用各种不同的云解决方案来满足其业务需求。这通常包括基础设施服务的混合，以及运行在公司数据中心之外的其他地方 (通常是在 AWS 上) 的打包解决方案。这完全讲得通。IT 高管应该关注他们试图解决的问题，并根据其面临的限制条件挑选最佳的工具来解决它。 但令我感到惊讶的是，很多公司掉入了陷阱之中：他们尝试构架单一应用程序来在多个不同的云提供商的服务上运行。我明白工程师为什么喜欢这样做 —  – 对工程师来说，造出能够使不同的云协同工作所需的“胶水”是一项莫大的成就。但遗憾的是，这种工作会抵消组织迁移到云所获得的生产力提升。我一直认为这是一种倒退的举动。除了管理自己的基础设施以外，您现在还需要解决多种服务的差异性问题。跟误区二一样，这也会将其应用限制到所有架构共有的功能集合。 […]

“好皮肤是妆容的最佳基础”- Holland Rolland 最近，我在一篇文章中介绍了一种称作“采用阶段”(SofA) 的心理模型，它描述组织在实现云优先时所经历的旅程。我发现，这个旅程与其说是技术行为，不如说是一种领导力和变更管理行为。尽管没有通用的答案，我还是希望在高管们引导组织踏上云之旅时，把 SofA 看作是一个有用的模型。 我的上一篇文章主要介绍第一个采用阶段 (我称之为“项目”)，其中介绍了我在开启云之旅的组织中的所见所闻。 通常只需要几个项目，大多数组织就能意识到云上的交付速度能够快多少。这篇文章介绍我发现各组织投资的四个典型领域，他们通过这些投资将云优势拓展到整个组织；我把这称为“基础”阶段。 1. 创建云卓越中心 (CCoE) 团队 我认为创建 CCoE 是组织最重要的基础投资之一，特别是在您需要发展自己的企业文化时。与我对话的许多组织使用其 CCoE 作为支点在组织中的各个层面推行变革，这是我在企业取得云迁移成功的飞轮中提到的趋势。 正如我在组建 CCoE 团队中所说的那样，我希望看到组织组建一个具有多样化视角的跨职能团队。随着系统管理、数据库管理、网络工程和运营等领域通过代码实现自动化，其传统角色正在逐渐融合。我坚信您已经拥有成功实现云迁移所需的人才，只要渴望学习新知识，今天这些岗位上的任何人都适合成为 CCoE 团队的成员。您可能已经知道哪些人适合，哪些人不适合。 在组建 CCoE 时，请考虑各个业务部门如何与之协作，以及组织如何掌控 (集中/分散) 技术选择。 例如，我们在道琼斯组建 CCoE 团队时，将其命名为 DevOps，有意将它与描述运行您构建的内容理念的术语混杂使用。我们的目标是让 DevOps 团队规定运营模式，体现我们倾向于在企业中实施的最佳实践、管理方式和护栏，同时仍然允许各个业务部门自主做出其所需的决策，从而在受控的时间期限内完成其目标。随着 DevOps 团队的日渐成熟，我们的参考架构 (见下文) 也不断完善。我们发现，越来越多的业务部门希望使用 DevOps 团队提供的内容，因为它们可以加快其工作速度、提高其运营效率，而不是因为我们强迫他们使用这些内容。 2. 构建参考架构，在企业各处反复使用 鼓励您的团队在其负责的应用程序中寻找通用模式。如果找到可满足多个应用程序需求的参考架构，则创建脚本来实现该参考架构的自动构建，同时将其纳入安全和运营控制体系。它可能非常简单，如为各种操作系统创建“黄金映像”供您的团队使用；也可能十分复杂，如用于描述托管的所有网站的架构和运营模式的蓝图。 每个参考架构都应考虑如何与您的本地资产通信。我在有关混合架构误区的文章中说过：“我接触过的许多首席信息官希望尽快将基础设施迁移到云，但必须认识到，有意义的云采用是一个需要时间的过程。在迁移到云的过程中，公司需要一种能够保持系统正常运行同时充分利用其现有投资的方法。”有些组织创建一些安全组，以符合其现有控制体系规定的方式穿过本地防火墙进行通信。然后，他们在不同的参考架构中重用这些安全组。 使您的 CCoE 能够观察整个 IT 产品组合，让他们更容易发现和扩展参考架构。在进行扩展时，AWS Service Catalog 可以帮助您在整个组织中存储、许可和分发参考架构。 3. 培育试验文化和发展您的运营模式 云是我职业生涯中见过的最大试验推动力，许多组织使用云之旅作为一项有力的功能来重新考虑其传统 IT 运营模型。 我发现越来越多的组织开始重新考虑为每个业务部门提供多少技术选择自主权。此外，他们还仔细思考如何管理角色和权限、谁负责成本、可以/应该使用哪些工具进行监控和日志记录，以及谁能影响环境中的变化。 例如在 Amazon，每项服务都由一个“双披萨团队”负责，该团队对其提供给客户的服务承担全部责任。这包括所使用的技术、服务的路线图、服务的运营等。 […]