Author: AWS Team


使用Amazon EC2 Systems Manager取代堡垒机

通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。

本文将向您介绍使用Amazon EC2 Systems Manager替换您的堡垒机,实现在服务器上运行命令的同时缩小系统攻击平面并获取更好的可见性。

堡垒机方案

堡垒机最好仅向特定的IP地址范围开放,这个地址范围通常可设定为您单位的企业网络。使用堡垒机的好处是,任何对内部服务器的访问都被限定到一种方式:通过单个或一组堡垒机。为了获取进一步的隔离,堡垒机通常被安放在单独的VPC中。

这种设计方案如下图所示:

应用服务器运行在与管理VPC对等相连的一个VPC的私有子网中。 应用服务器设定了一个安全组规则,其仅允许来自管理VPC中堡垒机所在安全组的22端口访问(本文的示例仅针对端口22和SSH访问。Windows用户可将其相应的替换为端口3389和RDP访问)。同样,堡垒机也设定了一个安全组规则,其仅允许来自公司网络IP地址空间的22端口访问。

由于应用服务器运行在私有子网中,所以它只能通过VPC公共子网中的NAT网关来建立出站公网连接。

假设您希望查看应用程序服务器的网络接口,您需要执行以下步骤:

  1. 将应用服务器的私钥安装在堡垒机上。
  2. 从可信网络(如公司网络)发起,在堡垒机上建立SSH会话。
  3. 从堡垒机发起,建立SSH会话到应用服务器。
  4. 运行“ifconfig”命令。
  5. 如需保存命令的结果,您可以复制和粘贴命令的输出,或者将输出重定向到文件。

这个方案中的安全措施限制了对应用服务器和堡垒机的访问,但堡垒机模式存在一些缺点:

  • 像任何基础设施服务器一样,堡垒机必须进行管理和维护。
  • 运行时会产生成本。
  • 允许堡垒机访问的每个安全组都需要设置一个安全组入口规则,即SSH(用于Linux)的22端口或RDP的3389端口(用于Windows服务器)。
  • 堡垒机和应用服务器的RSA密钥需要进行管理、保护和轮换。
  • SSH操作无缺省日志记录。

替代方案

Systems Manager允许您在被管理的服务器上远程执行命令,而不使用堡垒机(此功能称为EC2 Run Command)。安装于服务器上的代理程序会自动轮询Systems Manager以确定是否有命令在等待执行。

此方案具备以下优点:

  • 使用AWS托管服务,这意味着Systems Manager组件具备高可用性。
  • Systems Manager通过IAM策略设定是否允许用户或角色远程执行命令。
  • Systems Manager代理程序需要IAM角色和策略才能允许它们调用Systems Manager服务。
  • Systems Manager不可更改的记录每个执行的命令,从而提供了可审计的命令历史,包括:

 o   执行命令的内容

 o   执行命令的主体

 o   执行命令的时间

 o   命令的输出摘要

  • 当AWS CloudTrail在当前区域中启用时,CloudTrail会记录每个事件,并写入Amazon CloudWatch Logs。
  • 使用CloudTrail和CloudWatch规则,您可以将Systems Manager事件用作自动响应的触发器,例如Amazon SNS通知或AWS Lambda函数调用。
  • Systems Manager可以选择将命令历史记录和每个命令的全部输出存储在Amazon S3中。
  • Systems Manager可以选择发布消息到SNS主题,从而在命令开始执行时和完成时通知订阅者。
  • Systems Manager是基于代理程序的,这意味着它不限于管理Amazon EC2实例。它还可以管理运行在自有数据中心或者另一个云服务提供商的非AWS服务器上。
  • 无需管理SSH密钥。

Systems Manager本身没有成本,但是您需要支付Systems Manager所管理的资源(如EC2实例、SNS消息和S3存储等)的成本。

Systems Manager代理程序

Systems Manager代理是运行在被管理的服务器上的开源可执行程序,支持Linux和Windows操作系统(请参见支持的详细操作系统版本列表)。

Systems Manager代理通过IAM角色与Systems Manager进行通信。这个角色必须具有足够权限与Systems Manager及其辅助服务进行交互。IAM已经提供了一个名为AmazonEC2RoleforSSM的托管策略,为您预先定义了这些权限:允许代理程序获取并回复Systems Manager消息、发布CloudWatch指标、并将日志文件写入S3。

Systems Manager代理通过HTTPS协议与Systems Manager通信,这意味着服务器和Systems Manager服务之间的通信是被加密的,而且安全组也不需要特殊的出口规则。

理想情况下,您可以在实例引导时安装代理程序。您可以将其安装在已经运行的EC2实例或非AWS的服务器上。例如,您可以通过EC2实例的user data在系统引导时使用yum安装Systems Manager代理:

#!/bin/bash
cd /tmp
curl https://amazon-ssm-region.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm -o amazon-ssm-agent.rpm
yum install -y amazon-ssm-agent.rpm

关于安装Systems Manager代理的更多信息,请参考以下链接:Installing SSM Agent.

优化后的系统架构

现在您已了解了Systems Manager的众多优点,下面我们看一下如何据此优化您的系统架构。

如下图所示,Systems Manager消除了系统对堡垒机的需求,从而简化了系统架构。 用户不再直接与应用服务器进行交互,Systems Manager成为了执行命令的代理。

在此设计中,Systems Manager代理程序驻留在应用服务器上,使其成为 “受管实例”——这意味着它可以从Systems Manager接收命令。 要执行一个命令,只需在Systems Manager中创建一个命令请求,并派发到该实例或一组实例上运行。

创建命令请求时,您可以选择一个用于存储命令执行结果的S3存储桶,和用于发送执行通知的SNS主题。 您还可以创建通过Systems Manager事件触发的CloudWatch事件。

操作演示

您可以使用下面的【Launch Stack】链接来启动一个AWS CloudFormation栈,后者将创建上述架构,然后运行命令并在Systems Manager控制台中查看结果。最后,您可以销毁整个CloudFormation栈。

注:该链接会在北弗吉尼亚州区域启动相关资源,并产生相应的成本。SSM 只在如下区域可应用。

1.选择Launch Stack打开CloudFormation控制台(请确保您已经使用您的AWS账户登录)并启动CloudFormation模板。选择Next。

2.对于Stack name,请使用缺省的ssm-demo或输入自定义名称。 对于通知电子邮件,请输入您的电子邮件地址,以在Systems Manager执行操作时通知您。CloudFormation模板启动后,您将收到一个订阅确认邮件,您必须确认才能收到后续的通知。选择Next 。

3.在Review 屏幕上,确认允许CloudFormation创建IAM角色。选择Create

4.要查看栈的创建进度,请选择Refresh,然后选择ssm-demo栈以查看启动过程。

5.当栈成功启动时,状态会从CREATE_IN_PROGRESS更改为CREATE_COMPLETE 。 要查看本文后面需要使用的输出值,请选择Outputs.

这个CloudFormation模板创建的资源将在本文的后面中使用。您应该看到下表中列出的值。

Output名称 示例值 用途
S3Bucket S3Bucket ssm-output-history -account-id – 区域 S3桶用于存储命令的输出
ApplicationHostInstance id-instance-id 用于执行命令的EC2实例
SnsTopicArn arn:aws:sns: region : account-id :SsmNotificationTopic 用于发送命令执行通知的SNS主题
RoleArn arn:aws:iam :: account-id :role / SsmNotificationRole- region 用于向SNS发送通知的角色

Systems Manager演示

在本节中,您将使用Systems Manager发出与上文堡垒机方案中相同的“ifconfig”命令来查看应用服务器的网络接口配置。

首先,您需要指定要在其上执行命令的实例。在Systems Manager执行命令之后,它会报告执行状态,显示输出,并将输出的历史存储在S3桶中,并向您发送一封电子邮件通知。

Systems Manager代理以root权限运行,管理员在授予用户执行Systems Manager命令的权限时应注意这一点。

要使用Systems Manager,请按照下列步骤操作:

1.登录到您的AWS帐户并跳转到EC2控制台

2.在左侧导航窗格的SYSTEMS MANAGER 下 ,选择Managed Instances

注意:如果您看到“欢迎使用EC2系统管理器 ”的界面,而非受管实例列表,请确保您的系统已满足以下条件:

  • 您正在查看的EC2控制台与您启动CloudFormation模板的区域相同
  • 至少有一个实例正在运行Systems Manager代理
  • 运行Systems Manager代理的实例具有关联的实例角色,并具有允许Systems Manager操作的策略
  • 实例已完成初始化(通常只有几分钟)

3.选择本文前面CloudFormation模板创建的实例,然后选择 Run a command.4.在Run a command屏幕上,向下滚动命令文档列表并选择AWS-RunShellScript,平台类型是Linux。如果您使用Windows服务器,请选择AWS-RunPowerShellScript。本文不会涉及命令文档列表中的其他命令,但您可以在工作中根据实际用途选择使用其他命令文档。
5.确保选择了前文CloudFormation模板创建的EC2实例。
6.在Commands输入框中输入以下命令:

ifconfig

这会发出一个命令来查看主机的网络接口配置。 您可以在这里输入任何有效的bash命令(对于Linux),例如:安装补丁程序,执行应用程序,或更新配置文件等。

7.输入以下值,然后选择Run

  • 对于S3存储桶,请输入上文CloudFormation模板创建的存储桶名称(将S3前缀值留空)。
  • 对于角色ARN,输入从CloudFormation模板创建的ARN。
  • 对于SNS主题ARN,输入从CloudFormation模板创建的ARN。
  • 对于Notify me on,选择全部。
  • 对于Notify me for,选择命令。
  • 所有其他字段采用默认值。

