Author: AWS Team

一、介绍 Caffe 是一个高效的神经网络计算框架，可以充分利用系统的GPU资源进行并行计算，是一个强大的工具，在图像识别、语音识别、行为分类等不同领域都得到了广泛应用。有关Caffe的更多内容请参考项目主页： http://caffe.berkeleyvision.org/ 不过Caffe的常用部署方式是单机的，这就意味着它的水平扩展能力受到了限制。使用者可以通过在系统中添加多个GPU的方式提高并发度，不过其并发能力最终受到单系统可支撑的GPU数量的限制。同时，神经网络计算往往又是计算消耗很大的，所以人们在使用Caffe的时候都可能会希望有一种并行计算框架可以支持Caffe。 而我们知道Spark是基于内存的计算框架，基于Yarn, Mesos或者是Standalone模式，它可以充分利用多实例计算资源。因此，如果能够结合Caffe和Spark，Caffe的能力将得到更充分的发挥。 基于这些原因，Yahoo开源的CaffeOnSpark框架受到的极大的关注。 有关CaffeOnSpark的源代码和相关文档，请大家参考： https://github.com/yahoo/CaffeOnSpark 今天我们要进一步讨论的是如何在AWS EC2上部署CaffeOnSpark, 充分利用AWS服务提供的GPU实例构建强大的分布式神经网络计算框架。 在CaffeOnSpark的文档中有明确指出EC2上部署CaffeOnSpark的步骤，具体请参考： https://github.com/yahoo/CaffeOnSpark/wiki/GetStarted_EC2 但是文档的一些部分写得比较简单，初步接触的读者可能在执行过程中遇到一些问题，所以在这里将我个人的安装配置过程整理了一下供大家参考。 安装过程大概可以分为四部分： 下面会在“环境准备”一节中具体描述这几个步骤的细节。 二、环境准备 首先我们打开文档https://github.com/yahoo/CaffeOnSpark/wiki/GetStarted_EC2， 看看文档中刚开始的部分对于环境准备的要求。 里面首先提到我们需要准备“EC2 Key pair”, 就是要准备EC2启动需要的密钥对。当然，为了创建“EC2 Key pair”，为了启动EC2，你首先需要一个AWS账号。有关AWS账号的申请和基本使用这里就不细述了，请参考其它相关文档。需要注意的是你拿到的AWS账号需要有基本的权限才能完成CaffeOnSpark的安装工作，其中包括创建EC2实例，创建安全组等。 “EC2 Key pair”是你在创建EC2实例时创建的密钥对，创建过程中你有一次机会下载私钥文件，就是文中提到的pem文件。如果你之前没有创建过EC2，你也可以直接在EC2控制台的“网络与安全->密钥对”界面中点击“创建密钥对”按钮进行创建。同样，创建过程中你有一次机会下载pem文件，下载后注意保管好该文件，后面都会依赖这个文件。 按文档的描述，有了以上的资源以后就可以执行以下命令： 为了准备环境，我们需要先理解一下上面的脚本。脚本的刚开始部分是一系列变量的定义，我们先了解这些变量的作用。 第一句比较简单，从变量名可以知道这是指定了要使用的AMI的ID： 这个镜像是一个已经安装好Spark、CaffeOnSpark，并加载了常用神经网络测试数据的Ubuntu镜像。该镜像由CaffeOnSpark团队提供，已经共享给所有AWS账号。 不过稍有AWS使用经验的同学会意识到，这样的命令是针对特定的区域（Region）的，因为同一个AMI镜像拷贝到不同AWS区域时它们的AMI ID是不一样的。在命令行中如果指定了一个AMI的ID，就意味着这些命令只能在特定的AWS区域正常工作。 所以我们需要继续查看后续命令，看看哪里指定了区域。幸运的是，命令的第二行就是指定区域的命令： 我们知道区域代码“eu-west-1”指的是欧洲（爱尔兰） 区域，意味着我们运行完这个样例后我们的CaffeOnSpark群集是运行在欧洲（爱尔兰） 区域的。因为EC2 key pair也是按区域分的，所以我们创建的EC2 key pair也应该是在欧洲（爱尔兰） 区域。 为了在欧洲（爱尔兰） 区域创建你的EC2 key pair，你可以点击AWS控制台右上角的区域选择框，选择欧洲（爱尔兰） 区域，然后再按步骤进入EC2的控制台创建EC2 key pair. 同时，你也可以去EC2控制台的“映像->AMI”界面查找镜像ID为ami-5ff7782c的镜像，记得查看时选择“映像类型”为“公有映像”，而不是“我拥有的”。找到这个镜像你还可以仔细查看一下其它相关信息。 如果你发现镜像列表中没有ID为ami-5ff7782c的镜像，有可能你阅读本文的时候相关方已经更新了新的镜像，你可以去CaffeOnSpark的主页 https://github.com/yahoo/CaffeOnSpark […]

