亚马逊AWS官方博客

AWS Team

Author: AWS Team

AWS Organizations —— 管理众多账号再也不是难题

AWS Organizations简述 AWS Organizations 可为多个 AWS 账户提供基于策略的管理。借助 AWS Organizations,您可以创建账户组,然后将策略应用于这些组。Organizations 支持您针对多个账户集中管理策略,无需使用自定义脚本和手动操作流程。 使用 AWS Organizations,您可以创建服务控制策略 (SCP),从而集中控制多个 AWS 账户对 AWS 服务的使用。Organizations 支持您通过 包括API,SDK和Console界面创建新账户。Organizations 还有助于简化多个账户的计费模式,即您可以通过整合账单(Consolidated Billing)为您组织中的所有账户设置一种付费方式。所有 AWS 客户都可以使用 AWS Organizations,且无需额外付费。要注意的是任意的AWS账户只能存在一个Organization中。 AWS Organizations关键性概念 在正式接触AWS Organizations之前我们必须要先弄清楚其中的关键性名词和概念 Organization – 组织 组织是指一系列AWS账户,您可以将其整理为一个层次结构并进行集中式管理 AWS account – 账户 AWS账户是您AWS资源的容器,例如: Amazon S3 存储桶、 Amazon EC2 实例等 通过AWS Identity and Access Management (IAM) 规则  (users, roles) 管理AWS资源 AWS […]

Read More

搭建DX Gateway,轻松互联全球架构

Direct Connect Gateway是什么,能做什么 您可以使用新的Direct Connect Gateway功能建立跨越多个AWS区域的虚拟私有云(VPC)的连接。 您不再需要为每个VPC建立多个BGP会话; 这可以减少您的管理工作量以及网络设备的负载。 此功能还允许您从任何直接连接位置连接到任何绑定的VPC,从而进一步降低跨区域使用AWS服务的成本。 为了使您可以有更直观的区别体验,我们可以通过下面的对比图来更好的体会一下 在没有DX Gateway之前: 需要互联VPC的话,每个VIF需要和对应VPC的VGW绑定。也就是说,有多少希望互联的VPC,就需要维护多少VIF到VGW的链路。并且如果需要互联的VPC是跨region的,那么就需要多条AWS DX链路。这就意味着更多的DX代理商,更多的沟通时间,更多的维护成本。 下图标注出了,有两个不同的region资源(us-west-1和us-east-1)的客户Account-0希望通过DX来给其下面的子账号Account-1和Account-2分别分配DX VIF,使其可以更快的访问放在us-west-1和us-east-1的VPC资源。这就需要用户分别在这两个region找DX partner开启DX服务,并且针对每个VPC创建一个VIF连接。 有DX Gateway之后: 每个DX Gateway都是跨所有公共AWS区域存在的全局对象。这就使得所有的AWS全球区域之间可以通过网关进行的所有通信,而这类全球通信是通过AWS网络骨干进行保障的。 和上述同样的需求,我们来看看有DX Partner的情况会怎么样。Account-0账户只需要在最近的region,比如us-west-1申请一个DX专线。再创建一个AWS Global全局的DX Gateway。分别分配给account-1和account-2账户一个VIF连接DX Gateway,再将希望访问的VPC直接和DX Gateway绑定就解决了。 总结一下DX Gateway的作用: 在只需要拉一条DX专线的情况下,可以通过DX Gateway和全球region的VPC进行互通。就是这么简单。下面就让我们来亲手搭建一个互通全球region的DX Gateway,享受AWS给我们带来的网络便捷 使用DX Gateway实现不同region内的VPC互通 0. 网络架构图 通过创建DX Gateway并绑定至VIF来做到多个region的VPC互通的步骤如下: 创建DX Gateway并同步到所有region 绑定VIF到DX Gateway 配置本地路由器和DX Gateway形成BGP邻居 将其他region的VPC绑定的VGW和DX Gateway进行绑定,并打开路由汇聚 测试本地路由器和各个region的VPC中的EC2的连通性 1. 实际创建DX Gateway 在日本region创建DX Gateway 日本区域出现DX Gateway 一段时间之后在其他region,比如Singapore也会出现DX […]

