企业网站运行环境|服务器故障排查|服务器防攻击挂马清除，首发于服务器安全维护工作室。

云服务器时代，品质服务。7×24专业代运维服务，服务器安全、稳定，专业团队标准化运维服务，网站维护，服务器代维，安全代维，清除木马,，北京、成都、上海上门服务，堡垒机配置加固。

云服务器专业安全代维 服务器代维 阿里云代维 云主机代维 运维外包服务，首发于服务器安全维护工作室。

产品说明

企业上云迁移方案实施服务，首发于服务器安全维护工作室。

在大型企业云迁移项目组，经常会遇到企业将线下数据中心的子网迁移到 AWS 云上。线下的子网划分一般会根据子网的使用功能不同进行划分，例如防火墙子网、负载均衡器子网、配合部署高可用架构的心跳线子网、应用系统子网等。不同企业的子网划分规则、子网的掩码大小和路由规则均不相同，并且在迁移后的系统上线后，企业还会经常划分新的网段以部署新的应用系统，这就需要有一个通用的模板来协助网络管理人员简化工作流程，提高工作效率。在我所经历过的一个项目中，生产 VPC 的子网划分有47个之多，且子网掩码有/24, /25, /26. 27/, /28等不同，在添加新的子网时，需要仔细计算新的子网 CIDR 以及为新建子网配置路由表。

动态创建子网的方案概述

因为 CloudFormation 不支持程序逻辑，只支持静态资源的创建，所以在本方案中采用 AWS Lambda 来基于输入参数动态创建不同类型的子网。我们定义了3种不同类型的子网：公共子网 (Public Subnet)， 外部子网 (External Subnet)，内部子网 (Internal Subnet) Subnet。
公共子网的路由表有如下路由信息：

部署在公共子网中的服务器可以直接与 Internet 进行通信（缺省分配 Internet IP 地址，并且有指向 Internet Gateway 的缺省路由）。
外部子网的路由表有如下路由信息：

部署在外部子网的服务器可以通过 NAT Gateway 与 Internet 进行通信，并且可以不通过互联网访问 S3 和 dynamodb。
内部子网的路由表有如下路由信息：

部署在内部子网的服务器不能访问 Internet，但是能直接访问 S3 和 dynamodb。
本方案使用2个 CloudFomation 模板， 第一个模板(CreateBaseVpc.json)创建共享资源，例如 VPC、Internet Gateway、公共子网 (Public Subnet) 路由表、在各个可用区内创建公共子网、NAT Gateway、 VPC Endpoint (S3 endpoint和DynamoDB endpoint)和创建外部子网路由表。在这个模板中还创建了3个 Lambda 功能函数：

• SharedInfra – 对应 python 程序 create_shared_infra.zip

功能：根据输入的参数，在程序运行的AWS Region的每个AZ内创建公共子网，将在 CreateBaseVpc.json 模板中建立的公共子网路由表关联到每个公共子网。 在每个公共子网内创建 NAT Gateway 和VPC endpoint，创建内部子网路由表，创建外部子网路由表。删除已经创建完成的资源，包括：子网、路由表、vpc endpoint、NAT Gateway、Elastic IP。

• CreateExternalRoute – 对应 python 程序 create_external_route.zip

功能：创建外部子网路由表中的路由。因为 NAT Gateway 的创建速度比较慢，创建路由时一定要等待 NAT Gateway 的状态变成 available 后才可以成功。如果将此功能与 SharedInfra 放在一起，在执行的时候容易发生 Lambda 运行超时错误。删除已经创建的路由信息。

• SubnetAutomation – 对应 python 程序 subnet_creation.zip

功能：根据输入的参数，计算网路的子网掩码，创建公共子网、外部子网和内部子网，并将在公共子网路由表、内部子网路由表和外部子网路由表关联到相应的子网上。删除已经创建完成子网。在 CreateBaseVpc.json 模板运行时，通过创建用户定义资源 ExternalRouteCreation和SharedInfraCreation 分别触发 Lambda 功能 CreateExternalRoute 和 SharedInfra，从而完成共享资源的创建。并提供了 SubnetAutomation 的功能函数 ARN，供运行第二个模板时调用。

第二个模板 (SubnetAuto.json) 创建动态资源，例如根据输入参数的不同计算子网掩码、创建子网并分配路由表。

本方案中创建子网时的输入参数并不需要 CIDR，只需要指定子网要提供的可用 IP 地址的个数即可，程序在计算可用 IP 地址时已经排除了 AWS 子网子网中保留的5个 IP 地址。例如：如果要创建有50个 IP 的子网，则子网掩码是/26，共计有64-5=59个可用IP地址；如果要创建有16个 IP 的子网，则子网掩码是/27，共计有32-5=27个可用 IP 地址。

创建子网的参数输入规则如下：

1. 每个子网包含4个部分，之间使用“:”分隔 – 功能: IP 地址数量:可用区:子网类型
2. 可用区根据Region的不同可选项为：1a,1b,1c,1d,1e等
3. 子网类型的可选项为：p（公共子网），e（外部子网）或者 i（内部子网）
4. 不同子网之间使用“,”分隔。

安装和运行

1. 在浏览器中输入：https://github.com/shaneliuyx/autosubnet_creation， 下载2个 json 文件和3个 zip 文件。将3个 zip 文件上传到一个 S3 存储桶中。
2. 打开 AWS 控制台，并选择 CloudFormation，选择存储在本地的 json 文件 json，运行 CloudFormation 模板。
3. 假设输入缺省的 PublicSubnetCapacity 和 VpcCidr 如下：

1. 选择 Next，直至 AWS 资源开始创建
2. 最终运行结果如下：

创建的 Subnet 如下：

公共子网路由表：

1. 打开 AWS 控制台，并选择 CloudFormation，选择存储在本地的 json 文件 json，运行 CloudFormation 模板。
2. 输入 SubnetParameters：web1:50:1a:p,web1:50:1b:p,app1:50:1a:e,app1:50:1b:e,db1:50:1a:i,db1:50:1b:i

这将创建6个子网，其中 Web、APP 和 DB 各2个子网，分布在2个 AZ 中:

1. 运行结果如下:

创建的子网：

内部子网路由表：

外部子网路由表：

假设现在还要创建一个包含16个有效 IP 的公共子网用于部署网络设备，可以再运行一次SubnetAuto.json，输出参数：net1:16:1a:p,net1:16:1b:p
则可以创建出如下子网：