8.在你启动这个要求之后, 选择 View Managed Instances.

9.如需查看命令历史,在 SYSTEMS MANAGER SERVICES,选择 Run Command.

10.要在Systems Manager控制台上查看命令的简要输出,请选择 Output, 然后再选择View Output.

对于较长的输出,您可以在先前指定的S3存储桶中查看完整的命令输出。此外,您应该在几分钟内收到一封电子邮件,通知您Systems Manager的命令已执行完成。

注意:如果您没有收到电子邮件通知,请确保您在启动CloudFormation栈时收到的SNS主题确认邮件中,点击链接确认接收SNS通知。

截至目前,您已经在应用服务器上成功执行了一个命令,而没有使用堡垒机或直接访问服务器。您可以审核命令的执行,并使用现有的IAM框架来控制对服务器的访问,而无需管理专用的RSA密钥。有关使用IAM框架控制Systems Manager的权限的详细信息,请参阅Configuring Access to Systems Manager

要清理CloudFormation模板创建的资源,请确保删除CloudFormation栈。如果您使用Systems Manager时将执行日志存储在存储桶中,您在删除栈之前必须手动删除存储桶及其内容。

下一步

大多数AWS服务都包含强大的API让您实现服务交互的自动化。使用控制台是学习和理解远程命令执行过程的好方法,但自动化这一能力提供了一种可靠和规范的方式来管理用户对此功能的使用。

例如,许多组织都依靠人员的轮值来支持生产环境。由于Systems Manager支持IAM集成,您可以根据人员上岗的特定时间段来自动授予或撤消Systems Manager调用权限。

在上文的示例中,您在控制台中执行了一个随意的命令。实际工作中,您将执行存储在具备访问控制的源代码库中的脚本,并可将此功能集成到现有的运维工作流程中,实现请求的跟踪、审批或拒绝。另外,使用AWS CLI、AWS API和AWS SDK,您还可以实现Systems Manager的全程自动化。

更多Systems Manager的特性

远程命令执行只是Systems Manager的一个功能。 其他功能包括:自动补丁管理,服务器软件清单,AMI自动化和参数库等。更多详细信息,请参阅Amazon EC2 Systems Manager产品详细信息页面。

总结

本文介绍了如何在EC2实例上远程执行命令,同时减少系统的攻击平面并简化系统的架构。您还可以使用AWS的IAM、日志和警报等服务帮助您获取服务器上所执行命令的详细信息。

您可能会遇到此解决方案无法满足的SSH或RDP的用例,例如SSH隧道或依赖于SSH的专有软件。希望这篇文章为您提供了关于如何访问和管理服务器的新思路。

 

译者介绍

寇欣,亚马逊AWS中国区专业服务部咨询顾问,加入AWS之前,在IT和云计算行业积累了丰富的云服务架构和应用软件架构的经验。历任Oracle电信事业部专业服务部门资深顾问、中国移动研究院云计算研究员、Lucent Tech研发中心系统架构师。

基于Amazon EC2 Container Service构建安全高可用的Docker私有库

1. 背景

Docker hub作为docker官方镜像仓库,提供了大量Docker镜像的托管服务。但使用它来托管企业私有Docker镜像存在一些问题,比如:

(1)Docker hub托管私有镜像的服务目前只面对收费账户;

(2)使用Docker hub托管私有镜像并不适合一些特殊场景,比如工作环境网络是内网,不允许访问外网,那就更不可能到Docker hub去下载镜像。

在这种情况下,如果能构建一个安全可靠的Docker私有库,将会是一个更好的选择。本文将介绍在Amazon EC2 Container Service基础上结合AWS Elastic LoadBalancer、AWS Autoscaling Group、AWS S3及Docker官方提供的registry镜像构建安全、高可用的Docker私有库的方案,帮助您轻构实现这一需求。

2. 方案详解

我们会使用AWS CloudFormation服务,使用自定义的模板脚本声明所需的资源,实现自动化构建。接下来结合我们的模板脚本对本方案进行详细介绍。

注意:以下内容与代码相关部分只贴出主要代码,部分代码用…表示省略;红字部分请替换成您自己账号相关的信息。

完整模板代码地址:https://s3-us-west-2.amazonaws.com/blog.leonli.org/registry.yml

         或者点击按钮直接在控制台中运行:

2.1 架构图

根据以上架构图,基本数据传输过程为:

(1)Docker客户端向镜像仓库发送的pull/push等命令事实上都是通过docker daemon转换成restful请求的形式再发送给镜像仓库的。在本架构中,我们利用AWS Elastic LoadBalancer(简称ELB)接收客户端发来的请求,作为整个架构的接入层。由于我们要求数据是通过TLS加密传输的,所以我们需要使用AWS IAM中的server certificate(由AWS IAM账户上传的TLS证书)与ELB关联,实现对客户端发来的请求进行加密。

(2)ELB会将请求反向代理给后端分布在不同可用区的两台Container Instance(安装了Docker运行环境的EC2实例),Container Instance中运行了Docker registry服务。当请求到达registry时,我们需要首先使用内置在registry中的用户认证文件(比如本架构中使用apache htpasswd创建的基本用户名密码保护文件),进行用户认证,认证不通过,则驳回请求,认证通过,才可以读写数据。

(3)我们将数据统一存储在一个只供创建者使用的S3 Bucket中。

2.2 基于AWS ECS运行Docker Registry服务

Amazon EC2 Container Service (ECS) 是一项高度可扩展的高性能容器管理服务,它让您能够在托管的 Amazon EC2 实例群集上轻松运行Docker应用程序。 Amazon ECS主要有以下几个组件:ECS Cluster、 Container Instance、Task , ECS Service。这里我们基于ECS运行了Docker registry服务,架构如下:

(1)首先我们在模板中定义了一个ECS Cluster,用来管理相关的Container Instance。ECS提供了ECS-Optimize AMI来创建EC2实例作为Container Instance,ECS-Optimize AMI已经内置Docker运行环境和Container Agent代理,可以为我们节省安装这些环境所需的时间。Container Instance在启动时可以由Container Agent根据配置文件/etc/ecs/ecs.config中的ClusterName属性的值知道需要将实例注册到哪个ECS Cluster上。

因为我们要使用Auto Scaling服务实现对EC2实例的伸缩控制。所以我们使用Auto Scaling的Launch Config组件声明我们的Container Instance。并通过UserData传入Shell脚本,此脚本主要完成以下三件事:

– 调用 echo ECS_CLUSTER=${ECSCluster} >> /etc/ecs/ecs.config ,将Container Instance注册到我们的ECS Cluster中。

– 创建/docker-registry/certs目录和/docker-registry/auth目录,并调用aws s3 copy命令从指定的S3 Bucket中复制TLS证书文件和htpasswd用户认证文件。这些文件将在运行Docker Registry时使用到。

– 调用cfn-signal命令,通知AutoScaling Group资源EC2实例已经启动完毕。

Container Instance相关的主要模板代码如下:

(2)然后我们定义了一个TaskDefinition来声明我们要运行的容器及其相关配置。这里我们运行的是Docker registry镜像的容器,它是官方提供的用于构建镜像仓库服务的镜像文件。

ContainerInstances:

    Type: AWS::AutoScaling::LaunchConfiguration

Properties:

      …

      UserData:

Fn::Base64: !Sub |

          #!/bin/bash -xe

          echo ECS_CLUSTER=${ECSCluster} >> /etc/ecs/ecs.config

  yum install -y aws-cfn-bootstrap

          yum install -y aws-cli

          sudo rm -rf /docker-registry

          sudo mkdir -p /docker-registry/certs

          sudo chmod 777 /docker-registry/certs

          sudo mkdir -p /docker-registry/auth

          sudo chmod 777 /docker-registry/auth

          aws s3 cp s3://${SSLCertificateFileBucket}/${SSLCertificateFileName} /docker-registry/certs/domain.crt

          aws s3 cp s3://${SSLCertificateFileBucket}/${SSLKeyFileName} /docker-registry/certs/domain.key

          aws s3 cp s3://${SSLCertificateFileBucket}/${HtpasswdFileName} /docker-registry/auth/htpasswd

          /opt/aws/bin/cfn-signal -e $? –stack ${AWS::StackId} –resource ECSAutoScalingGroup –region ${AWS::Region}

– 配置环境变量REGISTRY_AUTH、REGISTRY_AUTH_HTPASSWD_REALM、REGISTRY_AUTH_HTPASSWD_PATH指定宿主机目录/auth/htpasswd文件作为Basic Authentication基础用户认证文件,从而实现用户授权认证。

    – 配置环境变量REGISTRY_HTTP_TLS_CERTIFICATE、REGISTRY_HTTP_TLS_KEY指定宿主机目录/certs/中存放的domain.crt作为TLS证书文件,domain.key作为TLS秘钥,从而实现TLS传输加密。

    – 通过配置环境变量REGISTRY_STORAGE指定registry的存储驱动为AWS S3,配置REGISTRY_STORAGE_S3_REGION为存储的S3所在Region,配置REGISTRY_STORAGE_S3_BUCKET为存储的Bucket。从而实现将镜像文件存储到AWS S3指定的Bucket中。

关于构建私有库的更多细节和更多配置可以通过Docker官方文档进行了解:Deploy a registry server

TaskDefinition相关的主要模板代码如下:

RegistryTaskDefinition:

    Type: AWS::ECS::TaskDefinition

Properties:

      NetworkMode: bridge

      ContainerDefinitions:

       – Name: RegistryContainer

          Image: registry:2

          …