Read More

AWS DevOps – 配合Jenkins和CodeDeploy实现代码自动化部署

作为DevOps和微服务的深入践行者,Amazon在内部积累了许多持续集成、交付和部署的自动化工具和平台。本文主要介绍如何在AWS云上,使用CodeDeploy,并配合Jenkins来构建持续集成/持续交付的管道,自动化代码部署和版本迭代。 在查看本文之前,建议大家先阅读一下代闻老师写的关于CodeDeploy的文章。 https://aws.amazon.com/cn/blogs/china/getting-started-with-codedeploy/ 一、创建EC2实例并安装CodeDeploy Agent 创建Amazon EC2实例,选择实例类型和添加存储。 在“高级详细信息”里面输入启动脚本 #!/bin/bash yum -y update yum install -y ruby yum install -y aws-cli cd /home/ec2-user aws s3 cp s3://aws-codedeploy-cn-north-1/latest/install . –region cn-north-1 chmod +x ./install ./install auto EC2启动成功后,使用SSH到该EC2,使用如下命令检验Agent是否工作正常。 sudo service codedeploy-agent status Result: The AWS CodeDeploy agent is running as PID 3523 二、创建应用程序负载均衡(ALB) 创建Target Group 三、创建CodeDeploy环境 点击“创建应用程序” 输入应用程序名称,和部署组的名称。CodeDeoploy支持两种部署方式,“就地部署”和“蓝绿部署”,更多关于部署类型请参考: […]

Read More

新一代负载均衡器服务NLB概述