关于本文 本文详细阐述了如何在Java客户端和Node.js服务器上使用和测试Alexa语音服务。 本实例需要用Node.Js来获取Login的授权码。 本指导提供详细的操作指南对于在取得示例授权码、依赖性和在运行Pi的过程中相应的硬件部署。对于Windows， Mac，或者通用的Linux指令，可以看这里的向导。 开始 所需硬件 1. Raspberry Pi 2 (Model B) –在亚马逊上购买。升级：当然，Raspberry 3也是可以的，请点击这里查看详细操作。Pi的用户-请点击这里来获取帮助。 2. 微型的-USB 电源线 供树莓派来使用（包括在树莓Pi中） 3. 微型的 SD 卡– 需要预装NOOBS – Raspberry Pi 8GB Preloaded (NOOBS) Micro SD Card 4. 网线 5. USB 2.0 小型麦克风 – Raspberry Pi 没有自带麦克风，需要外接来与Alexa进行交互-在亚马逊上购买 6. 外部扬声器3.5mm音频插座/立体声耳机插孔-在亚马逊上购买 7. 一个 USB 鼠标和键盘，以及一个支持HDMI的外部显示器 – 如果由于某种原因无法通过SSH协议进入到你的树莓派时，我们也推荐你使用USB键盘、鼠标和一个便于使用的HDMI显示器。稍后可以查看关于“SSH”协议的内容。 8. 无线WiFi适配器（可选）在亚马逊上购买 所需技能 1. […]

（本操作文档部分叙述内容与技术知识引用自AWS官方网站） 要在 Amazon EC2 中使用您的 VM，您必须首先将其从虚拟化环境中导出，然后使用 AWS Command Line Interface (AWS CLI) 或 API 工具将其导入 Amazon EC2。（AWS Console不支持从VM导入AWS的操作功能。） 从总体上看，要将VM导入到Amazon EC2中，需要经过以下五个步骤： 1. 安装 AWS CLI。 2. 为 VM 导入 Amazon EC2 做准备。 3. 从虚拟化环境中导出 VM。 4. 将 VM 导入 Amazon EC2。 5. 在 Amazon EC2 中启动实例。 本次实验使用VMware Workstation 10，把Ubuntu原生镜像ubuntu-12.04.5-desktop-amd64.iso导入到VMware Workstation 10。自行个性化操作后，利用VMware Workstation 10导出OVF映像的功能，获得VM的vmdk文件。并用AWS CLI，以流优化型 ESX 虚拟机磁盘 […]