PortMappings:

            – ContainerPort: 443

              HostPort: 443

          Environment:

            – Name: REGISTRY_AUTH

              Value: htpasswd

            – Name: REGISTRY_AUTH_HTPASSWD_REALM

              Value: “Registry Realm”

           – Name: REGISTRY_AUTH_HTPASSWD_PATH

             Value: /auth/htpasswd

            – Name: REGISTRY_HTTP_TLS_CERTIFICATE

              Value: /certs/domain.crt

            – Name: REGISTRY_HTTP_TLS_KEY

              Value: /certs/domain.key

            – Name: REGISTRY_HTTP_ADDR

              Value: 0.0.0.0:443

             – Name: REGISTRY_STORAGE

              Value: s3

            – Name: REGISTRY_STORAGE_S3_REGION

              Value: !Ref AWS::Region

            – Name: REGISTRY_STORAGE_S3_BUCKET

              Value: !GetAtt StorageBucket.DomainName

          …

(3)最后我们定义了一个ECS Service,指定TaskDefinition、Cluster和所需运行的任务个数DesiredCount。这样,我们就构建了一个运行着docker registry镜像的ECS服务了。

2.2 如何实现高可用性

(1) 跨可用区部署服务

– 首先,我们在模板中声明了一个VPC和两个私有子网PrivateSubnet1和PrivateSubnet2,这两个子网是分别部署在不同可用区的。

– 其次,我们的ECS服务是通过Elastic Load Balancing(ELB)来平衡多个容器的负载,ELB是高可用且自动伸缩的。我们在模板中定义了一个命名为RegistryELB的ELB组件,指定它是internet-facing模式可供外网访问、并且是跨可用区的。ELB接收外网的请求,并且将请求代理给Container Instance中的容器。

– 最后,我们在模板中声明了一个Auto Scaling Group,指定VPCZoneIdentifier为跨可用区的两个子网PublicSubnet1和PublicSubnet2,由RegistryELB代理请求,从而实现跨可用区部署服务。

(2) 利用Auto Scaling保障可用实例数量

当服务遇到一些突发或者预期的高流量时,或者您的服务出现某些异常时,可以利用Auto Scaling服务保障可用实例数量。比如某台Container Instance宕机了,那么可以利用Auto Scaling自动启动相同配置的另一台Container Instance代理宕机的实例继续提供服务。

大部分情况下,企业Docker私有库承受的流量负载不会太大,所以本方案不介绍Auto Scaling的扩展策略,当然您也可以根据自己的业务需要修改模板代码,实现此功能。本方案使用Auto Scaling主要是为了保障可用实例数量一直维持在DesiredCapacity,这个参数是我们通过模板的参数传入的。

Auto Scaling Group相关的主要模板代码如下:

ECSAutoScalingGroup:

    Type: AWS::AutoScaling::AutoScalingGroup

    Properties:

    …

LaunchConfigurationName: !Ref ‘ContainerInstances’

      MinSize: !Ref MinSize

      MaxSize: !Ref MaxSize

     DesiredCapacity: !Ref DesiredCapacity

    …

(3) 利用s3确保数据完整性

Amazon Simple Storage Service (Amazon S3) 是AWS提供的对象存储服务,它可用于在 Web 上的任何位置存储和检索任意数量的数据,能够提供 99.999999999% 的持久性,使用S3来存储Docker私有库的镜像文件,可以确保数据完整。Docker registry镜像支持使用S3作为存储驱动,只需传入存储所在Bucket和所在Region即可。我们在模板中声明了一个Bucket用来存储镜像数据。并且这个Bucket只能由创建者进行控制。

2.3 如何实现安全性

(1) 利用TLS加密传输

Docker官方建议与私有库通信的所有数据传输皆使用TLS加密,我们通过上传IAM server certificate证书并将其与ELB关联,ELB的Listener使用SSL安全监听443端口,并将请求代理给实例的443端口,实例上也需要安装TLS证书。从而实现全链路的安全传输。

(2)利用apache htpasswd实现基本用户认证

如果我们创建的私有库没有用户认证机制,那么无论是谁只要知道私有库链接,就可以肆无忌惮地访问和操作我们托管在私有库的文件,这显然不是我们想要看到的。所以需要实现用户认证,只有通过认证的用户,才有权进行相关操作。

这里,我们使用apache htpasswd实现基本用户认证。这也是Docker registry镜像默认支持的认证方式。

3. 构建过程

3.1 准备工作

(1) 域名

您必须拥有一个用来指向registry的域名,这样您才可以通过域名访问您的私有库。

(2)TLS证书

yourcertificate.crt intermediate-certificates.pem > yourcertificate.crt

Docker官方建议私有库数据传输基于TLS,这样您还需要为您的域名申请CA认证,得到TLS证书和秘钥文件。有以下两种方式:

向CA供应商购买。

利用Let’s Encrypt生成免费的证书,具体操作参考letsencrypt官网。

另外,如果您的证书供应商还提供给你intermedia证书,那么您需要将它与你的证书进行合并,运行如下命令可以进行合并

aws iam upload-server-certificate —server-certificate-name YourCertName —certificate-body file:///path/to/certificate.pem —certificate-chain file:///path/to/chained.pem —private-key file:///path/to/private_key.pem

(3)上传IAM Server Certificate

{

    “ServerCertificateMetadata”: {

        “Path”: “/”,

        “ServerCertificateName”: “MyRegistryCert”,

        “ServerCertificateId”: “ASCAJHAWE3QRHEHH3L6KM”,

         “Arn”: “arn:aws:iam::xxxxxxxxx:server-certificate/YourCertName”,

“UploadDate”: “2017-07-01T16:16:45.125Z”,

        “Expiration”: “2017-09-26T12:15:00Z”

     }

}

 

openssl x509 -inform DER -in Certificate.der -outform PEM -out Certificate.pem

当Docker客户端向我们的ELB发送请求时,出于安全考虑,需要对传输加密,这时可以利用IAM Server Certificate,将我们的TLS证书、秘钥以及证书链文件上传,IAM会帮我们自动生成一个Server Certificate,再将它与ELB绑定即可。

可以使用AWS CLI按照以下命令上传:

openssl rsa -in PrivateKey.pem -out PrivateKey.pem

上传完成后,您会得到类似以下响应信息,将红字部分ARN记录下来,后面构建时需要它作为参数传入模板中。

注意:

– TLS证书、秘钥及证书链必须都是PEM格式,如果不是,可以使用以下命令进行转换:

– AWS IAM 要求证书秘钥是不加密的,所以当您的秘钥是加密时,需要使用以下命令转换

– 如果您在上传Server Certificate过程中遇到问题,可参考AWS官网指南:

Working with Server Certificate

(4)htpasswd用户认证文件

使用apache htpasswd来做基本认证,首先需要安装httpd,安装完后运行以下命令可以生成一个包含 一条用户名和密码记录的htpasswd文件

htpasswd -c username password > htpasswdfile

后面如果需要加入更多条记录,只需将 -c 参数去除,运行上面相同的命令即可。

(5) 将证书、秘钥和认证文件上传到S3

我们需要将前面几步生成好的TLS证书、秘钥、htpasswd文件上传到S3中,Container Instance启动后会从S3中将这些文件拷贝下来,通过映射到容器中供registry容器使用。

创建一个S3 Bucket, 将这几个相关文件上传。

3.2 自动化构建

接下来,我们在AWS Management Console中使用CloudFormation指定我们的模板文件创建一个Stack。如何使用CloudFormation创建Stack,请参考AWS CloudFormation用户指南:CloudFormation入门

Stack构建成功后,在输出栏会有输出值 RegistryELBDns,它是我们创建的ELB的DNS域名。我们需要将我们之前TLS证书签发的域名DNS解析(CName解析)转发到这个ELB的DNS域名。这样就可以使用我们自己的域名访问我们的私有库了。

3.3 开始使用

构建完Docker私有库后,现在可以开始使用了。

首先,在Docker客户端,我们可以从Docker Hub上拉取一个ubuntu镜像。

docker pull ubuntu:16.04

然后tag这个镜像到我们自己的域名下

docker tag ubuntu:16.04 myregistrydomain.com/my-ubuntu

登录我们的私有库

docker login myregistrydomain.com

输入用户名,密码后,调用push命令将镜像上传

docker push myregistrydomain.com/my-ubuntu

上传完后,可以调用pull命令拉取镜像

docker pull myregistrydomain.com/my-ubuntu

4. 总结

本文介绍了如何利用AWS ECS及其他AWS服务构建一个高可用、安全可靠的docker私有库,通过本方案的详细介绍和构建实践,相信您对于docker registry以及AWS Elastic LoadBalancer、AWS Autoscaling Group、AWS S3及AWS CloudFormation有了更进一步的认识。接下来,您可以利用AWS ECS容器管理服务及Docker容器技术,更加轻松地构建和管理您的应用程序,发挥更大的效益。

作者介绍

李磊,AWS解决方案架构师,负责基于AWS的云计算方案的架构设计,同时致力于AWS云服务在国内和全球的应用和推广。在大规模并发后台架构,电商系统,社交网络平台、互联网领域应用,DevOps以及Serverless无服务器架构等领域有着广泛的设计与实践经验。在加入AWS之前超过十年的开发和架构设计经验, 带领团队攻克各种技术挑战,总是希望站在技术的最前沿。

新增 – EC2 Auto Scaling 的目标跟踪策略