在去年9月份,AWS发布了托管的网络负载均衡器服务Network Load Balancer,NLB是继Classic Load Balancer,Application Load Balancer之后,AWS发布的第三款负载均衡器服务,本文将着重介绍NLB的工作原理,特点以及在使用配置上的注意事项,帮助读者更好地在自己的业务场景中运用NLB服务。 NLB能够在极低的延迟下,支持每秒数千万的请求,在API上兼容现有的ALB应用负载均衡器,下面是NLB的一些主要功能和特点: 静态IP地址 每个NLB在每个可用区中提供单个静态IP地址,用户端发往该IP地址的流量会被负载分发到同可用区内的多个后端实例上,用户可以为NLB在每个可用区中分配固定的弹性IP,如此设计使得NLB能够被纳入企业现有的防火墙安全策略中,并且能够避免DNS缓存带来的问题。 同可用区内分发流量 客户端的流量到达NLB在某个可用区提供的IP后,NLB会向相同可用区内的后端实例分发流量,通过避免跨可用区的流量分发能够获得更好的延迟性能。 源地址保留 NLB在转发流量的同时,并不会修改数据包的源IP地址,后端实例无需支持诸如X-Forward-For,proxy协议,就能够直接从数据包的包头获取客户端的IP,从而很方便地分析客户端的地理位置等信息。 长连接支持 NLB内置的容错机制能够保证长连接应用的稳定运行,从而更好的贴合诸如IoT,游戏,消息应用等业务场景。 故障切换 利用Route 53的健康检查,NLB支持在一个区域内及跨区域和本地站点实现故障切换。 下面我们来看一下如何在AWS控制台创建NLB,可以看到,客户在创建负载均衡器页面中,目前可以有三种负载均衡器可选,我们选择NLB。 NLB和其他AWS提供的负载均衡器一样,支持创建面向internet及internal两种场景,除此之外,用户需要配置NLB监听的端口及所处的子网,如果创建面向internet的NLB,需要注意将NLB放到公有子网中。 考虑NLB本身的冗余,建议至少选择2个可用区,同时用户可以根据需要为NLB在每个可用区绑定弹性IP。 后续的配置与ALB的配置十分类似,用户需要配置目标组,目标组监听的协议、端口以及健康检查等相关配置,目前无论ALB还是NLB都支持将EC2实例及某个IP作为目标,前者实现VPC内部的负载均衡,后者通过IP可以为本地站点的实例提供负载均衡。 这里选择实例类型的目标类型,之后需要选择注册的实例。 需要注意的是,为了能够接受外部客户端的访问以及健康检查流量,建议后端实例的安全组做如下设置,如果用户觉得健康检查源地址设置VPC CIDR过于宽泛的话,建议可以设置为NLB的私有IP,NLB的私有IP可以在ENI界面通过NLB名字搜索到相关NLB的ENI来获取。 除了安全组设置上的考虑,对于面向internet的NLB来说,后端实例收到的流量的源IP地址是处于公网的客户端IP,对于接收internet流量的这部分后端实例,建议放到公有子网中,即默认路由指向IGW,如果用户不希望后端实例能够被外界直接访问,可以在将后端实例放入公有子网的同时,选择不分配公网IP,从而保证外界只能通过NLB来访问到后端实例。 选择完后端实例后,就可以完成NLB的创建。 NLB对外提供的是一个域名,客户端通过访问该域名将流量发给NLB,用户可以通过设置DNS CNAME记录来方便客户端通过自定义的域名来访问用户的后端系统。 以上介绍了面向internet的NLB的配置方法,对于面向internal的NLB,用户可以做类似的配置,这里不做过多的介绍,只是如果NLB后端对接的是容器业务,并且网络模式是bridge模式,需要做额外的考虑。 这里先给出结论再解释相关的原理,对于两个需要通过NLB互访的内部容器应用,建议将这两个应用的容器调度到不同的EC2节点上,对于AWS ECS,用户可以通过为两个应用创建不同的ECS Cluster或者在一个ECS Cluster内通过亲和性调度算法实现。 为什么需要做上述的设置呢?下面解释下如果将这两个应用调度到相同的ECS Cluster上会出现什么问题。 在上面这个场景中,App1和App2使用容器部署在EC2中,App1需要通过NLB来访问App2,如果网络模式使用bridge,App1的流量在发出所在EC2实例的时候,源IP地址会从App1的容器IP转换成EC2的IP,如果NLB通过负载分发算法将流量发往处于相同EC2上的App2容器,NLB会将目的IP转换成相同的EC2的IP地址,流量到达EC2后,EC2会将目的IP转换成App2的容器IP,问题在于App2回包的时候,当流量到达EC2 OS层,OS通过查询路由表发现目的地址是自己,会在OS层面直接处理流量,而不会将流量返回给NLB,导致App1访问App2失败。 这个问题是由于NLB的工作原理导致的,NLB在接收到流量后,保持源IP地址不变,通过负载均衡算法选择后端实例,并将目的IP转换成后端实例的IP地址进行流量分发,我们需要在设计上避免上述问题,将App1和App2的容器调度到不同的EC2实例上,从而在根本上避免App1访问App2的流量的发起和终止在同一台EC2实例上。 以上我们的介绍了NLB的主要特点,配置方法及常见的配置注意事项,读者如果感兴趣的话,可以通过下面的链接来进一步学习NLB的相关内容: https://aws.amazon.com/documentation/elastic-load-balancing/ https://aws.amazon.com/elasticloadbalancing/faqs/ 作者介绍 余骏,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。  

Read More

AWS Lambda 配合 Jenkins 实现自动化持续部署