随着云成为新常态，越来越多的客户开始采用AWS云服务，使用VPN隧道安全的连接到AWS成为一个常见的场景。本文介绍一种仅需少量交互与配置即可与多个AWS VPC建立动态路由VPN连接并在各个互联VPC之间转发流量的方案。该方案主要使用了Docker、IPSec套件strongSwan、动态路由软件BIRD，并在此基础上，使用AWS SDK for Python( Boto 3)、docker-py等实现快速建立与AWS VPC的动态VPN。 项目中使用的Dockerfile、相关的shell脚本以及Python应用等源文件均已经在这里开放，做为一种快速部署Customer Gateway的方法，供各位读者参考。 本文假定读者从概念上理解AWS VPC、IPSec VPN以及动态路由协议BGP。如果希望了解更多如何与AWS VPC建立VPN连接的信息，读者可以参考 AWS VPC 网络管理员指南。 如何使用 我们从最基本的场景开始，假定您需要将本地网络与单个AWS VPC通过IPSec隧道互联。 图中Customer Gateway应为一台可以访问Internet且IP固定的 Linux服务器， 这台服务器将作为IPSec网关和BGP路由器，将内部网络与AWS VPC通过IPSec隧道和BGP动态路由协议连接起来。 在Customer Gateway上执行如下预备工作: 一、我们需要 预先安装和配置好docker引擎; 二、我们的脚本使用了Python和一些第三方库，所以需要安装Python 2.7或更新版本以及Python包管理工具，例如pip 三、通过pip安装如下软件包; a. boto3 —— AWS SDK for Python，用于获取VPN连接的配置信息 b. xmltodict —— 便于python处理XML格式的数据 c. docker-py —— 用于连接docker engine并创建、运行容器 四、配置boto3连接AWS的 IAM凭证，需要注意使用的IAM用户需要拥有执行describe_vpn_connections API所需的权限。 $ cat  ~/.aws/credentials [default] […]

根据AWS的推荐设计原则，搭建一个云端应用系统时，需要记住的一个原则是“design for failure”，也就是系统架构设计的时候需要考虑到应用系统的每一个层面，包括硬件和软件是可能出现故障的，并据此在应用系统架构设计上消除单一故障点，从而实现高可用性的系统架构。 有些应用由于历史或其他原因，没有按照这个原则设计高可用的架构，因此在部署上存在单一故障点，比如某一台EC2实例的软件或者底层硬件出现故障的时候会影响到这部分应用。如何保证或者大大提高单机EC2的可用性是非常重要的问题。 针对这些用户的需求，AWS推出了两个非常有用的监控功能：自动重启(auto reboot)EC2实例的CloudWatch警报和自动恢复(auto recovery)EC2实例的CloudWatch警报。这两个警报能够在你设定的阀值内自动重启因为实例故障或者底层硬件故障的EC2实例，最快时间恢复实例健康，从而大大降低了down机时间，让应用系统快速从软件或者底层的软硬件故障中自动地恢复，大幅度提升应用的整体可用性。具体介绍如下： 自动恢复EC2实例的CloudWatch警报 任何物理机都可能发生故障，云端的物理主机也不例外。使用AWS云平台，当底层硬件发生故障时，你无需人工干预或者联系AWS的支持工程师帮助您处理并恢复实例，通过事先创建CloudWatch 的StatusCheckFailed_System（状态检查失败（系统））警报监控 EC2 实例，在实例运行的物理主机发生底层硬件故障的时候能够自动触发警报，一方面根据配置发送通知给贵司相关人员，另一方面以最快时间将实例迁移到健康的物理硬件上，并保持实例 ID、私有 IP 地址、弹性 IP 地址以及所有实例元数据不变。 自动恢复实例的Cloudwatch警报有以下要求： ·       仅支持C3、C4、M3、R3 和 T2 实例类型 ·       仅支持VPC 中的实例，不支持EC2-Classic 实例 ·       仅支持完全使用EBS 存储的实例，不支持使用任何实例存储卷的实例 自动重启EC2实例的CloudWatch警报 以前当您遇到由于实例内部的软件故障导致实例无法正常访问时，你只能选择手动重启实例让实例从故障中恢复，这个过程由于需要人工的干预，可能导致较长时间的实例不可访问。现在，您可以创建Cloudwatch的StatusCheckFailed_Instance（状态检查失败（实例））警报监控 EC2 实例，并在实例运行状况检查失败时自动重启此实例，从而实现在短短几分钟时间内即可重启您的实例并恢复实例。重启实例时，其仍驻留在相同的物理主机上，因此您的实例将保留其公有 DNS 名称、私有 IP 地址及其实例存储卷上的任何数据。 如何配置 为了大幅度提升单机的高可用性，建议您在一个实例上同时配置上述两种Cloudwatch警报，以监控软硬件故障并自动恢复实例。配置的时候需要注意的一点是：使用IAM user创建两个警报，其中自动重启EC2实例的警报的检测周期必须要大于自动恢复实例的警报的检测周期，比如下面例子中，自动重启EC2实例的检测周期是3，自动恢复EC2实例的检测周期是2。 自动重启EC2实例的警报的示例（StatusCheckFailed_Instance）： 自动恢复EC2实例的警报的示例（StatusCheckFailed_System）：   更多信息请参考 http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/DeveloperGuide/UsingAlarmActions.html#AddingRecoverActions http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/DeveloperGuide/UsingAlarmActions.html#AddingRebootActions  