最近我介绍过 DynamoDB Auto Scaling,并演示了它如何使用多个 CloudWatch 警报来实现 DynamoDB 表的自动容量管理。此功能在后台使用了一种更为通用的 Application Auto Scaling 模型,我们计划以后逐渐在多项不同 AWS 服务中投入使用该模型。

这一新的 Auto Scaling 模型包括一项重要的新功能,我们称之为目标跟踪。在创建使用目标跟踪的 Auto Scaling 策略时,需要为特定 CloudWatch 指标选择一个目标值。然后,Auto Scaling 旋转相应的旋钮 (打个比方) 推动指标趋向于目标,同时调整相关的 CloudWatch 警报。比起使用初始步进扩展策略类型来手动设置范围和阈值而言,采用对应用程序有意义的任何指标驱动的单元来指定期望的目标,通常来说要更简单,也更为直接。不过,您可以结合使用目标跟踪和步进扩展来实现高级扩展策略。例如,您可以使用目标跟踪实现扩展操作,使用步进扩展实现缩减操作。

现在面向 EC2

现在我们为 EC2 Auto Scaling 增加了目标跟踪支持。您现在可以创建应用程序负载均衡器请求计数、CPU 负载、网络流量或自定义指标 (Request Count per Target 是新指标,也是在今天发布) 驱动的扩展策略:

这些指标都具有同一个重要的特性:添加额外的 EC2 实例会推动指标下降 (但不会改变总体负载),反之亦然。

要创建使用目标跟踪的 Auto Scaling 组,只需输入策略名称、选择一个指标,然后设置所需的目标值:

您可以选择禁用策略的缩减功能。如果禁用,您可以手动缩减,也可以使用独立的策略。您可以使用 AWS Management ConsoleAWS Command Line Interface (CLI),或 AWS SDKs 来创建目标跟踪策略。如果要使用目标跟踪,请注意以下事项:

  • 只要每个目标引用不同的指标,您可以在单个 Auto Scaling 组中跟踪多个目标。扩展始终选择能推动实现最高容量的策略。
  • 如果指标数据不足,则不会扩展。
  • Auto Scaling 会补偿指标快速、瞬时的波动,尽力将相应的容量波动减到最小。
  • 您可以通过 Auto Scaling APIAWS Command Line Interface (CLI)为自定义指标设置目标跟踪。
  • 大多数情况下,您应该选择根据基于 1 分钟频率 (也称为详细监控) 发布的指标进行扩展。根据基于 5 分钟的指标进行扩展,将导致响应时间变慢。

现已推出

这项新功能现已推出,您可以立即开始使用,无需额外费用。要了解更多信息,请阅读《Auto Scaling 用户指南》中的目标跟踪扩展

-Jeff

AWS 深度学习之旅

如果您和我一样,就会对人工智能 (AI)、机器学习 (ML) 和深度学习这些主题有极大兴趣和深感兴奋。AI、ML 和深度学习的应用越来越广泛,对我来说,这意味着艾萨克·阿西莫夫博士的科幻小说、《星球大战》中机器和医疗的进步,以及让柯克船长和他的《星际迷航》舰员能够“前往没有人去过的地方”的那些技术都可成为现实。

大多数对前述主题感兴趣的人都熟悉深度学习支持的 AI 和 ML 解决方案,如实现图像和视频分类的卷积神经网络、语音识别、自然语言接口和推荐引擎。但是,设置基础设施、环境和工具,让数据科学家、机器学习实践者、研究科学家和深度学习爱好者/拥护者能够深入钻研这些技术并不总是那么容易。大多数开发人员都渴望能够快速上手深度学习,从而使用深度学习技术来训练模型和开发解决方案。

因此,无论您是经验丰富的数据科学家,还是急切想在这方面入门的开发人员,我都乐意分享一些资源,帮助您快速构建深度学习解决方案。

深度学习资源

Apache MXNet 是 Amazon 选择的深度学习框架。借助强大的 Apache MXNet 框架和 NVIDIA GPU 计算,您可以在 AWS 云中方便地启动您的可扩展深度学习项目和解决方案。随着您开始探索 MxNet 深度学习,有很多自助教程和数据集可供您使用:

  • 启动 AWS 深度学习 AMI:该指南可引导您完成基于 Ubuntu 启动 AWS 深度学习 AMI 的步骤
  • MXNet – 创建计算机视觉应用程序:该实践教程使用预构建的笔记本指导您完成使用神经网络实现计算机视觉应用程序来识别手写数字的整个过程
  • AWS 机器学习数据集: AWS 在您可以免费访问的 AWS Marketplace 中托管机器学习数据集。这些大型数据集可供任何人用来分析数据,而无需下载或存储这些数据。
  • 预测和提取 – 学习使用预先训练的模型来进行预测:实践课程将指导您借助预先训练的模型并使用完整 Imagenet 数据集来进行预测和特征提取。

AWS 深度学习 AMI

AWS 提供可在 Amazon EC2 上使用的 Amazon 系统映像 (AMI),用于快速部署开启您的深度学习之旅所需要的基础设施。AWS 深度学习 AMI 预先配置了主流的深度学习框架,使用 Amazon Linux 上的 Amazon EC2 实例和可以为 AI 目标解决方案和模型启动的 Ubuntu 来构建。在深度学习 AMI 中支持和预配置的深度学习框架有:

  • Apache MXNet
  • TensorFlow
  • Microsoft Cognitive Toolkit (CNTK)
  • Caffe
  • Caffe2
  • Theano
  • Torch
  • Keras

此外,AWS 深度学习 AMI 为 Jupyter 笔记本安装与 Python 2.7/3.4、适用于 Python 的 AWS 开发工具包有关的预配置库以及其他与 Python 程序包和依赖项相关的数据科学内容。这些 AMI 还随附 NVIDIA CUDA 和与所有受支持的深度学习框架一起预安装的 NVIDIA CUDA 深度神经网络 (cuDNN) 库,对于 Apache MXNet 框架则会安装 Intel Math Kernel 库。您可以使用尝试深度学习 AMI 链接访问 AWS Marketplace,从而启动任何深度学习 AMI。

总结

现在是深入钻研深度学习的大好时机。通过使用在 AWS 云中运行的 AWS 深度学习 AMI,可以让您的深度学习环境快速运行起来,从而加快您在深度学习方面的工作进度,您也可以通过使用 AWS 自助资源详细了解 AWS 上使用 MXNet 的深度学习。当然,您还可以通过查看 AWS 深度学习页面Amazon AI 产品页面AWS AI 博客,了解有关 AWS 上深度学习机器学习人工智能的更多信息。

愿大家都得到深度学习之原力。

Tara

白皮书:物联网的核心原则

摘要

本文概述了在制定物联网 (IoT) 策略时应考虑的核心原则。本文帮助客户了解 Amazon Web Services (AWS) 的好处以及 AWS 云平台如何成为支持 IoT 解决方案核心原则的关键组件。本文还简要介绍了应作为整个 IoT 策略一部分的 AWS
服务。本文针对的是正在了解物联网平台的决策者。

概述

物联网 (IoT) 策略的核心价值主张之一是让企业能够洞察以前不了解的周边环境。但企业若想制定 IoT 策略,则需要搭建符合 IoT 解决方案的基本原则的平台。

AWS 信奉一些自由原则,这些原则能为企业带来云的组织和经济收益。这些自由正是上百万客户使用 AWS 平台支持几乎所有云工作负载的原因。这些自由还是 AWS 成为跨商业、消费品和工业解决方案的任何物联网策略的主要催化剂
的原因。

采用这些解决方案的 AWS 客户已经确定了一些对所有 IoT 平台的成功都至关重要的核心原则。这些核心原则是敏捷性、可扩展性、成本和安全性;研究表明,它们对于 IoT 策略的长期成功十分重要。

本白皮书将这些原则定义为:

  • 敏捷性 — 不受限制地快速分析、执行和构建业务和技术计划
  • 可扩展性 — 在区域或全球范围内无缝地扩展基础设施以满足运营需求
  • 成本 — 了解和控制运营 IoT 平台的成本
  • 安全性 — 通过云保护来自设备的通信,同时保持合规性和快速迭代

通过使用 AWS 平台,公司能够基于世界上最安全的计算基础设施,构建可进行
扩展以适应设备呈指数级增长并具有管理成本功能的敏捷解决方案。选择具有这些自由的平台并宣传这些核心原则的公司将改进对其业务的独特优势的组织关注,
提高在物联网内实施解决方案带来的战略性价值。

物联网的核心原则

敏捷性

公司在制定 IoT 解决方案时追求的首要收益是高效量化商机的能力。这些商机源自可靠的传感器数据、远程诊断以及用户与设备之间的远程命令和控制。能有效收集这些指标数据的公司可以根据其 IoT 数据探索不同的业务前景。例如,制造商可以构建预测性分析解决方案以持续测量、测试和调整理想的产品维护周期。IoT 生命周期分为多个阶段,涉及采购、制造、装载、测试、部署和管理大批物理设备。在开发物理设备时,瀑布式的开发流程可能降低业务的敏捷性。这种方式加上大规模开发和部署物理资产的前期硬件成本,通常导致必须将设备长时间留在现场才能实现预期的投资回报 (ROI)。

鉴于公司当今面对的挑战和机会不断增加,公司的 IT 部门已成为支持业务绩效、产品开发和运营的独特竞争优势。为了让公司的 IoT 策略成为一项竞争优势,
IT部门需要依靠部署丰富的工具来提高整个 IoT 解决方案的互操作性以及各种设备之间的互操作性。公司若能在瀑布式开发流程与敏捷软件开发之间成功地实现平衡,就能持续优化 IoT 解决方案产生的价值。