AWS Lambda是AWS无服务器框架中的重要组成部分,而开发、测试和部署Lambda函数需要经过一个较为枯燥的过程:在集成开发环境(IDE)中编写函数,然后将其打包,并上传到AWS使用控制台进行测试。事实上,您可以在本地进行编写测试,并将其上传到自己的代码库,然后使用CICD(Continuous Integration/Continuous Development)工具来进行集成部署。 本文中将介绍如何使用Jenkins在AWS上进行Lambda开发部署。更多有关AWS Lambda 介绍可参考链接https://amazonaws-china.com/lambda/ 架构图 通过git命令提交代码 通过部署在EC2中的Jenkins拉取Github上的代码 将代码部署到Lambda,完成代码部署 上传一张图片到S3 触发S3的ObjectCreate事件,调用Lambda生成缩略图 将生成的缩略图储存到指定位置 创建Lambda 从控制台进入Lambda,选择从头开始创作 输入Lambda名称 选择从模板创建新角色 点击创建函数 记录已创建Lambda函数的 ARN,位于Lambda函数右上角 修改处理程序为CreateThumbnail.handler 创建S3存储桶 从控制台进入S3创建存储桶,输入自定义桶名,这边需要创建两个存储桶,一个是源数据桶,另一个是目标数据桶 源存储桶 目标桶 进入源存储桶,并选中属性标签 选中高级设置中的事件,按照以下顺序依次操作并保存 添加通知 输入名称 配置事件类型,及Lambda函数 修改Lambda角色 在之前的Lambda函数创建的过程中,自动创建了一个Lambda角色,但是这个角色只有最基本的创建CloudWatch Logs的权限,还需要对创建的S3存储桶有相应的进行读写的权限。 首先获取S3存储桶ARN,选中存储桶,点击复制存储桶ARN 从控制台进入IAM,选中角色,找到在Lambda里创建的新角色,点击附加策略 在搜索栏中输入S3,选中AmazonS3FullAccess并附加(在此案例中) Jenkins 环境 – Java 8 下载并解压Java 8 wget http://download.oracle.com/otn-pub/java/jdk/8u151-b12/e758a0de34e24606bca991d704f6dcbf/jdk-8u151-linux-x64.tar.gz tar -zxvf jdk-8u151-linux-x64.tar.gz 创建Java目录,并将Java移动至此目录 sudo mkdir -p /usr/local/java/jdk1.8 sudo mv […]

Read More

成本优化利器——Amazon EC2 Spot实例详细介绍

1.  前言 AWS EC2实例类型从实例类型上可以划分成通用型,计算优化型,内存优化型,存储优化型,GPU加速计算等实例类型。从实例的购买模式来看,又可以分为按需实例、预留实例、专用实例、Spot实例等类型。今天我来给大家介绍一下Spot实例这样一个非常有特色的实例类型。本文将会着重介绍Spot实例的基本概念,新的定价模型和计费方法,如何启动Spot实例,以及Spot实例的中断处理,Stop和Resume,Hibernate。希望通过这篇文章,您可以对Spot实例有个全面的了解。 2.  什么是Spot实例(Spot Instance) Amazon EC2 Spot 实例,是 AWS服务中的可用空闲计算容量。与按需实例的价格相比,这类实例可提供超低折扣。EC2 Spot 可帮助您优化 AWS服务的成本,可在预算相同的情况下将应用程序的吞吐量提高到10倍。您只需在启动 EC2 实例时选择“Spot”,即可节省按需实例价格的 90%; 按需实例和 Spot 实例的唯一区别在于,当 EC2 需要更多容量时,它会发出两分钟的通知继而中断 Spot 实例。您可以将 EC2 Spot 用于各种容错且灵活的应用程序,如测试和开发环境、无状态 Web 服务器、图像渲染、视频转码,以运行分析、机器学习和高性能计算 (HPC) 工作负载。EC2 Spot 还可与其他 AWS 产品紧密集成,包括 EMR、Auto Scaling、Elastic Container Service (ECS)、CloudFormation等,让您可以灵活选择如何启动和维护 Spot 实例上运行的应用程序。 Spot实例是购买和使用 Amazon EC2 实例的新方式。Spot实例的现货价格根据供需情况定期变化。直接使用类似购买按需实例的方式启动Spot实例,价格将根据供需关系确定(不超过按需实例价格);用户也可以设置一个最高价,当设置的最高价高于当前现货价格的期间内运行此类实例。Spot实例是按需实例和预留实例的补充,为获得计算容量提供了另一种选择。以下是Spot实例的一些基本概念: Spot实例池 – 一组未使用的 EC2 实例,具有相同的实例类型、操作系统、可用区。 现货价格 – Spot […]