作者 Werner Vogels 发布于 2016年3月14日 10 Lessons from 10 Years of Amazon Web Services AWS（Amazon Web Service） 开始于 2006 年 3 月 14 日 Amazon S3 的发布，距今已有十年时间。回首过去十年，我们在构建和运营 AWS 云计算服务中积累了大量的经验教训——这些服务不仅需要确保安全性、可用性和可扩展性，同时还要以尽可能低廉的成本提供可预测的性能。考虑到 AWS 是世界范围内构建和运营此类服务的开拓者，这些经验教训对我们的业务来说至关重要。正如我们多次重申的，“经验不存在压缩算法”。考虑到 AWS拥有每月超过一百万的活跃用户，而这些用户也许会为数以亿计的自家客户提供服务。因此，积累上述经验教训的机会在 AWS 比比皆是， 在这些经验教训中，我挑选了一些分享给大家，希望对各位也能有所帮助。 1.构建可持续演进的系统 从做 AWS 的第一天开始，我们就清楚地认识到，我们在做的这套软件不是一劳永逸的。现在可以用的软件，一年之后很可能将不再适用。我们的预期是，随着（用户）数量级的增加一或两次，我们都需要重新检视和适当修改我们已有的架构，以便解决扩展性的问题。 但是我们无法采取过去常用的通过检修停机进行系统升级的方式来实现上述目标，因为世界各地诸多业务都依赖着我们平台所提供的7 x 24 小时的可用性。因此，我们需要构建一个在引入新的软件构件时不会引起服务瘫痪的架构。Amazon 杰出的工程师 Marvin Theimer 有一次开玩笑说，Amazon S3 这项服务的持续演进用开飞机来形容最为贴切。我们最开始开的是一架单引擎的赛斯纳，一段时间后升级成一架波音 737，之后又换成了一支波音 747 小队，而现在更像是由空中巨无霸空客 A380 组成的一支大型机队。自始至终，我们一边通过空中加油确保飞机的正常飞行，一边在万米高空上将 AWS […]