可扩展性和全球分布

除了呈指数级增长的互联设备数量之外,物联网中的每个“物(互联设备)”还将传输大量数据,因而它们需要可靠的连接和持久的存储。在云平台出现之前,IT部门通常会采购额外的硬件并维护复杂配置、大量的存储(事实上这些存储并未得到充分的利用)来处理由设备传输的不断增加的数据 (也称为遥测)。在部署 IoT 后,IT部门将面临管理、监控和维护这些互联设备海量网络连接的挑战。

除了在区域性位置扩展解决方案之外,IoT 解决方案还需要能够在全球范围和不同的物理位置进行扩展。IoT 解决方案应该部署在多个物理位置以实现全球企业解决方案的业务目标,如数据合规、数据主权以及降低通信延迟以获得现场设备的更好的响应。

成本

通常,IoT 解决方案的最大价值是从设备得到数据,这些数据是设备生成和发送的遥测数据以及遥测的上下文相关数据。而建立本地基础设施则需要硬件采购上的前期资本投入,这可能是与设备在未来一段时间从遥测数据产生价值不直接相关的大量固定开支。对于接收处理遥测数据这一需求以及遥测数据在将来产生的不确定的价值,要实现两者之间的平衡,IoT 策略应该利用弹性、可扩展的云平台。利用 AWS 平台,公司只需为其使用的服务付费,无需签订长期合同。通过利用灵活、基于使用量的定价模式,IoT 解决方案和相关基础设施的成本可根据通过引入、处理、存储和分析由同一 IoT 解决方案收到的遥测提供的业务价值来评估。

安全性

IoT 解决方案的基础始于安全性、终于安全性。由于设备可能发送大量敏感数据,且 IoT 应用程序的最终用户还可能直接控制设备,因此物理的安全性必须是普遍的设计要求。设计 IoT 解决方案时不应只考虑安全性,还应考虑渗透到解决方案的每个层次的安全控制。安全性并不是一个一成不变的公式;IoT 应用程序必须能够对安全最佳实践进行持续建模、监控和迭代。在物联网中,受攻击的代价与传统
的 Web 基础设施有所不同。普适计算的普遍性意味着 IoT 漏洞可能招来导致人身伤亡的攻击,例如对受损的汽油管道或电网的控制系统的攻击。

IoT 安全性的竞争动力是物理设备的生命周期以及用于传感器、微控制器、促动器和嵌入式库的约束硬件。这些制约因素可能限制每台设备可实现的安全功能。面对这些附加动力,IoT 解决方案必须持续改变其架构、固件和软件才能在不断变化的安全格局中保持领先。尽管设备的制约因素可能带来更高的风险、障碍以及在
安全性与成本之间做出权衡取舍,但构建安全的 IoT 解决方案必须是任何组织
的主要目标。

适用于 IoT 解决方案的 AWS 服务

AWS 平台为执行敏捷、可扩展、安全和经济高效的 IoT 策略提供了基础。为了
实现 IoT 给公司带来的业务价值,客户应评估通常在大型分布式 IoT 部署中使用的 AWS 服务的深度和广度。AWS 提供了用于加快产品上市速度的各种服务:从适用于嵌入式软件的 SDK 到实时数据处理和事件推动的计算服务。

在以下章节中,我们将探讨 IoT 应用程序中最常用的 AWS 服务以及这些服务与 IoT 解决方案的核心原则如何对应。

AWS IoT

物联网不能离开“物” 而存在。每个 IoT 解决方案都必须先建立连接才能开始与
设备交互。AWS IoT 是一项 AWS 托管服务,用于为应用程序解决连接、管理和操作大批设备的难题。AWS IoT 中的连接可扩展性和数据传输安全机制作为 IoT 解决方案的一部分为 IoT 通信提供了基础。当数据发送到 AWS IoT 后,
解决方案能够充分利用涵盖数据库、移动服务、大数据、分析、机器学习等方面
的 AWS 服务生态系统。

设备网关

设备网关负责维护 IoT 解决方案中的所有互联设备的会话。AWS IoT 设备网关支持通过 MQTT、WebSockets 和 HTTP 实现的互联设备与 AWS 平台之间的安全、双向通信。MQTT 和 HTTP 等通信协议使公司能够利用行业标准协议,而不必使用会限制将来的互操作性的专属协议。

作为发布和订阅协议,MQTT 从制定伊始就鼓励可扩展、容错的通信模式并支持设备与设备网关之间的各种通信选项。这包括从两台设备之间的通信到可让一台设备通过共享主题将消息发送到大量设备的广播模式等各种消息模式。此外,MQTT 协议提供不同级别的服务质量 (QoS) 以控制消息在发布给订阅者时的质量(包括再传输和交付机制)。采用 QoS 的发布和订阅的组合不仅让 IoT 解决方案能够控制设备在解决方案中的交互方式,还提高了在出现网络或设备故障时交付、确认和保留消息时的可预测性。

设备影子、设备注册表和 规则引擎

AWS IoT 包含对构建可靠的 IoT 应用程序至关重要的附加功能。AWS IoT 服务
包含 规则引擎,它能够在设备网关接收设备到消息时筛选、转换和转发这些消息。规则引擎利用基于 SQL 的语法从消息负载中选择数据并根据 IoT 数据的特征触发操作。AWS IoT 还提供了维持设备当前状态的虚拟表示-设备影子。设备影子充当一个消息通道,用于将命令可靠地发送到设备并将设备最近的已知状态存储在 AWS 平台中。

为了管理大批设备的生命周期,AWS IoT 提供了设备注册表。设备注册表是一个集中的位置,用于存储和查询与每个“物”相关联的预定义的属性。设备注册表支持创建用于控制设备、设备影子、权限和身份之间关系的 IoT 解决方案整体管理视图。

安全和身份

对于互联设备,应在整个硬件和软件开发生命周期中使用IoT 平台所提供的身份识别、最小特权、加密和授权的功能。AWS IoT 通过使用传输层安全协议 (TLS) (支持大多数主流密码包) 对和该服务通信的流量进行加密。为了识别设备身份,AWS IoT 要求互联设备使用 X.509 证书进行身份验证。每个证书必须预先配置、激活并安装在设备上,然后才能与 AWS IoT 的有效身份相关联。为了支持设备的这种身份和访问的分离,AWS IoT 提供了针对设备身份的 IoT 策略。AWS IoT 还可针对 AWS 用户、组和角色利用 AWS Identity and Access Management (AWS IAM) 策略。通过使用 IoT 策略,公司可以控制(允许和拒绝)每台指定身份的设备进行的通信。AWS IoT 策略、证书和 AWS IAM 可为公司在 AWS IoT 生态系统中的每台设备通信通道显式配置白名单。

事件驱动的服务

为了让 IoT 解决方案符合可扩展性和灵活性的原则,公司应该引入事件驱动机制。在IoT 解决方案中触发的事件,事件驱动机制通过对事件的创建、存储、消费和响应来建立可扩展性和解耦的通信。首先,应当对IoT 解决方案中生成的消息进行归类并将其映射到一系列事件。然后将这些事件与业务逻辑关联起来,这些业务逻辑在执行过程中还可能会触发更多的事件。AWS 平台提供很多种应用服务,使用这些应用服务可以帮助其构建分布式的事件驱动的IoT架构。

基本上,事件驱动架构依靠的是对订阅者生态系统的持久存储事件和发送事件的能力。为了支持解耦事件的编排,AWS 平台提供了多项专门用于可靠的事件存储和高度可扩展的事件驱动型计算的应用服务。事件推动的 IoT 解决方案可以使用 Amazon Simple Queue Service (Amazon SQS)、Amazon Simple Notification Service (Amazon SNS) 和 AWS Lambda 作为用于创建简单或者复杂事件工作流的基础应用组件。Amazon SQS 是一项快速、持久、可扩展且完全托管的消息队列服务。Amazon SNS 是一项 Web 服务,用于从应用程序发布消息并立即将它们交付到订阅者或其他应用程序。AWS Lambda 用于以事件响应方式触发代码的运行,而底层计算资源是全托管的。AWS Lambda 可直接从其他 AWS 服务接收和响应事件。在事件驱动的 IoT 架构中,当IoT 系统上下文中有相关事件发生时就会触发AWS Lambda以执行相应的业务逻辑。

AWS 服务 (如 Amazon SQS、Amazon SNS 和 AWS Lambda) 可将事件的消费从对消息的处理过程和业务逻辑分离开。这种分离为端到端解决方案带来了灵活性和敏捷性。这种分离让您可以快速修改事件触发逻辑或用于聚合系统各个部分之间的上下文相关数据的逻辑。最后,这种分离支持将变化引入 IoT 解决方案而不会阻止在最终设备和 AWS 平台之间发送的数据的持续传输。

自动化和开发运营

在 IoT 解决方案中,应用程序的初始发布便是长期持续优化业务逻辑的IoT策略的起点。在这之后,您的大部分时间和精力便可集中在为你的IoT解决方案业务增加新特性上。基于“在整个解决方案生命周期中保持敏捷性”这一原则,客户应评估支持根据业务需求的变化而快速开发和部署的服务。与DevOps技术仅用于后端服务器的传统Web架构不同的是,IoT 应用程序还需要一种能力 — 不断对各种全球互联设备迭代变化的能力。利用 AWS 平台,公司可以应用服务端和设备端应用各种DevOps实践已达到自动化运维。