与其他 CloudFormation 模板配合使用，进行 Landing Zone 部署

Landing Zone 中文名称翻译成着陆区，是指 AWS 的基本环境，用户在其上部署安全和运维流程。Landing Zone 的内容包含：账户结构、账户安全基线、网络结构和AWS用户访问管理。下面简单的介绍一下 AWS Landing Zone 的最佳实践。

• 账户结构

AWS 建议账户的划分与企业的组织架构和运维部门的组织架构一致。例如按照如下结构划分账户：

• 账户安全基线

AWS 建议在所有账户内打开 CloudTrail 和 AWS Config 功能。所有日志信息要复制到安全账户内的 S3 存储桶中。建立跨账户访问的 Auditor 角色。

• 网络结构

AWS 建议删除缺省 VPC，建立客户自己定义的 VPC。建立共享 VPC（包含目录服务、邮件服务器等），应用 VPC 与共享 VP C建立 Peer 关系。通过 VPN 或者 Direct Connect 与线下的数据中心建立网络连接，或者采用 Transit VPC（参考 https://aws.amazon.com/answers/networking/aws-global-transit-network/ ，https://aws.amazon.com/blogs/aws/aws-solution-transit-vpc/ ）建立集中的网络控制机制。网络输入输出的安全控制（建立堡垒机，建立 Security Group、网络 ACL 或者第三方的防火墙工具）

• AWS 用户访问管理

包括建议基于 SAML 的单点登录，建立跨账户角色访问机制等。

上述介绍的建立 VPC 和子网的方法可以看成建立 Landing Zone 的基础，在此之上，我们还可以使用 CloudFormation 建立堡垒机，打开 CloudTrail 和 AWS config，建立不同账户间的日志（log）复制机制，建立 Config Rule 进行合规性检查等等。 AWS 已经开发出多个 QuickStart CloudFormation 脚本协助用户完成上述工作，但是这些脚本在中国区（BJS）运行时需要做一些修改。下表列出了一些可用的资源，其中中国区部署模板是我针对中国区的特点修改过的，可以在BJS正常运行。

建立 VPC 并基于参数动态创建子网的 CloudFormation 模板，首发于服务器安全维护工作室。

宏的使用有两个主要步骤。首先，我们需要定义宏。当然，为此我们需要使用 CloudFormation 模板。然后，为了在我们的模板中使用宏，我们需要将它添加为整个模板的转换函数，或者直接调用它。在本博文中，宏和转换函数这两个术语基本可以互换。已经准备好了解其工作原理了？

创建 CloudFormation 宏

宏的创建有两个要素：一是定义，二是实现。如要创建宏的定义，我们需要一个类型为 AWS::CloudFormation::Macro 的 CloudFormation 资源，该资源定义了需要使用的 Lamda 函数以及应当调用的宏。

Type: "AWS::CloudFormation::Macro"
Properties:
  Description: String
  FunctionName: String
  LogGroupName: String
  LogRoleARN: String
  Name: String

宏的 Name 必须在整个区域是唯一的，并且通过 FunctionName 引用的 Lambda 函数必须与要创建的宏位于同一区域。您执行宏模板时，将会使该宏对其他模板也同样可用。宏的实现由 Lambda 函数完成。宏可以位于自己的模板中，也可与其他宏组合，但无法在注册宏的模板中使用该宏。Lambda 函数会收到与以下类似的 JSON 负载：

{
    "region": "us-east-1",
    "accountId": "$ACCOUNT_ID",
    "fragment": { ... },
    "transformId": "$TRANSFORM_ID",
    "params": { ... },
    "requestId": "$REQUEST_ID",
    "templateParameterValues": { ... }
}

负载的 fragment 部分包含了整个模板或者模板的相关区段 — 具体取决于如何从调用宏的模板中调用转换函数。区段始终在 JSON 中，即使模板在 YAML 中亦是如此。

Lambda 函数预计将会返回一个简单的 JSON 应答：

{
    "requestId": "$REQUEST_ID",
    "status": "success",
    "fragment": { ... }
}

requestId 需要输入负载中收到的相同，如果 status 包含除 success（不区分大小写）以外的任何值，则变更集的创建将会失败。然后，fragment 必须包含转换后模板的有效 CloudFormation JSON。即使您的函数未执行任何操作，仍然需要返回它的区段以包含到最终模板中。

使用 CloudFormation 宏

如要使用宏，我们只需使用要求的参数调用Fn::Transform。如果您希望利用宏来对整个模板进行句法分析，则我们可以按照与 SAM: Transform: [Echo] 相同的方式，将其列入模板中的转换函数列表中。在我们执行模板时，通过调用每个宏的制定函数并返回最终模板，转换函数将会被收集到变更集中。

假设我们有一个名为 EchoFunction 的 虚拟 Lambda 函数，它只是记录通过它的数据并返回未加任何修改的区段。我们将宏定义为一种正常的 CloudFormation 资源，与以下类似：

EchoMacro:
  Type: "AWS::CloudFormation::Macro"
  Properties:
    FunctionName: arn:aws:lambda:us-east-1:1234567:function:EchoFunction
	Name: EchoMacro

Lambda 函数的代码可能简单如下：

def lambda_handler(event, context):
    print(event)
    return {
        "requestId": event['requestId'],
        "status": "success",
        "fragment": event["fragment"]
    }

然后在部署此函数并执行宏模板后，我们可以在任何其他模板的顶层的转换函数中调用宏，与以下类似：

AWSTemplateFormatVersion: 2010-09-09 
 Transform: [EchoMacro, AWS::Serverless-2016-10-31]
 Resources:
    FancyTable:
      Type: AWS::Serverless::SimpleTable

CloudFormation 会首先调用我们定义的 Echo 宏，然后调用 AWS::Serverless 转换函数，从而创建模板的变更集。它将按照列表中的顺序执行转换函数中列举的宏。

此外，我们还可以使用内部函数 Fn::Transform 调用宏，该函数允许我们输入额外的参数。例如：

AWSTemplateFormatVersion: 2010-09-09
Resources:
  MyS3Bucket:
    Type: 'AWS::S3::Bucket'
    Fn::Transform:
      Name: EchoMacro
      Parameters:
        Key: Value