2006年3月14日，计算时代的新纪元由此拉开帷幕。就在这一天，Amazon Web Services发布了Simple Storage Service（简称S3）。从技术角度讲，Simple Queuing Services的发布时间更早一些，但S3的发布真正点燃了这场云计算的燎原烈火。我对那一天仍然记忆犹新。当时我在Frontbridge Technologies公司担任总经理，这是一家由微软全资掌控的子公司，负责提供云托管邮件反垃圾、反恶意与归档服务。结合这番经历，我意识到云托管服务能够为客户带来的可观价值。我也意识到，客户热爱如此高效的配置方式与如此多样的低成本实现途径——这一切让我的态度发生了转变。那时的我得出了肯定的结论，云托管将成为未来的新方向。 不过Amazon Simple Storage Service的发布仍然令我感到大开眼界。当时技术行业每天都会发布上百项方案，其中大部分完全引不起我的兴趣——甚至连看一眼的愿望都没有。然而S3的发布则彻底改变了游戏规则。这项服务的最大亮点在于低廉到夸张的成本水平。其使用成本几乎比我们目前多数据中心冗余存储体系低出两个数量级。但更具颠覆性的是，用户可以利用手中的信用卡完成存储资源购买与配置。没有财务审批、没有专家建议、没有RFP、没有厂商选择流程、没有厂商谈判也没有数据中心空间核算。直接登录，着手使用——就这么简单！ 除了低廉的成本与便捷的配置方式之外，更让我意外的是这一技术成果的发布由Amazon——而非传统企业IT厂商——来完成。那些急于追求高利润、总会设置复杂谈判并喜欢在许可使用审计上做文章的厂商没能拿出这样的成果，而Amazon做到了。而这种令大多数企业IT部门欢呼雀跃的即时管理能力则让Amazon以不胜而胜的方式获得了可观的利润。这真的颠覆了我的认知——一家具有颠覆性的厂商、一种具有颠覆性的模式、一种低冲突配置途径外加一种起价极低并随时间推移而变得更低的价格设定。 S3的发布引发了整个技术行业的关注与惊叹——即使是那些发货量极大、且不会因此遭受任何营收损失的厂商。我被这款产品彻底迷住了，并最终编写了数千行代码以将S3作为底层存储系统。有时候S3显得比较笨拙，有时候则锐不可当，但为其编写应用让我坚定了自己的观点——这将成为其它更伟大事物的开端。 从决定编写应用到将该应用付诸运行共花掉了我几天时间，其中还包括调试与测试工作——当月末我收到了自己的Visa卡账单。我一直都清楚S3的价格非常便宜，但最终发现应用程序的整个开发与测试过程只花掉了3.08美元，这样的结果还是让我难以置信。在开发结束之后，我立刻将全部测试数据保存在了S3当中，而第二个月的账单来了——承惠0.07美元。 面对如此颠覆性的服务方案，我开始在企业内部发布评述博文并将其展示给包括CTO与CEO在内的众多高管人员。我在表达中还使用了一张Al Vermeulen——S3上的一名早期开发者——照片，外加一些S3的工作原理并阐述了其差异性所在——当然，还有我拿到的两张AWS账单。我的表达重点在于，这绝不是Amazon公司搞出的什么噱头或者小实验，而是真正实现基础设施服务交付的根本性新途径。存储只是第一步，计算也一定会很快跟进。 我对AWS的兴趣与时俱进，并在2007年参加了一次Amazon组织的用户会议——我最终于2008年正式加入了其技术团队。 作为AWS工程技术团队的一员，新环境给我留下的第一印象就是一个“快”字——决策制定流程非常迅速，新思路能够很快以代码形式推出，并立刻被交付至客户手中。这一切都让传统企业IT的响应速度看起来像是大陆板块漂移。我记得自己曾经半开玩笑地回忆过往角色称：“我们在十年中只发布了两次客户可能需要、也可能不需要的更新。”现在新功能正以惊人的频率推出，我们甚至很难追踪其推进节奏。 AWS的另一种有趣特质在于对产品及工程技术相关争论的处理方式。这类争议会频繁出现，而且AWS内部的辩论之声要远超过任何其它企业。这些决策的制定流程让我意识到，AWS除了拥有卓越的数据处理能力外，亦能够快速中止争论并拿出结论性意见。在AWS，我们不再自以为是地制定“战略”并强行说服客户认同其适用性，而是推出适合自身业务环境的方案，并通过面向服务的快速投入帮助更多客户快速享受至由其带来的便利。如此一来，优秀的服务能够快速演进为卓越的服务。 在过去的一系列角色中，我发现争论带来的思维碰撞根本无法切实转化为成果，甚至在多年之后仍然毫无动静。但在AWS，各部门几天之内就能够解析客户使用量数据并迅速将注意力转移到执行层面。相较于过往的缓慢节奏，这样的进度确实让人耳目一新。AWS的大部分工作成果最终被交付至客户手中，而不像我过去的工作那样将大部分精力耗费在解决内部矛盾上。这种出色的交付速度让AWS客户尽享优势，同时也为工程师带来了充满激情的梦幻般工作环境。 客户的认同正是创新成果的绝佳验证，而且毫无疑问，客户表现出的最大信任就是将全部业务迁移至云基础设施当中。Netflix成为第一家决定将100%业务负载交由云环境打理的企业。以下是一些已经全面登陆云端的客户：   2010年，Netflix   2013年，凯宾斯基酒店   2013年，Suncorp Group   2014年，Infor   2014年，日本通运   2014年，美国圣母大学   2014年，美国全国民主学会（NDI）   2015年，英国卫报媒体集团 从个人角度来看，企业客户决定全面拥抱云服务作为自身惟一基础设施已经成为整个技术行业最令人兴奋也最引人注目的实例。不过作为AWS创新速度的另一种实例，请大家跟随我的脚步纵观其在过去十年中掀起的一波又一波变革浪潮。 原文链接：http://perspectives.mvdirona.com/2016/03/a-decade-of-innovation/