在 AWS 云平台中部署的应用程序可利用 AWS 上的多种DevOps技术。要了解 AWS DevOps,我们建议查看文档 《Introduction to DevOps on AWS》[1]。尽管大多数解决方案对部署和运维的要求不同,不过 IoT 解决方案可使用 AWS CloudFormation 以代码的方式定义服务端的基础设施。这种以代码定义基础设施的好处有:可重现、可测试和可在其他 AWS 区域中更轻松地部署。企业利用AWS CloudFormation 和其他DevOps工具可以显著提高应用程序的敏捷性和应对应用程序变化的速度。

 

为了设计符合安全性和敏捷性原则的 IoT 解决方案,组织还必须能够在将互联设备部署到环境中后更新该设备。固件更新为公司提供了一个将新功能添加到设备的机制,并且是在设备的生命周期中提供安全修补程序的关键途径。为了对互联设备实施固件更新,IoT 解决方案应该首先将固件存储在可全球访问的服务
(如 Amazon Simple Storage Service (Amazon S3)) 中以实现安全、持久和高度可扩展的云存储。然后,IoT 解决方案可使用全球内容分发网络 (CDN) 服务 Amazon CloudFront 以较低的延迟将存储在 Amazon S3 中的固件引入到互联设备。最后,客户可利用 AWS IoT 设备影子将命令推送到设备,以出发设备从预签名的 Amazon CloudFront URL (限制对通过 CDN 提供的固件对象的访问) 中下载新版本的固件。升级完成后,设备可以通过将消息发送回 IoT 解决方案以确认升级是否成功。通过固件更新编排这一系列服务,客户可以控制对设备的DevOps方法,并扩展这种方法以和整体IoT策略保持一致。

在 IoT 中,自动化和DevOps过程将扩展到在 AWS 平台中部署的应用服务之外,并包含已作为整个 IoT 架构的一部分部署的互联设备。通过设计可为新软件更改和固件更改轻松执行定期和全局更新的系统,组织可以对方法进行迭代以提升来自 IoT 解决方案的价值和在新的市场机会出现时持续创新。

管理和安全

安全在IoT中不仅仅是数据匿名化,它还是一种能够在整个系统中具有洞悉,可审核性和控制力的能力。IoT 安全包括监控整个解决方案中的事件以及对这些事件进行响应以实现所需的合规性和监管力的能力。保证 AWS 的安全性是我们工作的重中之重。通过 AWS 责任分担模型,组织获得了满足安全要求所需的灵活性、敏捷性和控制力。[2] AWS 负责管理云本身的安全,而客户负责运行在云内部的安全。客户可以始终控制他们实施哪个安全机制来保护数据、应用程序、设备、系统和网络。此外,公司可以利用 AWS 和 AWS 合作伙伴提供的各种安全和管理工具为大批设备创建强大、安全、在逻辑上隔离的 IoT 解决方案。

第一个应该打开的服务应该是AWS CloudTrail,AWS CloudTrail支持对您的AWS账户进行监管、合规性检查、操作审核和风险审核。AWS CloudTrail是一项服务,它会记录整个 AWS 基础设施中的 API 调用,并向 Amazon S3 发送日志文件。在启用 AWS CloudTrail 后,解决方案可以建立安全和监管流程,这些流程基于来自跨 AWS 账户进行的 API 调用的实时输入。在创建系统中可操作性和开放性并对其进行迭代方面,AWS CloudTrail 提供更高的可见性和灵活性。

除了记录 API 调用之外,客户还应为系统中使用的所有 AWS 服务启用 Amazon CloudWatch。Amazon CloudWatch 支持应用程序监控 AWS 指标和创建由应用程序生成的自定义指标。这些指标可以基于规则警报事件。除了 Amazon CloudWatch 指标之外,还有 Amazon CloudWatch 日志,该日志将存储来自 AWS 服务或客户应用程序的额外日志,并且可基于这些额外指标触发事件。AWS 服务 (如 AWS IoT) 直接与 Amazon CloudWatch 日志集成;这些日志可作为数据流动态读取,并可以使用系统的业务逻辑和上下文进行处理以实现实时异常检测或应对安全威胁。

通过将服务 (如 Amazon CloudWatch 和 Amazon CloudTrail) 与 AWS IoT 身份
和策略的功能配对,公司可以在 IoT 策略启动时立即收集有关安全做法的宝贵数据并满足在 IoT 解决方案中主动实施安全做法的需求。

将服务与解决方案结合起来

要更好地了解客户使用量、预测未来趋势或更有效地运营 IoT 系统,组织需要
收集和处理从互联设备收集的数量巨大的数据,并且需要连接和管理大量的“物”。

AWS 提供了用于收集和分析大量数据集 (通常称为大数据) 的各种服务。这些服务可能在 IoT 解决方案中紧密集成,以支持收集、处理和分析解决方案的数据,
以及利用IoT数据对设想做证明和否定。通过管理大批“物”的同一平台对问题进行构想和解答,组织最终能够避免重复工作并能以敏捷的方式发挥企业的创新力。

将 IoT、大数据和其他服务结合在一起的 IoT 解决方案的高层次衔接架构称为杂注(Pragma)架构。杂注架构由多个层次的解决方案组成:

  • 物质 — 设备或一组设备
  • 控制层 — 用于访问速度层的控制点和用于设备组管理的 nexus
  • 快速处理层 — 入站、高带宽设备遥测数据总线和出站设备命令总线
  • 服务层 — 供系统和人员与队列中的设备交互的访问点,用于执行分析、存档和关联数据以及使用队列的实时视图。

杂注架构

杂注架构是单一的衔接透视图,阐明了在使用 AWS 服务时 IoT 的核心原则如何表示为 IoT 解决方案。

基于杂注架构的 IoT 解决方案的一个情景是处理由设备发出的数据;这些数据也称为遥测。在上图中,当设备使用从控制层中的 AWS IoT 服务获得的设备证书进行身份验证后,设备将定期向速度层中的 AWS IoT Device Gateway 发送遥测数据。遥测数据随后被 IoT 规则引擎作为事件处理,处理结果将由Amazon Kinesis 或 AWS Lambda 输出并由与服务层交互的 Web 用户使用。

基于 IoT 解决方案的杂注架构的另一个情景是将命令发送到设备。在上图中,用户的应用程序将所需的命令值写入到目标设备的 IoT 设备影子。然后,AWS IoT 设备影子和 设备网关将合作克服网络卡顿状况以将命令传达到特定设备。

这只是与杂注架构相配的众多解决方案中的两个以设备为中心的情景。这些情景都不能满足“处理从互联设备收集的可能数量巨大的数据”这一需求,这就让集成式大数据后端有了用武之地。此图中的大数据后端适合客户已利用 AWS 平台创建的实时和批处理模式大数据解决方案的整个生态系统。简而言之,从大数据的角度来看,IoT 遥测相当于大数据解决方案中“接收的数据”。如果您想详细了解 AWS 上的大数据解决方案,请单击下方的延伸阅读链接。

公司已使用 AWS 平台创建了丰富的大数据解决方案。杂注架构展示了通过在同一平台上构建 IoT 解决方案,大数据解决方案的整个生态系统都将可用。

总结

定义您的物联网策略可能是为独特的业务创新开启大门的一项真正变革式的工作。随着组织开始努力实现自己的 IoT 创新,选择推崇以下核心原则的平台很关键:业务和技术敏捷性、可扩展性、成本和安全性。AWS 平台不仅提供 IoT 服务,还为这些服务配套提供跨全球足迹的一套广泛、深入和高度相关的平台服务,从而超额兑现对 IoT 解决方案的核心原则的承诺。此超额兑现还带来了可提高您的企业对自己命运的掌控力的自由度,并使您的企业的 IoT 解决方案能够更快地向 IoT 策略追求的成果迭代。

作为评估 IoT 平台的后续步骤,我们建议进一步阅读下面的章节以详细了解 AWS IoT、AWS 上的大数据解决方案和 AWS 上的客户案例研究。

客户案例

Phillips Healthcare

https://amazonaws-china.com/cn/solutions/case-studies/philips/

Phillips Healthcare是一家领先的健康科技公司,致力于在从健康的生活方式及疾病的预防、到诊断、治疗和家庭护理的整个健康关护全程,提高人们的健康水平,并改善医疗效果。公司的医疗信息、服务与解决方案部门基于AWS的飞利浦HealthSuite数字化平台致力于为全球数亿人医疗保健革新。飞利浦HealthSuite数字化平台分析和存储15PB的病人数据,这些数据包括了3亿9千多万个诊断影像、医疗记录、病人监护、健康信息等,并直接给病人的医疗保健提供可操作化的数据。飞利浦HealthSuite数字化平台运行在可靠的、高性能和可扩展的AWS之上,保证每月Pb级的全球病人数据增长。

“飞利浦医疗正在与诸如AWS、学术医疗中心以及病人权益保护者等技术公司进行合作,加速实现从健康生活方式、疾病预防,到疾病诊断、治疗和家庭护理的个人健康全覆盖的互连管理平台,并致力于全球化规模。”–Jeroen Tas, 飞利浦医疗信息、服务与解决方案CEO

iRoBot

https://amazonaws-china.com/cn/solutions/case-studies/irobot/

艾罗伯特公司基于AWS高度可扩展以及全球化的云端服务产品,并充分利用AWS广大的生态合作伙伴体系,致力于通过其扫地机器人产品(例如广受欢迎的Roomba)实现未来智慧家庭的愿景。艾罗伯特公司是世界知名的消费机器人公司,在全球已经售出了多达1500万的家用机器人。公司在2015年推出的第一款智能互连的机器人产品Roomba,到目前为止已经绘制了超过500万平方英尺的室内地图,为实现智慧家庭的愿景迈出了坚实的一步。艾罗伯特公司的创新充分利用了AWS丰富的云端服务产品,其中包括物联网服务(IoT)、计算服务、手机服务、分析服务、存储服务、数据库服务、平台管理服务以及网络服务等。