内联转换函数将拥有其所有同级节点和下级节点的访问权限。转换函数的处理顺序为由深到浅，这意味着最顶层的转换函数将会最后执行。我知道大多数人都会说：不对，你不能在宏中包含宏 — 但想法不错。

在您执行 CloudFormation 模板时，它将会直接要求您创建一个变更集，并且您可以在部署前预览输出结果。

示例宏

我们正在推出多个参考宏，以帮助开发人员上手，同时我预计许多人也将发布更多的宏。以下四个宏是在此功能发布前，一个小的内部骇客马拉松的优胜作品：

以下是我认为有人可能会感兴趣实现的一些理念：

• 自动注册 R53 域 + AWS Certificate Manager (ACM) 凭证预置
• 自动分配带自定义域的 S3 静态网站或 Amazon CloudFront
• 扩展 CloudFormation 映射以读取 DynamoDB 表
• 自动为 Amazon Virtual Private Cloud 设置 IPv6
• 自动订阅 Webhook 以与 Slack、Twitter、Messenger 集成

如果您有任何奇妙的想法，我非常期待您写出来！

现已推出

CloudFormation Macros 从今天开始已在所有支持 AWS Lambda 的 AWS 区域推出。使用 Macros 不会发生额外的 CloudFormation 费用，这意味着您只需承担正常的 AWS Lambda 函数费用。更多信息请参阅文档。

使用 AWS Lambda 支持的宏扩展 AWS CloudFormation，首发于服务器安全维护工作室。