原英文链接：http://blogs.aws.amazon.com/security/post/Tx71TWXXJ3UI14 在我们使用AWS的过程中, AWS IAM 是我们接触的第一个服务, 它具有强大的功能，可使您在AWS IAM中通过管理用户, 用户组, 策略, 角色, 证书, 密钥等来灵活而精确的控制对AWS 服务和资源的访问和权限. 同时在很多企业内部, 一般都已经部署了自己的用户管理及授权系统, 如何将AWS的用户管理及授权纳入现有系统则成为企业的想要解决的一个问题. 本文将介绍如何将企业内部Windows活动目录(Active Directory)和AWS通过ADFS(Active Directory Service) 进行集成, 从而实现在活动目录中管理用户对AWS服务和资源的访问和授权. 在AWS IAM中, 我们提供了对SAML的支持, 这个功能可以让我们可以和支持该标准的身份提供商进行联合从而实现单点登陆. 对于很多使用微软活动目录的企业, 我们可以使用Windows自带的ADFS进行和AWS IAM的集成. 工作原理: 在我们进行详细配置之前, 可以先看一下工作原理: 1.       首先用户访问和AWS做了集成的ADFS站点 (https://ADFS/adfs/ls/IdpInitiatedSignOn.aspx) 2.       用户在登陆页面输入用户名及密码, 提交以后ADFS将联系AD进行用户验证 3.       用户浏览器收到ADFS返回的SAML 断言 4.       用户浏览器将用户断言Post到AWS的Sign-in SAML终结点 (https://signin.amazonaws.cn/saml), Sign-in将调用AssumeRoleWithSAML API接口请求临时安全凭证并使用其构建管理控制台的登陆链接 5.       用户浏览器转向使用构建的登陆链接进行登陆 配置活动目录: 1.       在活动目录中及建立用户adfsuser, 邮件地址设为adfsuser@examplecom 2.       在活动目录中建立两个组AWSBJS-Admin, […]