“艾罗伯特公司非常高兴在发展机器人云端服务战略时能与AWS结为合作伙伴。AWS拥有世界知名的品牌、丰富的云端服务产品以及世界级的云服务基础设施,这些都将极大程度地加快艾罗伯特开发智能互联机器人科技,并拓展机器人在智慧家庭中的应用价值。基于AWS云端服务产品,艾罗伯特能够提升现有机器人产品的服务能力,改善客户体验,从而引领一个居家生活的新时代。” –Colin Angle,艾罗伯特主席及CEO

Rachio

(https://amazonaws-china.com/cn/solutions/case-studies/rachio/)

Rachio公司位于科多拉多,是一家制造同时提供软件解决方案的智能洒水控制器生产厂商。Rachio智能洒水控制器提供基于WiFi的洒水控制能力,帮助用户设置并优化其洒水计划。通过很多在线商城就可以购买到这一款控制器,该控制器能够获取并利用当地的天气预报信息,提供多达16种模式并根据植物和土壤类型来设置洒水时间以及洒水量。从而在满足草坪和庭院的用水需求前提下,最大程度的节约水资源。

“AWS IoT服务提供了领先的边缘端的安全管理能力。消息本身是加密的,消息代理又增加了另一层安全机制。一般而言,基于策略的安全机制是AWS的一大优势。当某一个设备异常时,我们不需要重新发放证书,只需要隔离异常设备的策略即可。这种方式既简单又高效。”–Garsombke,CTO与联合创始人

Enel

(https://amazonaws-china.com/cn/solutions/case-studies/enel/)

意大利能源公司是一家跨国企业,给6100万客户提供电力与燃气服务。意大利能源公司基于AWS构建其物联网管理平台,提供能源管理服务。

“基于AWS云端服务,意大利能源公司不但节省了21%的计算成本,60%的存储成本,并且将提供服务的时间从4周缩短到2天,这一切都大大改变了业务运营方式。” –Fabio Veronese, 基础设施与技术服务部

延伸阅读

如需补充阅读,请查阅以下资源:

·         AWS IoT 服务

·         AWS IoT 入门

·         AWS 案例研究

·         AWS 上的大数据分析选项

备注

[1] https://d0.awsstatic.com/whitepapers/AWS_DevOps.pdf
[2] https://aws.amazon.com/compliance/shared-responsibility-model/

补上 2017 年年初的 AWS 公告

尽管今年迄今为止我们已经发布了 123 篇文章,但我们根本没有时间来介绍每一项重要的 AWS 发布。此外,较新的服务通常更加丰富,并需要更多空间加以描述,这也增加了我们的工作量。本文 (以及随后每个季度的其他文章) 将概述我们之前没有时间介绍的一些发布。例如:

  • 针对 NoSQL 数据库的迁移支持
  • 面向 WorkDocs 的注释、标记和元数据 API。
  • Pinpoint 的电子邮件和短信集成
  • AWS Budgets 的使用类型组和链接账户访问
  • EC2 Systems Manager 对层次结构、标记和 CloudWatch Events 的支持

这些功能已经推出,您可能已经在使用它们了!

针对 NoSQL 数据库的迁移支持

通过此次发布,AWS Database Migration Service 可以迁移关系数据库、NoSQL 数据库和数据仓库。此次发布支持将 MongoDB 数据库用作迁移源,将 Amazon DynamoDB 表用作迁移目标。要开始操作,请为 MongoDB 和 DynamoDB 创建复制实例和数据库终端节点:

有关更多信息,请阅读MongoDB 用作 AWS Database Migration Service 的源将 Amazon DynamoDB 数据库用作 AWS Database Migration Service 的目标

面向 WorkDocs 的注释、标记和元数据 API

Amazon WorkDocs 管理软件开发工具包提供用于创建和访问元数据、标记和注释的 API:

元数据CreateCustomMetadataDeleteCustomMetadata

标记CreateLabelsDeleteLabels

注释CreateCommentDeleteCommentDescribeComments。该软件开发工具包适用于 Java、Python、Go、JavaScript、.NET、PHP 和 Ruby。它使用 Sigv4 处理 API 请求的签名,并与 IAM (角色和权限)、SNS (实时通知) 和 CloudTrail (监控) 集成。

Pinpoint 的电子邮件和短信集成

除现有移动推送通知外,Amazon Pinpoint 现在还可以通过电子邮件和短信通知推动用户参与。为了使用此功能,您必须首先启用一个或多个所需通道:

要了解更多信息,请阅读 Amazon Pinpoint Channels

AWS Budgets 的使用类型组和链接账户访问

AWS Budgets 允许您设置成本和使用量预算,并在超出预算时收到通知 (请阅读利用预算管理成本AWS Budgets Update – Track Cloud Costs and Usage)。为了使 AWS Budgets 更加有用,我们添加了对链接账户和新的使用类型筛选选项的支持。利用整合账单整合多个 AWS 账户付款的组织将从对链接账户的支持中受益。成员账户现在可以访问他们自己的预算,而付款人账户仍然负责付款。使用类型和使用类型组筛选维度允许您从聚合级别跟踪成本和使用情况,一直跟踪到最基本的计量单位。例如,您可以创建一个预算来跟踪所有 EC2 使用情况 (EC2-Running Hours):

或者跟踪特定使用类型,在本例中,跟踪三种不同大小的 T2 实例:

EC2 Systems Manager 对层次结构、标记和 CloudWatch Events 的支持

此管理服务可帮助您自动收集软件清单,应用操作系统修补程序,创建系统映像以及配置 Linux 和 Windows 操作系统。Parameter Store (该服务最受欢迎的功能之一) 以加密形式存储数据库访问字符串和密码等配置数据。可以通过 CLI、API 和软件开发工具包访问该功能;这将允许在 Amazon ECS 容器内运行的 AWS Lambda 函数和代码访问相同的参数。

我们添加了对分层形式的参数存储的支持,使您能够按组织、应用程序等因素进行分组。您还可以创建并行参数集以用于开发、测试和生产环境。要创建参数层次结构,请使用包含一个或多个“/”字符的名称:

我们还添加了对标记的支持。您可以基于标签查询参数,并且可以通过标签添加对参数的 IAM 权限。

最后,参数存储现在是 CloudWatch Events 的源。现在您可以跟踪参数的更改,也许可以确保它们不会无意中被更改从而可能破坏现有应用程序:

保持关注

除了定期阅读此博客,您还可以在 Twitter 上关注Jeff Barr 和 AWS Cloud。此外,还可以查看 AWS 新增功能并订阅 RSS 源。

-Jeff

新增 – CloudWatch Events 的跨账户传送功能

CloudWatch Events 让您能够跟踪和响应 AWS 资源中的更改。您可以获得几乎实时的事件流,并使用规则将其路由到一个或多个目标 (AWS Lambda 函数、Amazon Kinesis 流、Amazon SNS 主题等)。生成的事件取决于特定的 AWS 服务。例如,以下是为 EC2 实例生成的事件:

或者,对于 S3 (必须启用 CloudTrail 才能创建使用这些事件的规则):

请参见 CloudWatch 事件类型列表,以查看有哪些服务和事件可用。

新的跨账户事件传送客户要求我们扩展 CloudWatch Events,以处理跨多个 AWS 账户的一些有趣且强大的使用案例,我们也很乐意满足这些要求。今天,我们将添加对 CloudWatch Events 的受控、跨账户传送的支持。如您所见,现在您可以安排将事件从一个 AWS 账户路由到另一个账户。与现有的事件传送模式一样,您可以使用 CloudWatch Events 规则来指定要将哪些事件发送到另一个账户。

以下是客户与我们分享的一些使用案例:

隔离问题 – 客户希望在单独的账户中处理和响应事件,以实施高级安全方案。

汇总 – 客户正在使用 AWS Organizations,并希望在整个组织范围内跨多个 AWS 账户跟踪某些类型的事件。

每个 AWS 账户都使用资源事件总线来分发事件。该对象可追溯到 CloudWatch Events 的引入,但从未这样被正式地称呼过。AWS 服务、PutEvents 函数和其他账户可以向该对象发布事件。

事件总线 (目前每个账户一个,计划将来允许一个账户有更多事件总线) 现在有一个关联的访问策略。该策略指定允许向总线发送事件的一组 AWS 账户。您可以添加一个或多个账户,也可以指定允许任何账户发送事件。

您可以创建基于扇入或扇出模式工作的事件分发拓扑。扇入模式允许您在一个位置处理来自多个账户的事件。扇出模式允许您将不同类型的事件路由到不同的位置和账户。

为了避免形成循环的可能性,从一个账户发送到另一个账户的事件将不会发送到第三个账户。在计划跨账户实施时,应该考虑到这一点。

使用跨账户事件传送为了测试此新功能,我利用了我的工作和个人 AWS 账户。我登录到个人账户并转到 CloudWatch 控制台。然后,我选择 Event Buses,单击 Add Permission,并输入我的工作账户的账户 ID:

我可以在一个位置看到我的所有总线 (目前只允许一个总线) 和权限:

接下来,我登录到我的工作账户,并创建一条规则,以便将事件发送到我的个人账户中的事件总线。在本例中,我的个人账户对我的工作账户中运行的 EC2 实例的状态更改感兴趣:

回到我的个人账户,我创建一条将针对任何 EC2 事件触发的规则,并将其目标设置为配置为发送电子邮件的 SNS 主题:

对我的个人账户中启动的 EC2 实例测试此规则后,我将在我的工作账户中启动一个实例并等待电子邮件消息:

消息中的账户和资源字段来自源 (工作) 账户。

须知事项

此功能在所有提供 CloudWatch Events 的 AWS 区域均可用,您可以立即开始使用它。也可以从 CloudWatch Events APIAWS Command Line Interface(CLI) 访问此功能。从一个账户转发到另一个账户的事件被视为自定义事件。发送账户每发送一百万个事件需支付 1 USD (有关更多信息,请参阅 CloudWatch 定价)。

-Jeff

PS – AWS CloudFormation 支持正在准备阶段,即将推出!

AWS 降价 – 在Amazon EC2 上运行的 SQL Server 标准版

我很高兴地宣布,AWS 迎来了第 62 次降价,本次降价适用于在 EC2 上运行的 Microsoft SQL Server 标准版

许多企业工作负载都在 Microsoft Windows 上运行,主要是在本地部署或企业数据中心。AWS 上提供了各种各样的服务,由我们覆盖全球的基础设施合作伙伴生态系统提供支持,因此,我们认为它是构建、部署、扩展和管理 Windows 应用程序的最佳位置。AdobePitney BowesDeVry University 等客户都已将核心生产 Windows Server 工作负载移到了 AWS。他们的应用程序囊括从 SharePoint 站点到自定义 .NET 应用程序和 SAP 的全部范围,且经常使用 SQL Server。

Microsoft SQL Server on AWS 运行在 EC2 Windows 实例上,并可为您的应用程序开发和迁移提供支持。通过它,您可以控制所有设置,就像在本地部署中运行关系数据库时控制设置一样,它支持 32 位和 64 位版本。

今天,我们将降低在 R4、M4、I3 和 X1 实例上运行的 EC2 上的 Microsoft SQL Server 标准版的按需和预留实例价格,降幅高达 52%,具体取决于实例类型、大小和区域。您可以构建和运行企业级应用程序、可大规模扩展的网站及移动应用程序,成本比以往任何时候都低。

下面是针对每个区域和实例类型的最大降价幅度:

区域 R4 M4 I3 X1
[iad] -51% -29% -50% -52%
[cmh] -51% -29% -50% -52%
[pdx] -51% -29% -50% -52%
[sfo] -51% -30% -50%
[yul] -51% -51% -50% -44%
[gru] -49% -30% -48%
[dub] -51% -29% -50% -51%
[fra] -51% -29% -50% -50%
[lhr] -51% -51% -50% -44%
[sin] -51% -31% -50% -50%
[syd] -51% -30% -50% -50%
[nrt] -51% -29% -50% -50%
[icn] -51% -31% -50% -50%
[bom] -51% -33% -50% -50%

按需实例新的更低价格自 2017 年 7 月 1 日开始生效。预留实例的新定价从今日开始生效。

-Jeff

新增 – 面向 Amazon CloudWatch 控制面板的 API 和 CloudFormation 支持

我们在几年前发布了 CloudWatch 控制面板。在专为这次发布撰写的文章中,我介绍了如何以交互方式创建控制面板,以便以图形形式显示所选的 CloudWatch 指标。发布之后,我们增加了其他功能,包括全屏模式、深色主题、控制 Y 轴的范围、简化的重命名、持久性存储和新的可视化选项

新 API 和 CLI

虽然控制台支持非常有利于交互式使用,但许多客户要求我们提供对控制面板及其中小部件的编程式创建和操作的支持。这些客户想要动态构建和维护控制面板,从而在创建和销毁相应的 AWS 资源时添加和删除小部件。其他客户则希望在两个或多个 AWS 账户中设置和维护一组一致的控制面板。

我非常高兴地宣布,面向 CloudWatch 控制面板的 API、CLI 和 AWS CloudFormation 支持现已推出,您可以立即开始使用!

我们新增了四个 API 函数 (和等效的 CLI 命令):

ListDashboards / aws cloudwatch list-dashboards – 用于提取账户内所有控制面板的列表,或共享通用前缀的子集。

GetDashboard / aws cloudwatch get-dashboard – 用于提取单个控制面板的详细信息。

PutDashboard / aws cloudwatch put-dashboard – 用于创建新控制面板或更新现有控制面板。

DeleteDashboards / aws cloudwatch delete-dashboards – 用于删除一个或多个控制面板。

控制面板概念 我将要向您展示如何使用这些函数和命令。在转入正题之前,我应该介绍几个重要的控制面板概念和属性。

全局 – 控制面板是 AWS 账户的一部分,但未与特定 AWS 区域关联。每个账户最多可以包含 500 个控制面板。

命名 – 每个控制面板都有一个在 AWS 账户内唯一的名称。名称最长可达 255 个字符。

网格模式 – 每个控制面板都由网格单元格组成。网格包括 24 个单元格,高度可根据需要调整。控制面板中的每个小部件可位于一组特定的网格坐标上,大小可跨越一个整数的网格单元格。

小部件 (可视化) – 每个小部件可以显示文本或一组 CloudWatch 指标。文本通过 Markdown 指定;指标可以显示为单个值,或以折线图或堆积面积图的形式显示。每个控制面板最多可以包含 100 个小部件。显示指标的小部件还可以与 CloudWatch 警报相关联。控制面板有 JSON 表示形式,现在您可以在控制台中看到并编辑它。只需单击 Action 菜单并选择 View/edit source 即可:

下面是我的控制面板源:

您可以使用此 JSON 作为您自己的应用程序的起点。如您所见,控制面板中每个小部件的 widgets 数组中都有一个条目;每个条目描述一个小部件,从其类型、位置和大小开始。

使用 API 创建控制面板

假设我要在特定区域为我的每个 EC2 实例创建一个含有小部件的控制面板。我会使用 Python 和适用于 Python 的 AWS 软件开发工具包,然后按如下所示开始创建 (请原谅我的代码不够专业):

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

接着,我直接对实例进行迭代,以便为每个实例创建 widget 词典,并将其附加在 widgets 数组中:

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

我更新循环内的位置 (xy),并形成一个网格 (如果我不指定位置,则小部件会从左向右、从上至下进行排列):

        x += width
        if (x + width > max_width):
            x = 0
            y += height

处理完所有实例后,我创建一个 JSON 版本的小部件数组:

body   = {'widgets' : widgets}
body_j = json.dumps(body)

接下来,我创建或更新我的控制面板:

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

运行代码后,会获得以下控制面板:

CloudWatch 团队建议,以编程方式创建的控制面板应包括文本小部件 (用于说明控制面板是自动生成的) 以及指向所使用的源代码或 CloudFormation 模板的链接。这样可防止用户在外部对控制面板进行手动更改。如前所述,每个指标小部件还可以与一个 CloudWatch 警报相关联。您可以通过编程方式或使用 CloudFormation 模板来创建警报,如示例 CPU 使用率警报。如果您决定这样做,则警报阈值会显示在小部件中。要详细了解此操作,请阅读 Tara Walker 近期发布的文章 Amazon CloudWatch 发布了控制面板警报功能。更进一步的操作是,我可以使用 CloudWatch Events 和 Lamba 函数来跟踪某些资源的创建与删除,并在发生更改时更新控制面板。要了解如何执行此类操作,请阅读使用 AWS Lambda 让 CloudWatch 控制面板保持最新

使用 CLI 访问控制面板 我还可以通过命令行访问和操作我的控制面板。例如,我可以生成一个简单的列表:

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

然后,我删除 Disk-Metrics 控制面板:

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

此外,也可以检索用于定义控制面板的 JSON:

使用 CloudFormation 创建控制面板

控制面板还可以在 CloudFormation 模板中进行指定。下面是一个简单的 YAML 格式的模板 ( DashboardBody 仍以 JSON 指定):

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

我将模板放置在一个文件中,然后使用控制台或 CLI 创建堆栈:

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

下面是控制面板:

现已推出

此功能现已推出,您可以立即开始使用。您可以免费创建 3 个控制面板,每个控制面板最多包含 50 项指标;如果创建的控制面板超过 3 个,则每月需支付 3 USD (相关价格信息,请访问 CloudWatch 定价页面)。您每月最多可以免费调用 100 万次新 API 函数;如果超出此范围,则每调用 1000 次需支付 0.01 USD。

-Jeff

现已推出 – AWS SDK for Java 2.0 的开发人员预览

AWS 开发人员工具团队一直苦心致力于 AWS SDK for Java 的开发,今天终于推出了 2.0 版开发人员预览版。这个版本是对旧 1.11.x 代码库的重大修改。新 SDK 构建在 Java 8 之上,重点在于一致性、不变性和易用性,包括经常请求的功能,例如支持非阻塞 I/O 以及在运行时选择所需的 HTTP 实现的能力。新的非阻塞 I/O 支持,比现有的服务客户端基于线程的异步变体实现更有效。每个非阻塞请求都返回一个 CompletableFuture 对象。版本 2.0 SDK 包括对早期 API 的许多更改。例如,它使用基于客户端生成器和不可变客户端的一致模型来代替客户端构造函数和可变方法的现有组合。该 SDK 还将用于配置多个区域的离散类集合折叠为单个区域类,并提供一组新的用于流式处理的 API。该 SDK 在 GitHub 上提供。您可以通过打开 GitHub 问题发送公共反馈,也可以按照通常的方式发送提取请求。要了解有关此 SDK 的更多信息,请阅读 AWS 开发人员博客上的AWS SDK for Java 2.0 – 开发人员预览

-Jeff