Read More

由 Code.org 主办的 Hour of Code 现在正在进行

Hour of Code 现在正在进行中。这项全球性活动让学生能够体会到计算机科学的力量,该活动在“计算机科学教育周”期间举行,今年的计算机科学教育周持续时间是 12 月 4 日到 10 日。 Code.org 是 Hour of Code 的主办组织,该组织通过在 180 多个国家/地区举行的超过 10 万次活动吸引了数千万学生。一个如此大规模的教育活动需要强大且安全的基础设施。AWS 使 Code.org 能够扩展其网站以满足需求并提供良好的用户体验。 “AWS 是 Code.org 明智的选择,”Code.org 首席技术官 Jeremy Stone 表示。“冗余和可扩展性是做出这一决定的关键因素。”活动期间使用的一些关键服务为 Amazon CloudFront、Amazon EC2 和 Elastic Load Balancing。 Amazon CloudFront 是全球内容分发服务,帮助学生在 Hour of Code 期间从本地服务器获取内容。根据 Stone 的说法,这为全球参与者带来了更流畅的体验。 Amazon EC2 为 Code.org 的前端 Web 服务器提供了可扩展的计算能力。Stone 表示,这避免了前期硬件投资,并且其可靠性让人高枕无忧。 […]

Read More

新功能- Collectd的Amazon CloudWatch插件

原文:https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/ 作者:Jeff Barr 我在2011年已介绍过Cloud Watch的特性,“您可以在Cloud Watch中查看图表、设置告警、并根据这些指标启动自动化操作,所使用的这些AWS资源指标会被存储于Cloud Watch中 。”您目前已有能力在Amazon Cloud Watch中存储一段时间范围内的业务、应用及系统的指标数据(参阅“Amazon Cloud Watch定制新指标”了解更多信息)。 今天我们将简化系统统计信息的采集过程,使用一个新的 CloudWatch plug for colletd将采集数据发送至CloudWatch中 。并通过collectd 多种类型信息的统计采集能力与cloudwatch存储、展示、警报和告警的功能的整合,您可以更好地获取EC2实例、本地硬件以及运行于其上应用程序的运行状态及其性能信息。该插件已经作为一个开源项目发布,我们期待您的反馈。 Collectd守护进程采用C语言编写,具有高性能和可移植性。它支持上百个插件 ,允许您收集有关Apache、Nginx Web服务器性能统计数据、memory usage 、 uptime等信息。 安装与配置 为了演示这些功能,我在EC2实例上安装并配置了Collectd服务及新Cloudwatch插件。 首先我创建了一条IAM策略,它具备将指标数据写入CloudWatch的权限: 然后我创建了一个IAM角色,允许EC2(运行collectd程序的实例)使用上述所建的策略: 如果我计划使用Collectd 插件从本地服务器或运行中的EC2实例收集统计信息,那请跳过这些步骤,采用创建一个具有适当权限的IAM用户作为替代方法。在我完成上述工作后,会将该用户的证书放在本地服务器或EC2实例中。 在策略和角色配置完毕后,选择该角色来启动一个EC2实例 登录并安装Collectd : $ sudo yum -y install collectd 然后获取插件和安装脚本,设置脚本为可执行,并运行该脚本: $ chmod a+x setup.py $ sudo ./setup.py 回答一些交互问题确认安装过程无误,在完成配置之后就可启动Collectd : Installing dependencies … OK Installing […]

Read More

使用AWS CodeDeploy和Auto Scaling组实现蓝绿部署