2016-03-15 AWS 缺乏敏捷性并且行动速度滞后的企业在当今社会是难以具有竞争力的，看看那些初创公司对那些存在已久的行业都做了什么便知道了。 随着云计算的快速发展及概念的普及，云计算已经成为各类型企业发展的新常态。目前，世界上已经有许多家企业正快速地将自身应用向云端迁移，以此实现更加自由的创新和发展。这些企业不仅包括初创公司（例如 Dropbox、Airbnb、Pinterest、Hailo、WeTransfer），还包括许多成熟的大企业（例如壳牌、强生、通用电气、飞利浦、Netflix 和三星）。 与此同时，我们看到了大量的中国企业也正通过云计算的应用加速了发展的步伐。比如，小米正通过云计算服务开拓全球范围的智能手机用户；远景能源通过云计算管理着世界各地的智能风场；猎豹移动通过云计算为全球的用户提供手机安全的保障。 如今，云计算为企业提供了充分的平台空间和技术支持，让企业更为自由地发展成为可能。 打破传统的IT 部署 云计算可以让企业自由地构建和使用 IT 基础设施。在现如今的市场环境中，这已然成为了企业的发展基础。具体而言，云计算能够让企业自由灵活地使用IT 基础设施，以此在一定程度上让企业实现无限制的自由发展。 对于这些企业而言，若要开发面向用户或客户的完美体验及服务，来自云基础设施提供商的强大支持是必不可少的。而且，构建灵活的IT 基础设施需要两个关键因素——快速提供广泛、稳健的技术平台并且让其“唾手可得”。 云计算能够使这些企业拥有此类新能力，并且能够借助广泛而有深度的服务平台快速部署自身的 IT 资源。 因此，灵活的云基础设施不仅让企业行动的更快，而且能够为其消除所面临的诸多障碍。 例如AWS 可以在几分钟内为用户配置数千台服务器，可以在全球范围内为用户提供由多个数据中心支持的高可用性服务，可以在一个统一的平台上提供用户所需的功能和服务。同时，AWS 提供的不仅仅是大量的产品，而是深度的功能，满足用户对计算、存储、加密、数据库、访问控制等多方面的需求。让用户在使用云资源时更自由灵活。 每个人都是技术专家 在云问世之前，企业因成本过高而无法保存它们想要保留的全部数据。现在，云计算可以实现数据采集、存储、分析和共享，让企业享受到从未有过的方便和实惠。此外，目前企业内部真正能做分析的人的数量是很少的，通常只有那些技术人员才可以享受这些数据分析服务。但是，企业或客户也希望非技术人员能够以不太昂贵且便于操控的方式更快地了解数据现状，快速获得他们可转化为行动的洞察力。 通过云计算服务，非技术人员同样具备了数据分析“能力”，他们甚至能够利用移动设备分析数据。利用云平台服务，企业还可以享受关于数据的云自由，从大量数据中获取实际价值、然后将分析数据结果用于进一步的发展。自从使用云计算以来，企业已在数据分析上变得非常自由，正在以基于数据的方式有效地从事多种类型的开发和研究。 如Amazon QuickSight 就完全不同于旧式的解决方案，工程师再也不需要在首次可视化之前花费数周、甚至数月做数据建模了。其提供的可视化数据服务，其能够捕获图形、表格或故事，并可实现数据在内部或外部分享。 在云间自由穿梭 大约在2015 年，我们开始看到企业支持新用例（例如流传输数据）的需求：在我们的家中、工作场所、甚至在油田等场所有数百万个设备，它们连续传输数据——有时达到每小时数TB。借助云计算服务，处理起这些数据来比以往容易得多。 由于云计算的发展，企业的数据可在云间“自由穿梭”。但是，许多企业想通过更简单的方式将流数据载入云。 云服务可以有弹性地扩展支持大量的数据，让企业以时段或块大小连接数据，让企业能够利用标准的方法压缩数据。如果企业愿意，它们还可以选择在入站时加密数据并在使用时解密，方便地存储和轮换密钥。 摆脱数据迁徙的限制 向开源数据库迁移是企业追求更佳性能和更大灵活性的结果。然而，从专有数据库向开源数据库迁移不太容易。正如我们许多客户所证实的那样，云计算已彻底改变技术提供商和客户之间的关系。因此，企业可以摒弃专有数据库并自由地选择新数据库。 专有数据库的解决方案非常昂贵，它们具有专有属性并且拥有大量的锁定。这些数据库的供应商会核查客户，一旦发现任何不合规的应用方式，便会处罚客户。这也是许多客户想尽快摆脱专有数据库的原因。 但是借助这些开源数据库就想获得最佳性能是非常困难的。AWS 发布的新数据库引擎 Amazon Aurora，以开源数据库的价格向客户提供能够与商业级数据库相媲美的性能。从 2015 年7 月正式上市以来，Amazon Aurora 已经成为Expedia、通用电气、太平洋燃气电力公司 (PG&E) 和NBC 环球等企业使用的云服务。 不惧差异化的数据迁移 基于业务差异化，每家企业通常会选择不同的解决方案迁移数据入云。在云计算服务的支持下，用户可以以非常短的停机时间向开源数据库迁移较大规模的生产数据。企业也可以从源向云端新目标连续复制数据，并通过实时监控跟踪进度。这样就使得原本要花很长时间的迁移设置变得更迅速、更节约成本。 AWS 对多样化迁移方案的广泛支持使得其有能力帮助通用电气(GE) 在未来：从分散独立的数据中心向 AWS 迁移 9000 多个工作负载，包括 […]