{
  "type": "AssumedRole",
  "principalId": "AROAJI4AVVEXAMPLE:ROLE-SESSION-NAME",
  "arn": "arn:aws:sts::ACCOUNTNUMBER:assumed-role/ROLE-NAME/ROLE-SESSION-NAME",
  "accountId": "ACCOUNTNUMBER",
  "accessKeyId": "ASIAEXAMPLEKEY",
  "sessionContext": {
    "attributes": {
      "mfaAuthenticated": "false",
      "creationDate": "XXXX-XX-XXTXX:XX:XXZ"
    },
    "sessionIssuer": {
      "type": "Role",
      "principalId": "AROAJI4AVV3EXAMPLEID",
      "arn": "arn:aws:iam::ACCOUNTNUMBER:role/ROLE-NAME",
      "accountId": "ACCOUNTNUBMER",
      "userName": "ROLE-SESSION-NAME"
    }
  }
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::MyExampleBucket",
        "arn:aws:s3:::MyExampleBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "111111111111"
          ]
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::MyExampleBucket",
        "arn:aws:s3:::MyExampleBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "AIDAEXAMPLEID",
            "111111111111"
          ]
        }
      }
    }
  ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::MyExampleBucket"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::MyExampleBucket/*"
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::MyExampleBucket",
                "arn:aws:s3:::MyExampleBucket/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userId": [
                        "AROAEXAMPLEID:*",
                        "111111111111"
                    ]
                }
            }
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
            },
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::MyExampleBucket"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::MyExampleBucket/*"
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::MyExampleBucket",
                "arn:aws:s3:::MyExampleBucket/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userId": [
                        "AROAEXAMPLEID:*",
                        "111111111111"
                    ]
                }
            }
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": [
                {
                    "AWS": [
                        "arn:aws:iam::222222222222:role/ROLENAME",
                        "arn:aws:iam::222222222222:user/USERNAME"
                    ]
                }
            ],
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::MyExampleBucket"
        },
        {
            "Effect": "Allow",
            "Principal": [
                {
                    "AWS": [
                        "arn:aws:iam::222222222222:role/ROLENAME",
                        "arn:aws:iam::222222222222:user/USERNAME"
                    ]
                }
            ],
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::MyExampleBucket/*"
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::MyExampleBucket",
                "arn:aws:s3:::MyExampleBucket/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userId": [
                        "AROAEXAMPLEID:*",
                        "AIDAEXAMPLEID",
                        "111111111111"
                    ]
                }
            }
        }
    ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::MyExampleBucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::MyExampleBucket/*"
    }
  ]
}

将亚马逊 AWS S3 存储桶的访问权限到一个特定 IAM 角色，首发于服务器安全维护工作室。

背景

随着移动互联网的发展，越来越多的图片分享、短视频、在线直播等应用越来越火，如何安全、经济高效、低延迟的将内容分发到终端用户受到开发者越来越多的关注。内容分发网络（CDN）是为解决互联网访问拥塞的问题而生，通过使用大量更靠近终端用户的边缘节点向终端用户提供服务以加速内容的分发，因此在应用系统前端部署 CDN 成为内容加速分发的不二选择。

一、什么是 Amazon CloudFront

Amazon CloudFront 是一种全球内容分发网络服务，可以安全地以低延迟和高传输速度向浏览者分发数据、视频、应用程序和 API。CloudFront 与 AWS  与多种 AWS 产品集成，如用于 DDoS 缓解的 AWS Shield、应用程序防火墙 AWS WAF、 Amazon S3、 Elastic Load Balancing、 Amazon EC2 以及 Amazon Route 53，以及可在 AWS 全球基础设施运行用户代码的 Lambda@Edge。

截止目前（2018年7月），Amazon CloudFront 在26个国家/地区的59个城市中设有131个接入点（121个边缘站点和11个区域性边缘缓存站点）。

举例说明，当客户端发起对 www.customer.com 的访问时，首先需要 DNS系统解析出该域名对应的主机 IP，通过本地 ISP DNS 递归查询到 customer.com 的 DNS 域名服务器并了解到该域名是指向了 xxx.cloudfront.net，进一步解析 xxx.cloudfront.net，CloudFront 的 DNS 域名服务器会根据请求来源的 IP 等信息，返回适合当前该客户端访问的边缘节点的主机 IP 如1.1.1.1，最终该客户端向1.1.1.1发出请求。如果该边缘节点已经缓存了该客户端请求的内容（图片、视频等静态文件），则直接返回给客户端，如果未缓存，则首先回源取回该内容，并存储在边缘节点，以便下次客户端对该内容请求时可以直接返回该内容。

更好的 CDN 性能表现带来更多的访问流量，以及更好的用户体验，下面我们将介绍如何配置以及优化建议。

二、如何配置 CloudFront Distribution

下面介绍下如何为自己的应用配置 CloudFront，实现网站访问加速。

在开始之前，首先简单介绍下 CloudFront的常见术语。

Distribution：分配是 CloudFront 的基本单元，每个分配有独一的 ID 以及CloudFront 为其分配的域名（类似 abcdefg13456789.cloudfront.net）。目前有 Web 和 RTMP 两种方式的分配， Web 分配主要用于分发静态、动态内容，基于 HTTP/s 协议的媒体文件分发，基于 HLS 协议的互联网直播等。 RTMP 分配主要用于基于 RTMP 协议的视频点播场景，源站必须为 S3 存储桶。本文以 Web 分配为例。

Origin： 源站，顾名思义，是加速的站点，可以是 S3 存储桶，可以是 ELB/EC2，可以是 Elemental MediaStore/MediaPackage，或者是用户自定义的站点（如第三方 IDC 中的 HTTP Web 服务器）。一个分配中可以有多个源站。

Behaviors：行为， CloudFront 通过路径匹配的方式决定执行哪一个缓存行为，一个分配中可以有多个 Behaviors，并且每个 Behaviors 对应一个源站。在 Behaviors 中可以设置缓存 TTL 时间，允许的 HTTP 行为（GET，PUT，POST 等），与 Lambda 关联等等。

本节将涉及如下内容：

1. 创建一个分配；
2. 该分配有两个源站，其中一个是创建时添加，一个是后添加。一个源站为ELB，一个源站为 S3 存储桶；
3. 两个 Behaviors，一个是默认 Behaviors 并对应回源 ELB，一个是新加Behaviors 并对应源站 S3 存储桶；
4. ELB，S3 创建过程不做介绍；

1、进入 CloudFront console，并选择新建 Distribution，选择 Web Distribution。

2、源站设置

部分解释如下：

由上可见，是否缓存、缓存多久跟是否转发 Header、Cookie、Query string也有关联，如何提高缓存的命中率以提高访问性能，可见https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html 。

点击创建后，来到 Distribution 的列表页面，可以看到 Status 的状态是“In Process”，大概10分钟左右该状态是“Deployed”时，则表示该分配创建完成，可以使用，并且可见 CloudFront 为其分配的域名。

3、添加源站

点击分配的 ID，可见当前分配的相关设置。

点击 Origin，可见当前的 Origin 配置，点击 Create Origin，可以添加源站。

此时我们添加一个 S3 桶为源站。

注意选择 S3 桶为源站时，会出现是否“Restrict Bucket Access”的选项，我们知道 S3 通过 ACL 和 Bucket Policy 控制存储桶的对象是否被公开访问，因此该 S3 存储桶需要允许 CloudFront 能够从 S3 存储桶拉取对象，这儿有两种方式，一个是该桶设置为公开访问桶，任何人可以直接从该桶下载；方式二是使用 OAI（Origin Access Identity），即该分配获取一个 OAI，并且在 S3 bucket policy 中的 principle 部分填写该 OAI，这样该 S3 存储桶将仅向该分配开放了相应的权限，而其他人无法直接从该存储桶下载资源。

建议选择“Yes, Update Bucket Policy”以避免 Bucket Policy 配置错误^[2]。

4、添加 Behavior

同样进入分配后，在 Behavior 栏选择 Create Behavior。我们假定访问 jpg图片的请求，回源到前面创建的 S3 存储桶。

Path Pattern 中支持通配符，在此处配置路径模式，即当一个请求到达CloudFront POP 点，CloudFront 检查该请求的 URL 路径，并与 Behavior 中设置的进行匹配，按先匹配到的 Behavior 的配置执行对应的行为。

Origin 栏可以选择该分配中已添加的源站。

当拥有多个 Behavior 时，若路径模式中有重合，可以通过 Move Up/Down调整匹配的顺序，一旦匹配到将按该 Behavior 执行，不再去匹配其他 Behavior。优先级 Precedence 数字越小越优先匹配。

三、缓存优化

本节将介绍常见的 TTL 设置建议、动态加速，设置样例以及错误处理。

1、TTL 设置建议

CloudFront 在计算 Cache key 时会将请求的 URL 以及当前分配对应的Behavior 的配置（如是否转发 Header、Cookie、查询字符串）考虑在内，计算出唯一值。因此即使两次请求都是相同的 URL，如果两次请求的个别 Header 不一样，且该 Header 配置为了转发（Cached based on Selected Headers），则计算出的 Cache key 也不同，返回给客户端的内容自然也不同。因此配置转发的查询字符串、Cookie 及 Header 越少，Cache key 也将越少，缓存命中率就越高，带来了性能也越好。

对于用户内容在 PoP 点的缓存 TTL，可以使用源站设置的 Cache Control: max-age 的值，或者在 Behavior 中使用 Customized 设置 Minimum TTL，Maximum TTL、Default TTL（https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/Expiration.html ）。

对于动态内容，动态加速场景，可以在源站设置：

Cache-Control: no-cache; max-age=0; No-store; private

或 Cache-Control: public; max-age=0;

若使用 CloudFront Behavior 中 Customize TTL，可以直接在‘Cache based on Selected Header’处选‘All’，然后 Minimum TTL，Maximum TTL，Default TTL 均设置为0.

对于 Cache-Control Header 设置样例：

2、错误处理

当源站不可用时，可以在 CloudFront 配置针对400，403，404，405，414，500，501，502，503，504等错误码的自定义响应页并修改返回给客户端的响应码。CloudFront 将周期性验证源站的可用性，并可在源站恢复前将当前缓存中的内容作为响应返回给客户端。

设置方式可见https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html

四、内容更新

当源站静态内容更新时，如何让客户端在 TTL 失效时间前即可拿到最新版本的内容是每一位开发者关心的问题，在 CloudFront 有两种方式。

1、版本号控制

当已发布的内容更新时，可在文件名或者路径中使用版本号进行区分，比如从 v1 到 v2，或者时间戳等可以区别同一对象两种版本的其他方法，同时应用测对资源链接指向新版本号的资源。

2、使用 Invalidation 使缓存中的文件失效

CloudFront 提供一个名为‘Invalidation’的功能，可以使文件在 TTL 失效时间到达前将文件从 PoP 点删除，使用该功能可以快速的在文件名不变的前提下将文件更新。

Invalidation 支持指定单个文件或者以*通配符结尾的路径。限制及费用见https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

五、监控与日志

CloudFront 提供多种报告供用户了解自己分配的使用率等情况，您可以使用 CloudWatch API 获取分配的相应监控指标，需要注意的是，使用 CloudWatch API 时 region 应设置为 us-east-1。

CloudFront 报告提供按天或按小时的请求数、数据传输、HTTP Status Code、Top50 访问的对象，使用率以及按设备、浏览器、操作系统、客户端位置等指标的报告，同时可以配置 CloudWatch 警报，对关键指标数据进行监控（请求数、已下载字节、已上传字节、总错误率、4xx错误率、5xx错误率），一旦超过正常阈值，运维人员可第一时间得到告警。

尽管 CloudFront 提供了多维度的报告，但可能仍不能满足用户的多维度分析的需求。因此推荐这类用户对 CloudFront 日志进行分析，当用户开启 CloudFront 分配日志后，日志将会上传到指定的 S3 存储桶，通过分析日志可以了解有关该分配的更多的客户端请求行为，有助于做运营分析或者 debug。关于日志字段解释见https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html 用户可以使用 Amazon EMR 或者无服务器交互式查询服务Amazon Athena轻松的使用标准 SQL 直接在 S3 中分析数据，并与 Amazon QuickSight  集成，轻松实现数据可视化。

使用 Amazon Athena 查询  Amazon CloudFront  日志方式见https://docs.aws.amazon.com/zh_cn/athena/latest/ug/cloudfront-logs.html

使用 Amazon EMR 分析 CloudFront 日志可见参考资料8。

六、合规与安全

CloudFront 目前已经获得 PCI DSS 合规，GDPR（https://amazonaws-china.com/compliance/gdpr-center/service-capabilities/ ）、HIPPA、SOC 以及 ISO 9001, 27001, 27017, 27018 等合规认证。

同时开启 CloudTrail，用户帐号下所有的 CloudFront API 调用记录将均被CloudTrail 记录，便于用户后期审计。

下面我们将从4个方面进行介绍 CloudFront 如何保证您的内容安全。

1、回源保护

我们可以将源站设置为仅允许 CloudFront 访问，而拒绝客户端的直接回源。

当源站为 ELB/EC2 时：

（1）ELB/EC2 的安全组仅对 CloudFront 节点 IP 开放对应的端口（80/443），CloudFront 节点服务器的 IP 地址范围见：

https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html

（2）在 CloudFront Origin 设置时，添加自定义 Header 字段及值，源站对请求中的字段检查，若不含有该 Header 字段及值，则返回错误码。

（3）回源 HTTPS

回源支持 TLSv1.1、TLSv1.2 安全协议以及 RSA，ECDSA 两类密码算法。

当源站为 S3 存储桶时：

在 S3 存储桶策略中应用 OAI，仅允许带该 OAI 的 CloudFront 分配从存储桶中获取内容。

https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

2、传输安全

CloudFront 支持客户端到 PoP 点使用 HTTPS 请求，CloudFront 为每个分配生成的域名支持 HTTPS 请求，并支持用户上传自己从可信 CA 购买的证书。用户可以在 Amazon ACM 服务免费申请自己域名的证书，需要注意的是，需要在 us-east-1 区的 ACM 服务申请，才能应用到 CloudFront 的分配。

对于用户域名证书，CloudFront 支持专属 IP 和 SNI 两种方式。

3、内容保护

（1）签名 URL、签名 Cookie

针对有些内容限制访问的情景，如仅允许付费用户或者授权用户访问的内容，我们可以通过签名 URL 或签名 Cookie 的方式提供内容的私有化访问。文档中已有非常详细的说明，在此不再展开，具体方式见：https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html 另外也可见参考资料[3]。

（2）Field-Level Encryption 字段级加密

2017年12月份，CloudFront 推出了该功能，使用该功能，可以进一步增强敏感数据 (如信用卡号码或个人身份信息) 的安全性。在将  POST  请求转发到您的源站之前，CloudFront 的字段级加密使用特定于字段的加密密钥 (由用户提供) 对  HTTPS  表单中的敏感数据进行进一步加密。这可确保敏感数据只能被应用程序堆栈中的某些组件或服务解密和查看。

配置方式见：https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html

（3）Geo 限制

CloudFront 提供了基于地理位置访问限制的功能，用户可以通过设置白名单或者黑名单的方式，允许或禁止某个国家或地区对自己分配的访问。

4、与 AWS WAF、Shield 集成

AWS WAF 是一款 Web 应用程序防火墙，帮助保护您的 Web 应用程序免受常见 Web 漏洞的攻击[5]。AWS Shield 是一种托管式分布式拒绝服务 (DDoS)防护服务，可以保护在 AWS 上运行的防护应用程序 [7]。

用户可以在创建 CloudFront 分配时关联已创建的 WAF，或者在 WAF Console 创建完 WAF 规则后与 CloudFront 分配关联。

七、可编程 CDN

AWS在2017年7月正式推出了 Lambda@Edge，借助  Lambda@Edge，用户可以轻松在 AWS 的全球基础设施上运行代码，从而以最低的延迟响应最终用户。代码可以由  Amazon CloudFront  事件触发，例如源服务器和浏览者之间的内容请求或响应。您只需将 Node.js代码上传到 AWS Lambda，Lambda 就能在靠近最终用户的 AWS 站点实现高可用性，提供复制、路由和扩展代码所需的一切。

我们将在下一篇中对 Lambda@Edge进行讲解与使用案例分享，感兴趣的读者可以查看官方文档进一步的了解：https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html

参考资料

全站加速，Amazon CloudFront 配置，首发于服务器安全维护工作室。

Amazon ECS 是一种容器管理服务，可以很方便地运行、停止和管理群集上的 Docker 容器。当使用 ECS 运行容器任务时，会将它们放置在 ECS 群集上。Amazon ECS 从指定的映像存储库中，下载指定的容器映像，并在集群中的容器实例上运行这些映像所承载的任务。

我的同事 Chris Barclay 发了一篇很不错的博客文章，介绍了在 Auto Scaling 组缩小 ECS 集群之前，使用容器实例耗尽的方法，自动化地删除正在进行的容器实例。

根据多个实际的客户案例，需要从 Amazon ECS 群集中终止实例的应用场景很多且重要， 例如： EC2 AMI 的升级和更新，执行系统关键升级补丁，系统核心组库的更新，Docker 软件版本的升级和更新，ECS 代理的版本升级和更新，集群大小的变更等等。

解决方案

通常而言，这些应用场景，都有一个共同的目标就是当容器实例的终止时，或从集群中删除容器实例时，不会影响集群中正在进行的任务，也就是说，阻止将新任务安排在处于 DRAINING 状态的容器实例上，如果资源可用（或预先起动新的容器实例），则新任务分配到 ECS 集群中的其他容器实例，待终止的容器实例上正在运行的任务，等其成功迁移到其他容器实例后，终止实例。实战中，亦可手动修改容器实例的状态为 DRAINING。本文中，我们将展示如何实现对集群任务最小影响的 ECS 容器实例自动化终止方案，其中会需要使用Auto Scaling组的生命周期挂钩以及 Amazon Lambda 提供的无服务函数调用，如下图所示：

Auto Scaling 组支持可调用的生命周期挂钩，例如：Lambda 函数，以允许其在实例启动或终止之前完成，此例为实例终止之前。生命周期挂钩调用的 Lambda 函数完成以下两个任务：

1. 将 ECS 容器实例状态设置为 DRAINING。
2. 检查容器实例上是否存在任何正在进行的任务。 如有则会向 SNS 发布消息，再次调用该 Lambda 函数进行检查。

该 Lambda 函数会重复执行第2步，直到容器实例上没有任何正在运行的任务，或者生命周期挂钩心跳超时，以先发生者为准。 之后，控制权返回到 Auto Scaling 生命周期挂钩，终止容器实例。

参考示例

要实现上述自动化容器实例终止方案，可参考开源的 CloudFormation 模板，以及 S3 存储桶中上传 Lambda 部署软件包，设置本文中描述的资源。该模板创建以下资源：

• VPC 和关联的网络元素（子网，安全组，路由表等）
• ECS 群集，ECS 服务和示例 ECS 任务定义
• 具有两个 EC2 实例和包含生命周期终止挂钩的 Auto Scaling 组
• Lambda 函数
• SNS 话题
• 能执行 Lambda 函数的 IAM 角色

鉴于中国区有关 Auto Scaling 组的可信任实体和全球的命名方式有所区别，因此可参考这里的修改方法，对 CloudFormation 模板进行配置和更改。

创建 CloudFormation 堆栈，我们可以通过触发实例终止事件，来了解这是如何工作的：

• 在 Amazon EC2 控制台中 ，选择 Auto Scaling Groups 并选择由 CloudFormation 创建的 Auto Scaling 组的名称。
• 选择操作 ， 编辑并更新服务，将实例的数量减少1个。

这将触发一个实例的终止过程。选择 Auto Scaling 组实例选项卡：实例状态值应显示生命周期状态：

此时，生命周期挂钩被激活并向 SNS 发布消息，最终触发 Lambda 函数的响应和执行。之后， Lambda 函数将 ECS 容器实例状态更改为 DRAINING。ECS 服务介入调度，停止实例上的任务并在可用实例上启动该任务。

任务完成后，Auto Scaling 组活动历史记录确认 EC2 实例已终止。

深入分析

我们来深入分析一下 Lambda 函数内部的工作原理。该函数首先检查，收到的事件中的 LifecycleTransition 值是否为 EC2_INSTANCE_TERMINATING，表示当前已经进入生命周期挂钩的终止状态之前。

 # If the event received is instance terminating...
if 'LifecycleTransition' in message.keys():
    print("message autoscaling {}".format(message['LifecycleTransition']))
if message['LifecycleTransition'].find('autoscaling:EC2_INSTANCE_TERMINATING') > -1:

继续调用函数 “checkContainerInstanceTaskStatus”。该函数根据容器实例的 ID，将容器实例状态设置为 ‘DRAINING’。

# Get lifecycle hook name
lifecycleHookName = message['LifecycleHookName']
print("Setting lifecycle hook name {} ".format(lifecycleHookName))

# Check if there are any tasks running on the instance
tasksRunning = checkContainerInstanceTaskStatus(Ec2InstanceId)

然后，检查实例上是否有任务正在运行。如有任务正在运行，则向 SNS 发布消息以再次触发 Lambda 函数后退出。

# Use Task ARNs to get describe tasks
descTaskResp = ecsClient.describe_tasks(cluster=clusterName, tasks=listTaskResp['taskArns'])
for key in descTaskResp['tasks']:
 print("Task status {}".format(key['lastStatus']))
 print("Container instance ARN {}".format(key['containerInstanceArn']))
 print("Task ARN {}".format(key['taskArn']))

# Check if any tasks are running
if len(descTaskResp['tasks']) > 0:
 print("Tasks are still running..")
 return 1
else:
 print("NO tasks are on this instance {}..".format(Ec2InstanceId))
 return 0

继续执行的 Lambda 函数，发现容器实例上没有运行的任务时，则继续完成生命周期挂钩并终止 EC2 实例。

#Complete lifecycle hook.
try:
 response = asgClient.complete_lifecycle_action(
 LifecycleHookName=lifecycleHookName,
 AutoScalingGroupName=asgGroupName,
 LifecycleActionResult='CONTINUE',
 InstanceId=Ec2InstanceId)
 print("Response = {}".format(response))
 print("Completedlifecycle hook action")
except Exception, e:
 print(str(e)) 

结论

本文讨论了 ECS 容器实例终止的多种应用场景，提供了对集群任务最小影响的 ECS 容器实例自动化终止方案，并通过参考示例展示和深入分析了其工作原理。基于参考示例，可以使用 CloudFormation，Lambda 等服务，实现真正的滚动部署 ，先启动新实例并批量终止实例，同时保证对现有的集群任务带来最小影响。要了解有关容器实例耗尽的更多信息，请参阅 Amazon ECS 开发人员指南 。

如何实现对集群任务最小影响的 ECS 容器实例自动化终止方案，首发于服务器安全维护工作室。

Amazon Polly 是一项将文本转换为逼真语音的服务，让您可以构建支持聊天功能的应用程序，从而打造全新类别的具有语音功能的产品。它使用深度学习技术来合成类似于人声的语音。该服务提供了不同语言的各种语音。

对于外出的企业 IT 安全人员，有关 AWS 账户安全事件的电话呼叫警报可以带来极大的帮助。这些安全事件可以根据事件的严重性和优先级进行自定义。严重性和优先级较高的安全事件可以发送到通过电话呼叫报警的系统中。

对于电话呼叫报警，我会使用 Twilio，它提供了 API 功能，例如语音、视频和消息传送。当给定 AWS 账户中发生安全事件时，使用 Twilio 的平台能够以编程方式发布 API 调用，用于进行电话呼叫。Amazon Polly 将此文本警报转换为在电话呼叫上播放的语音消息。

解决方案概述

该解决方案包括两个系统，如以下架构图所示：

• 事件检测和通知系统
• 文本到语音转换系统

事件检测和通知系统与文本到语音转换系统彼此分离，这是因为后一个系统对用户定义的任何其他事件检测通用。在此博客帖子中，作为解决方案示例，我重点介绍文本到语音转换系统，并使用来自我之前博客帖子中介绍的事件检测和通知系统。

如架构图中所示。步骤 3 的警报消息发布到 Amazon SNS 主题，该 SNS 触发我们文本到语音转换系统中的 Lambda 函数。

1. 此 Lambda 函数解析 SNS 警报消息的主题，并使用 Amazon Polly 将文本转换为语音文件。
2. 此语音文件存储在 Amazon S3 存储桶中。
3. Twilio 使用语音文件的位置，对相关方进行出站呼叫并播放语音文件。请注意，您可以根据在使用语音文件进行出站呼叫之后的需求，为这些文件添加 Amazon S3 对象生命周期策略。

演示

先决条件

• 至少有一个事件检测和通知系统。例如，您可以设置对 AWS 账户根用户活动进行监视和通知
• 您将需要 Twilio 账户身份验证令牌来进行 API 调用。您可在此处注册免费 (试用) Twilio 账户。
• 会向您的 Twilio 账户分配一个电话号码。这是您接听电话呼叫报警时的主叫号码。
  
• 如果您使用的是试用账户，则需要确保对“被叫”电话号码进行验证。
  

部署步骤

以下部署步骤将部署“文本到语音转换”系统，如下图中所示。

1. 在 AWS CloudFormation 控制台中，选择 Create Stack。使用 CloudFormation JSON 模板 。选择 Next。(注意：中国和 AWS GovCloud (美国) 区域不支持 Amazon Polly。)
2. 在要部署事件检测和通知系统的区域中创建堆栈。
3. 输入以下参数详细信息，选择 Next，然后选择 Next：
   1. ToPhoneNo：Twilio 将拨打的电话号码。在电话号码前面加上“+国家/地区代码”，例如 +14561237890。
   2. FromPhoneNo：Twilio 进行呼叫时所用的虚拟电话号码。在您的 Twilio 账户中可以找到此信息。请参阅“先决条件”部分。
   3. TwilioAccntSid：输入 Twilio 账户 SID。当您在 https://www.twilio.com/ 上注册时提供此项
   4. TwilioAuthToken：输入 Twilio 身份验证令牌 ID。
   5. BucketName：输入您要创建的存储桶的名称。此存储桶将存储事件警报的语音文件。
   6. PollyVoiceId：输入您希望呼入警报的 Amazon Polly 语音。默认语音为“Amy”。
   7. LambdaS3Bucket：存储 Lambda 函数 zip 文件的 Amazon S3 存储桶的名称。
   8. LambdaS3Key：Lambda 函数 zip 文件的名称。这是 S3 对象的完整路径，带有前缀。例如，“dir1/dir2/lambdafunction.zip”。Lambda 函数 zip 文件可以从此博客帖子的 Lambda 函数部分中的链接下载。
4. 依次选择 Capabilities Acknowledgement 和 Create。此字段向堆栈提供权限来创建 IAM 角色和策略。这些角色和策略由 Lambda 函数用于执行特定操作，例如发布消息到 SNS 主题、列出账户别名等等。
5. CloudFormation 堆栈完成之后，检查 output 中提供的 Lambda 函数名
6. 现在，我们将触发器添加到此 Lambda 函数。转到 Lambda 控制台并选择刚刚创建的 Lambda 函数，然后选择 triggers 和 add trigger。
7. 在触发器框中，选择 SNS，并选择您希望用于电话呼叫的“事件检测和通知”系统的 SNS 主题。选择 Submit。
   
8. 现在，Lambda 函数已准备好，可由您的“事件检测和通知”系统的 SNS 主题触发。您可以根据需要，为各种事件检测和通知系统添加任意数量的触发器。在此处可以找到有关触发 AWS Lambda 的更多信息。

SNS 触发 Lambda 函数

在触发时，文本语音转换 Lambda 函数会解析 SNS 消息的主题。然后，它将此主题字段文本传递到 Amazon Polly 服务以将其转换为语音文件。将文本转换为语音文件之后，该文件存储在前一部分中由 CloudFormation 堆栈创建的 S3 存储桶内。

然后，它调用 Twilio API 进行电话呼叫，并播放来自 S3 存储桶的事件通知音频文件。

import boto3
import os
from contextlib import closing
import botocore.session
from botocore.exceptions import ClientError
session = botocore.session.get_session()
import logging
import uuid
import twilio
from twilio.rest import Client

import urllib
from urllib import request, parse
from urllib.parse import quote

logging.basicConfig(level=logging.DEBUG)
logger=logging.getLogger(__name__)

def lambda_handler(event, context):
    logger.setLevel(logging.DEBUG)
    logger.debug("Event is --- %s" %event)
    speak = event["Records"][0]["Sns"]["Subject"]
	
	# 将 SNS 消息的主题文本转换为 mp3 语音文件。
	
    polly = boto3.client('polly')
    response = polly.synthesize_speech( OutputFormat='mp3',
                                        Text = 'ALERT !' + speak,
                                        SampleRate='22050',
                                        VoiceId = os.environ['VoiceId']  
                                        )
    logger.debug("Polly Response is-- %s" %response)
    id = str(uuid.uuid4())
    logger.debug("ID= %s" %id)
    
    
    # 将 Amazon Polly 返回的语音流保存到 Lambda 的临时
    # 目录。如果有多个文本块，语音流
    # 将合并为单个文件。
    if "AudioStream" in response:
        with closing(response["AudioStream"]) as stream:
            filename=id + ".mp3"
            output = os.path.join("/tmp/",filename)
            with open(output, "wb") as file:
                file.write(stream.read())
	
	# 将语音 MP3 文件上传到 S3位置
	
    s3 = boto3.client('s3')
    s3upload_response = s3.upload_file('/tmp/' + filename, os.environ['BUCKET_NAME'],filename,ExtraArgs={"ContentType": "audio/mp3"})
    logger.debug("S3 UPLOAD RESPONSE IS--- %s" %s3upload_response)
    s3.put_object_acl(ACL='public-read', Bucket=os.environ['BUCKET_NAME'], Key= filename)
    
    location = s3.get_bucket_location(Bucket=os.environ['BUCKET_NAME'])
    logger.debug("Location response is -- %s" %location)
    region = location['LocationConstraint']
    
    if region is None:
    	url_begining = "https://s3.amazonaws.com/"
    else:
    	url = url_begining + str(os.environ['BUCKET_NAME']) + "/" + filename
    
    url = '{}/{}/{}'.format(s3.meta.endpoint_url, os.environ['BUCKET_NAME'], filename)
    
    #编码 URL
    encode_url = quote(url, safe='')
    logger.debug("ENCODED URL-- %s" %encode_url)
    
    # 从 http://twilio.com/user/account 获取这些凭证
    account_sid = os.environ['account_sid']
    auth_token = os.environ['auth_token']
    client = Client(account_sid, auth_token)
    
    # 使用 Twilio 进行电话呼叫
    call_response = client.api.account.calls.create(to=os.environ['ToPhoneNo'],  # 任意电话号码
    												from_=os.environ['FromPhoneNo'], # 必须是有效的 Twilio 号码
    												url="http://twimlets.com/message?Message%5B0%5D=" + encode_url + "&"
    												)
    												
    logger.debug("Call_response is-- %s" %call_response)

此 AWS Lambda 代码 zip 文件可从此处下载并用于 CloudFormation 堆栈部署。

解决方案验证

在接下来的示例语音中，我将演示在部署事件检测系统 (就根 API 活动进行通知) 并将其集成到文本到语音转换系统之后，每次在 AWS 账户上检测到根 API 时，我将收到电话呼叫报警。

由根触发的控制台登录警报电话呼叫示例：

立即收听 语音由 Amazon Polly 提供

然后，我使用根凭证创建 Amazon EBS 卷并获取另一个电话呼叫警报。

立即收听 语音由 Amazon Polly 提供

结论

在这篇帖子中，我演示了如何创建电话呼叫音频警报系统，该系统可集成到现有的警报和监视系统中。针对 AWS 账户中的关键事件，此框架在获取近乎实时的电话呼叫警报方面非常有用。

如需进一步了解，建议阅读以下内容：

• 使用 Amazon Polly 构建您自己的文本到语音应用程序
• 对 AWS 账户根用户活动进行监视和通知
• 在 AWS CloudTrail 中监视更改和自动启用日志记录

使用 Amazon Polly 针对 AWS 账户安全事件进行电话呼叫报警，首发于服务器安全维护工作室。

Amazon GuardDuty 应运而生。通过各种公开的和 AWS 生成的数据源，在机器学习的大力支持下，GuardDuty 分析了数十亿个事件，追踪趋势、模式和异常，在其中识别暗藏潜在风险的蛛丝马迹。您可以通过一次单击来启用它，并在数分钟内即可查看前几项结果。

工作原理
GuardDuty 处理能力强大，可使用多个数据流，其中包括多个威胁情报源，保持对恶意 IP 地址和生僻域的了解；更重要的是，它会学习如何准确地识别 AWS 账户中恶意或未经授权的行为。结合从您的 VPC Flow Logs、AWS CloudTrail Event Logs 和 DNS 日志中收集的信息，GuardDuty 能够检测许多不同类型的危险和有害行为，包括探测已知漏洞、端口扫描和探测，以及来自不寻常位置的访问。在 AWS 方面，它会查找可疑的 AWS 账户活动，例如未经授权的部署、异常的 CloudTrail 活动、AWS API 函数访问模式以及超出多个服务限制的尝试。GuardDuty 还将查找与恶意实体或服务进行通信的受损 EC2 实例、数据泄漏尝试以及正在进行加密货币挖矿的实例。

GuardDuty 完全在 AWS 基础设施上运行，不会影响工作负载的性能或可靠性。您不需要安装或管理任何代理、传感器或网络设备。这个纯净的零占用空间模型应该对您的安全团队有很大吸引力，可以让他们不假思索地批准在所有 AWS 账户中使用 GuardDuty。

结果按照三个级别 (低、中或高) 之一呈现给您，并附有详细的证据和修复建议。这些结果还作为 Amazon CloudWatch Events 提供；这样您可以使用自己的 AWS Lambda 函数自动修复特定类型的问题。利用这种机制，您还可以轻松地将 GuardDuty 结果推送到事件管理系统 (例如 Splunk、Sumo Logic 和 PagerDuty) 以及工作流系统 (例如 JIRA、ServiceNow 和 Slack)。

快速指南
让我们快速看一下。我打开 GuardDuty 控制台，然后单击 Get started：

然后，我确认我希望启用 GuardDuty。通过单击“Enable GuardDuty”，授予它相应权限以设置合适的服务相关角色和分析我的日志：

我自己的 AWS 环境无法完全展现其功能，所以我访问 General Settings，然后单击 Generate sample findings 继续。现在我得到一些有趣的结果：

我可以单击某个结果来了解更多信息：

使用放大镜图标，我可以为关联的资源、操作或其他值创建包含或排除筛选条件。我可以筛选与此实例相关的所有结果：

通过添加我的环境特有的可信 IP 地址列表和恶意 IP 地址列表，我可以自定义 GuardDuty：

在我的管理员账户中启用 GuardDuty 后，我可以邀请我的其他账户参与：

一旦这些账户决定参与，GuardDuty 将安排将他们的结果与管理员账户共享。

由于时间和篇幅的关系，我只是简要介绍了 GuardDuty 的一些皮毛。您可以免费试用 30 天时间；之后，将根据从您的 VPC Flow、CloudTrail 和 DNS 日志处理的条目数量向您收费。

现已推出
Amazon GuardDuty 现已在以下区域中正式推出：美国东部 (弗吉尼亚北部)、美国东部 (俄亥俄)、美国西部 (俄勒冈)、美国东部 (弗吉尼亚北部)、欧洲 (爱尔兰)、欧洲 (法兰克福)、欧洲 (伦敦)、南美洲 (圣保罗)、加拿大 (中部)、亚太区域 (东京)、亚太区域 (首尔)、亚太区域 (新加坡)、亚太区域 (悉尼) 和亚太区域 (孟买)，您可以立即开始使用！

Amazon GuardDuty – 持续安全监控和威胁检测，首发于服务器安全维护工作室。