原文: https://aws.amazon.com/blogs/devops/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/ 作者:Jeff Levine,Amazon Web Services解决方案架构师 AWS提供的服务能够帮助大家利用云的力量来满足开发和部署的需求。AWS CodeDeploy可自动将代码部署到Amazon EC2或本地实例,并支持蓝绿部署方式。在这篇博文中,将讨论蓝绿部署的好处,并展示如何实现。 蓝绿部署的好处 蓝绿部署涉及两个生产环境: 蓝色环境指代正在使用的生产环境。 绿色环境则将发布一个新版本。 以下是蓝绿部署的一些优点: 可在绿色环境下进行测试,而不会中断蓝色环境。 切换到绿色环境不需要停机,只需要重定向用户流量。 问题发生时,可很方便地从绿色环境回滚到蓝色环境,只要将流量重定向回蓝色环境即可,而无需重新构建。 需要变更时,利用不可变基础设施原则初始化新的实例,避免实例配置产生不一致性。 AWS CodeDeploy提供了两种蓝绿部署的方式: 第一种,AWS CodeDeploy为Auto Scaling组创建了副本,启用新的Amazon EC2实例,将应用程序部署到这些新实例,然后重定向用户流量重定到新部署的代码。 第二种,可使用实例标签或Auto Scaling组来选择用于绿色环境的实例。AWS CodeDeploy会将代码部署到标记的实例上。 那么,如何设置你的第一个蓝色环境?最佳做法,当然是采用AWS CodeDeploy的in-place部署方式。当然也可以从已有的空白Auto Scaling组开始。 蓝绿部署的示例 我们来看一下如何使用Auto Scaling组来实现蓝绿部署。 概述 下图中,示例环境包括一组Amazon EC2实例,可作为AWS CodeDeploy的工作站。服务发布管理员或开发人员可以使用此工作站部署新版本的代码。蓝色环境包含一个Auto Scaling组,其中另有两个实例用作Web服务器。 Web服务器,最初将包含应用程序的第一个版本和AWS CodeDeploy客户端。负载均衡器以轮转的方式,将流量引导到两个Web服务器。 服务发布管理员使用工作站实例,将新版本的应用程序推送到AWS CodeDeploy,并启动蓝绿部署。 AWS CodeDeploy会创建Auto Scaling组的副本,启动两个新的Web服务器实例,并安装新版本的应用程序,然后将负载均衡器重定向到新实例。 原实例仍然是原Auto Scaling组的一部分。 如果需要,均可重新关联到负载均衡器中。 构建该示例的先决条件 以下是需要的准备工作。 具有使用Amazon EC2,Amazon S3,Amazon VPC,AWS CodeDeploy和AWS CloudFormation权限的IAM用户。 选定构建示例环境的AWS区域和可用区域。 Amazon EC2密钥对。 […]

Read More

使用 Amazon EC2 Run Command 在不使用 SSH 访问的情况下大规模地管理实例

以下博文的投稿者为 Ananth Vaidyanathan (EC2 Systems Manager 高级产品经理) 和 Rich Urmston (Pegasystems 公司云架构高级总监),介绍了如何使用 EC2 Run Command 在不使用 SSH 的情况下管理大量 EC2 实例。 -Jeff 企业通常具有若干托管环境和成千上万的 Amazon EC2 实例。安全地管理系统非常重要,同时也要避免棘手的安全外壳 (SSH)。Run Command 是 Amazon EC2 Systems Manager 的一部分,可以让您以可控制和可审查的方式对实例 (或使用标签的实例组) 运行远程命令。这有效地提升了每天都要依赖 Run Command 服务的 Pega 云操作的效率。 您可以通过标准 IAM 角色和策略控制 Run Command 访问,定义文档以获取输入参数,控制用于返回命令输出的 S3 存储桶。您还可以与其他 AWS 账户共享文档或将文档公开。总而言之,Run Command 提供了一组很有用的远程管理功能。 优于 SSH Run […]

Read More