从前的你是巨型的、从前的你是冰冷的，从前的你是安全的，但现在的你却是空荡荡的，因为你已经把所有资源都部署在了AWS云端。那么，你将会用你原来本地数据中心做些什么事呢？曾经令你自豪和喜悦的IT设施，现在给了你一个残严酷、昂贵的提醒：这个世界正不断地在改变。 许多AWS客户从他们现有的本地数据中心迁移到AWS云端。这里仅仅是他们其中的一些故事（案例分析，博客帖子和视频的链接）： Delaware North：这个花生和爆米花的供应商减少了他们90%多的服务器占地面积，预计使用5年以上的AWS服务，总体会帮他们减少3.5亿350万美金的IT采购和维护成本。 Seaco: 这一全球性的海上集装箱租赁公司通过将自己的SAP商务套件部署在AWS云端，在延迟方面减少了超过90%。 Kaplan: 作为一个教育和测试准备公司，Kaplan将曾经部署在12个本地数据中心的一套囊括开发、测试、分期和生产的应用环境部署在AWS云端，并关掉了12个本地数据中心中的8个。 Talen Energy: 作为企业剥离计划的一部分，这个核电公司决定将自己的IT设施迁移到AWS云端，之后他们能够将主要的精力聚焦在公司的核心业务。 Condé Nast : 这个著名的出版商完成了将超过500多台的服务器和将近1PB数据迁移到AWS云端，在之后会全部迁移到AWS云端。 Hearst Corporation: 这个多元化的通信公司将自己29个数据中心中的10个迁移到了AWS云端。 University of Notre Dame: 这所大学已经将自己的网站迁移到AWS云端，并且计划在未来三年将剩余工作的80%迁移到AWS云端。 Capital One: 这个财务公司已经将AWS作为其技术策略的核心部分。 General Electric: 这个多元化的公司已经迁移了超过9000个工作任务到AWS云端，并且关闭了34个数据中心中的30个。 如果你很好奇，下文就介绍了当关闭一个数据中心会发生的事情： 现在怎么办？ 您也许正在为您闲置的数据中心发愁，在迁移到云之后，您该如何处理它。 我的同事贡献了他们的想法（他们做了85%的工作），我已经列出了120种利用您的数据中心的方法。为了方便阅读，我将120方法分成了不同的类别。如您所见，我的同事们非常有想象力！这里有一些重叠，但我不想厚此薄彼。请阅读下文… 体育与休闲娱乐 1.                  冰球场 2.                  竞技场 3.                  卡丁车赛道 4.                  雪鞋练习场 5.                  激光枪运动 6.                  彩弹运动 7.                  汗蒸 8.                  瑜珈 9.                  沉浸式虚拟现实游戏领域 10.              史上最大型纸足球比赛 11.              […]