服务范围：站点部署，网站部署，网站设置，数据库设置 ，防火墙设置，系统配置，DEDECMS，帝国等开源模板导数据前配置，安全组设置，安全策略设置，服务器设置，80端口配置及设置，开启或关闭端口。

服务说明	价格
网站设置： 1、开源网站设置，及其它网站设置。	100元/个
网站/程序/服务器/应用部署： 1、部署网站、程序、服务器、应用等。 2、配置网站、程序、服务器、应用等。	200元/个
数据库设置： 1、数据库安全设置。 2、数据库应用设置等。 3、数据库性能调优。	200元/次
防火墙设置： 1、第三方防火墙设置。 2、服务器防火墙设置，安全组设置，安全规则设置等。	200元/次
系统设置： 1、系统安全设置，环境要求设置等。 2、80端口配置及其它端口配置等。	100元/次
端口配置及设置： 1、如：80端口配置，或其它指定端口配置。 2、开启或关闭指定端口。	200元/次
备注： 1、如果您无法确认或者需要更多服务，可以联系工作人员交流。 2、交付时间：1天内（通常2小时）

万能配置(网站_服务器_数据库_安全组及端口_系统配置及设置_ftp)，首发于服务器安全维护工作室。

产品亮点

网站搬家_服务器搬家_网站/服务器迁移，首发于服务器安全维护工作室。

在大型企业云迁移项目组，经常会遇到企业将线下数据中心的子网迁移到 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，首发于服务器安全维护工作室。

在本文中，我们将向您展示如何使用 AWS Config 监控 Amazon Simple Storage Service (S3) 存储桶 ACL 和策略，确定是否存在允许公开读写访问权限的违规行为。如果 AWS Config 发现违反策略的行为，我们会使其触发 Amazon CloudWatch Event 规则以触发 AWS Lambda 函数，从而更正 S3 存储桶 ACL，或通过 Amazon Simple Notification Service (Amazon SNS) 通知您存在违反策略且允许公开读写访问权限的行为。我们将通过五个主要步骤为您演示此过程。

1. 启用 AWS Config 来监控 Amazon S3 存储桶 ACL 和策略，以发现违规行为。
2. 创建 IAM 角色和策略，为 Lambda 函数授予读取 S3 存储桶策略和通过 SNS 发送提醒的权限。
3. 创建和配置 CloudWatch Events 规则，在 AWS Config 检测到违反 S3 存储桶 ACL 或策略的行为时触发 Lambda 函数。
4. 创建 Lambda 函数，以使用 IAM 角色审核 S3 存储桶 ACL 和策略、更正 ACL，并通知您的团队策略违规行为。
5. 验证监控解决方案。

注意：本文假设您的合规性策略要求您所监控的存储桶不允许公开读写访问权限。例如，如果您打算开放提供静态内容的存储桶，可以从本文着手，根据您的需要定制解决方案。

在本文末尾，我们将提供一个可实施本文所述解决方案的 AWS CloudFormation 模板。您可以使用该模板在多个区域快速部署解决方案。

重要说明：如果使用部署的某些资源（包括使用所提供的 CloudFormation 模板部署的资源），则在使用这些资源期间会产生费用。在提供 AWS Config 规则的每个区域使用这些规则都会产生费用。

架构

以下是我们将要实施的架构图：

步骤 1：启用 AWS Config 和 Amazon S3 存储桶监控功能

以下步骤将演示如何设置 AWS Config 来监控 Amazon S3 存储桶。

1. 登录 AWS 管理控制台，并打开AWS Config 控制台。
2. 如果这是您第一次使用 AWS Config，请选择开始使用。如果您已经使用过 AWS Config，请选择设置。
3. 在设置页面中的 Resource types to record (要记录的资源类型) 下，取消选中 All resources (所有资源) 复选框。在 Specific types (具体类型) 列表中，选择 S3 下的存储桶。

    

4. 选择用于存储配置历史记录和快照的 Amazon S3 存储桶。我们会创建一个新的 Amazon S3 存储桶。

    

   1. 如果您更希望使用账户中现有的 Amazon S3 存储桶，请选择 Choose a bucket from your account (从您的账户中选择存储桶) 单选按钮，然后使用下拉菜单选择现有的存储桶。

       

5. 在 Amazon SNS topic (Amazon SNS 主题) 下，选中 Stream configuration changes and notifications to an Amazon SNS topic (将配置更改和通知流式传输至 Amazon SNS 主题) 旁边的复选框，然后选择 Create a topic (创建主题) 旁边的单选按钮。
   1. 您也可以选择之前创建和订阅的主题。

       

   2. 如果您创建了新的 SNS 主题，则需要订阅它才能收到通知。我们将在后面的步骤中演示此操作。
6. 除非您已经有要使用的角色，否则请在 AWS Config role (AWS Config 角色) 下选择 Create a role (创建角色)。我们使用系统自动推荐的角色名称。

    

7. 选择下一步。
8. 配置 Amazon S3 存储桶监控规则：
   1. 在 AWS Config rules (AWS Config 规则) 页面上搜索 S3，选择 s3-bucket-publice-read-prohibited 和 s3-bucket-public-write-prohibited 规则，然后单击下一步。

       

   2. 在审核页面上，选择确认。AWS Config 此时会分析您的 Amazon S3 存储桶，捕获它们当前的配置，并根据我们选择的规则评估配置。
9. 如果您创建了新 Amazon SNS 主题，请打开 Amazon SNS 管理控制台并找到您创建的主题：

    

10. 复制该主题的 ARN（以 arn: 开头的字符串），您需要在后面的步骤中使用它。
11. 选择主题旁边的复选框，然后在操作菜单下选择订阅主题。
12. 选择电子邮件作为协议，输入您的电子邮件地址，然后选择创建订阅。
13. 几分钟后，您会收到一封电子邮件，要求您确认订阅与此主题有关的通知。选择对应链接以确认订阅。

步骤 2：为 Lambda 创建角色

我们的 Lambda 需要相关权限，才能检查和修改 Amazon S3 存储桶 ACL 和策略，记录 CloudWatch 日志并发布到 Amazon SNS 主题。现在，我们将设置自定义 AWS Identity and Access Management (IAM) 策略和角色来支持这些操作，并将它们分配到我们将在下一节中创建的 Lambda 函数。

1. 在 AWS 管理控制台中，在服务下选择 IAM 以访问 IAM 控制台。
2. 创建具有以下权限的策略，或者复制以下策略：

   
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "SNSPublish",
               "Effect": "Allow",
               "Action": [
                   "sns:Publish"
               ],
               "Resource": "*"
           },
           {
               "Sid": "S3GetBucketACLandPolicy",
               "Effect": "Allow",
               "Action": [
                   "s3:GetBucketAcl",
                   "s3:GetBucketPolicy"
               ],
               "Resource": "*"
           },
           {
               "Sid": "S3PutBucketACLAccess",
               "Effect": "Allow",
               "Action": "s3:PutBucketAcl",
               "Resource": "arn:aws:s3:::*"
           },
           {
               "Sid": "LambdaBasicExecutionAccess",
               "Effect"quot;: "Allow",
               "Action": [
                   "logs:CreateLogGroup",
                   "logs:CreateLogStream",
                   "logs:PutLogEvents"
               ],
               "Resource": "*"
           }
       ]
   }
   
   

3. 为 Lambda 函数创建角色：
   1. 从要使用该角色的服务列表中选择 Lambda。
   2. 选择您之前创建的策略旁边的复选框，然后选择 Next: Review (下一步：审核)
   3. 指定角色名称，为其输入描述，然后选择创建角色。在该示例中，我们将角色命名为 LambdaS3PolicySecuringRole。

步骤 3：创建和配置 CloudWatch 规则

在这一节中，我们将创建一个 CloudWatch 规则，以便在 AWS Config 确定您的 Amazon S3 存储桶不合规时触发 Lambda 函数。

1. 在 AWS 管理控制台中，在服务下选择 CloudWatch。
2. 在左侧的事件下，选择规则。
3. 单击创建规则。
4. 在 Step 1: Create rule (第 1 步：创建规则) 中的事件源下，选择下拉列表并选择生成自定义事件模式。
5. 复制以下模式，并将其粘贴到文本框中：

   
   {
     "source": [
       "aws.config"
     ],
     "detail": {
       "requestParameters": {
         "evaluations": {
           "complianceType": [
             "NON_COMPLIANT"
           ]
         }
       },
       "additionalEventData": {
         "managedRuleIdentifier": [
           "S3_BUCKET_PUBLIC_READ_PROHIBITED",
           "S3_BUCKET_PUBLIC_WRITE_PROHIBITED"
         ]
       }
     }
   }
   
   			

   该模式会在检查 Amazon S3 存储桶的公开访问权限时匹配 AWS Config 生成的事件。

6. 我们将在稍后添加 Lambda 目标。现在，选择您之前创建的 Amazon SNS 主题，然后选择配置详细信息。

    

7. 输入规则的名称和描述。在该示例中，我们指定名称 AWSConfigFoundOpenBucket
8. 单击创建规则。

步骤 4：创建 Lambda 函数

在这一节中，我们将创建新的 Lambda 函数，用于检查 Amazon S3 存储桶的 ACL 和存储桶策略。如果发现存储桶 ACL 允许公开访问权限，该 Lambda 函数会将其覆盖，改为私密。如果找到了存储桶策略，Lambda 函数会创建 SNS 消息，将该策略添加到消息正文中，然后将其发布到我们创建的 Amazon SNS 主题。存储桶策略可能很复杂，而覆盖策略可能会导致访问权限意外丢失，因此该 Lambda 函数不会尝试对您的策略进行任何更改。

1. 获取之前创建的 Amazon SNS 主题的 ARN。
2. 在 AWS 管理控制台中，在服务下选择 Lambda 进入 Lambda 控制台。
3. 在控制面板中，选择创建函数。或者，如果您直接进入了函数页面，也可以选择右上角的创建函数按钮。
4. 在创建函数页面上：
   1. 选择从头开始创作。
   2. 为该函数提供一个名称。我们使用 AWSConfigOpenAccessResponder。
   3. 我们编写的 Lambda 函数与 Python 3.6 兼容，所以请在运行语言下拉列表中选择 Python 3.6。
   4. 在角色下选择选择现有角色。选择您在前一节中创建的角色，然后选择创建函数。

       

5. 现在，我们根据之前创建的规则添加 CloudWatch 事件。
   1. 在 Add triggers (添加触发器) 部分，选择 CloudWatch Events。CloudWatch Events 框应该会显示在 Lambda 函数左侧，还会显示一条内容为 Configuration required (需要配置) 的备注。

       

   2. 在规则下拉框中，选择您之前创建的规则，然后选择添加。
6. 向上滚动到 Designer (设计者) 部分，然后选择您的 Lambda 函数的名称。
7. 删除默认代码，然后粘贴以下代码：

   
   import boto3
   from botocore.exceptions import ClientError
   import json
   import os
   
   ACL_RD_WARNING = "The S3 bucket ACL allows public read access."
   PLCY_RD_WARNING = "The S3 bucket policy allows public read access."
   ACL_WRT_WARNING = "The S3 bucket ACL allows public write access."
   PLCY_WRT_WARNING = "The S3 bucket policy allows public write access."
   RD_COMBO_WARNING = ACL_RD_WARNING + PLCY_RD_WARNING
   WRT_COMBO_WARNING = ACL_WRT_WARNING + PLCY_WRT_WARNING
   
   def policyNotifier(bucketName, s3client):
       try:
           bucketPolicy = s3client.get_bucket_policy(Bucket = bucketName)
           # notify that the bucket policy may need to be reviewed due to security concerns
           sns = boto3.client('sns')
           subject = "Potential compliance violation in " + bucketName + " bucket policy"
           message = "Potential bucket policy compliance violation. Please review: " + json.dumps(bucketPolicy['Policy'])
           # send SNS message with warning and bucket policy
           response = sns.publish(
               TopicArn = os.environ['TOPIC_ARN'],
               Subject = subject,
               Message = message
           )
       except ClientError as e:
           # error caught due to no bucket policy
           print("No bucket policy found; no alert sent.")
   
   def lambda_handler(event, context):
       # instantiate Amazon S3 client
       s3 = boto3.client('s3')
       resource = list(event['detail']['requestParameters']['evaluations'])[0]
       bucketName = resource['complianceResourceId']
       complianceFailure = event['detail']['requestParameters']['evaluations'][0]['annotation']
       if(complianceFailure == ACL_RD_WARNING or complianceFailure == ACL_WRT_WARNING):
           s3.put_bucket_acl(Bucket = bucketName, ACL = 'private')
       elif(complianceFailure == PLCY_RD_WARNING or complianceFailure == PLCY_WRT_WARNING):
           policyNotifier(bucketName, s3)
       elif(complianceFailure == RD_COMBO_WARNING or complianceFailure == WRT_COMBO_WARNING):
           s3.put_bucket_acl(Bucket = bucketName, ACL = 'private')
           policyNotifier(bucketName, s3)
       return 0  # done
   			

8. 向下滚动到环境变量部分。该代码使用一个环境变量来存储 Amazon SNS 主题的 ARN。
   1. 输入 TOPIC_ARN 作为密钥。
   2. 输入之前创建的 Amazon SNS 主题的 ARN 作为值。
9. 在 Execution role (执行角色) 下选择选择现有角色，然后从下拉菜单中选择之前创建的角色。
10. 保留其他内容不变，然后在顶部选择保存。

步骤 5：验证效果

到现在为止，我们已经有了一个 Lambda 函数、一个 Amazon SNS 主题、监控 Amazon S3 存储桶的 AWS Config，以及在发现存储桶不合规时触发 Lambda 函数的 CloudWatch 规则。我们来进行测试，确保它们能够正常工作。

我们有在受 AWS Config 监控的区域中创建的 Amazon S3 存储桶 myconfigtestbucket，还有关联的 Lambda 函数。ACL 或策略中未设置该存储桶的公开读写访问权限，所以它是合规的。

我们来更改存储桶的 ACL，以允许公开列出对象：

保存后，该存储桶便可公开访问了。几分钟后，AWS Config 控制面板会发现一项不合规的资源：

在 Amazon S3 控制台中，我们可以看到：在调用由之前创建的 CloudWatch 规则触发的 Lambda 函数后，存储桶中不再公开列出对象。

请注意，AWS Config 控制面板此时显示没有不合规的资源了：

现在，我们来配置允许列表访问的存储桶策略，以尝试进行 Amazon S3 存储桶策略检查：

对 myconfigtestbucket 存储桶设置该存储桶策略后，AWS Config 会在几分钟后检测到该存储桶不再合规。因为这是存储桶策略而不是 ACL，所以我们将一条通知发布到我们之前创建的 SNS 主题，以通知我们可能违反策略的行为：

获知该策略允许公开列出存储桶后，我们现在可以修改或删除该策略，随后 AWS Config 会检测到资源符合策略。

结论

在本文中，我们演示了如何使用 AWS Config 监控 Amazon S3 存储桶是否使用公开的读写访问权限 ACL 和策略。另外，我们演示了如何使用 Amazon CloudWatch、Amazon SNS 和 Lambda 覆盖公开的存储桶 ACL，或者在存储桶使用可疑策略时提醒您。您可以使用 CloudFormation 模板在多个区域快速部署该解决方案。通过该方法，您将能够轻松找出并保护公开的 Amazon S3 存储桶 ACL 和策略。将该解决方案部署到多个区域后，可以使用 AWS Config 聚合器来聚合结果。阅读本文了解更多信息。

利用 AWS Config 监控和响应 Amazon Simple Storage Service (S3) 允许公开读写访问权限，首发于服务器安全维护工作室。

{
  "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 角色，首发于服务器安全维护工作室。

Q：如何提高 S3 性能？

A：S3 index 和实际数据分开存放。默认一个 bucket 所有 object 都位于同一个分区。如果 object 数量太多，而请求速率又不高时，S3 会根据 key name 自动分区。但是，如果请求速率太高，会耗尽 S3 分区的 IO，触发限制，可能会返回503 Slow Down 错误。

尽量利用 hash 或者倒序，使 S3 前缀随机化。如果读写请求过高，可以向 AWS 提交 S3 分区请求，或者采用指数退避(exponential backoff)算法，增加请求的重试等待时间。尽管如此，仍然需要遵循 S3 key name 随机化原则。可以对于某个目录下的已经随机化的 object 进行分区。

例如：S3 bucket 的 log 目录下的.log 对象前缀已经做了随机化。

S3://bucket/log/A0B1.log

S3://bucket/log/C2D3.log

S3://bucket/log/E4F5.log

在提交请求时，除了请求速率，还需要填写 pattern，注明 log/ 目录下是如何进行随机化的。后台就可以在 S3://bucket/log/ 后面进行分区。

S3 不限制带宽。但是，也不要对 S3 进行压力测试。实际的传输速率和客户端到 S3 的网络有关。如果客户端请求很多，可以使用 CDN 进行加速。

Q: 有很多小文件，如何有效上传到 S3？

A: 如果可能，尽量先压缩成大文件再上传。一方面，减少大量小文件上传时，TCP 连接建立和断开的开销。另外一方面，S3 虽然上传流量不收费，但是请求仍然收费。

Q: 需要在本地到 S3 之间每日同步文件，现有文件数量非常多（几百万），如何提高效率？

A: aws s3 sync 命令可以同步本地到 S3 的文件，只同步变化的部分。但是，sync 需要先列出 LIST S3，以进行比较。如果文件数量非常巨大，LIST 所有对象，非常花费时间，甚至可能卡住。

解决办法：只同步变化的目录。例如，按照日期目录来同步。

aws s3 sync /data/2018/03/13 s3://bucket/data/2018/03/13

如果每天变化的数据分布在不同目录，可以把这些变化记录在 Dynamodb，在同步时，只同步变化的部分。

Q: S3 是否支持断点续传？

A: 断点续传的实现，在于根据 content-length 划分成多个 range，没有传完的，可以保留，下次可以继续传输。

S3 支持 multi-part 分段传输。分三个步骤：

1. Initiate Multipart Upload：初始化任务。
2. Parts Upload：把文件分成多块，每个块都有一样的 upload ID，和不同的 part number。不同的分块分别传输，与顺序无关。
3. Complete Multipart Upload：所有分块完成后，把分块合并成 S3 对象。一般的程序，例如 AWS CLI，如果有部分没有完成，并且重试后超时，那么会调用 Abort Multipart Upload，所有已经上传到 S3 的部分全部删除，任务终止。

S3 没有提供直接断点续传 API，可以自己在程序加个逻辑来实现。如果在第二阶段有部分一直没有传完，就不会调用第三阶段的 Complete/Abort。这样，已经传输完成的部分会一直放在 S3，直到 Complete/Abort。

Q: 应用程序在下载S3文件时，会判断MD5以防止文件传输中被篡改，但是大文件总是出错。

A: S3 大文件传输使用 multi part 分段。对于每一段，分别计算 MD5。最后在任务完成时，把所有分段的 MD5，再进行 MD5 计算，得到 S3 Etag 值。

应用程序只对比了某一段的 MD5 值，与 S3 Etag 不一致，因此出现错误。

Q:在移动应用上传到S3的场景下，S3 Pre-singed URL和Cognito方式，有何区别？

A: 移动客户端在上传时，需要在服务器生成 Pre-signed URL，返回客户端。客户端以此临时 URL，无需 credentia l即可上传。实际上，上传时，使用的是服务器生成 URL 时的 IAM 用户权限，相当于以此 IAM 用户来上传。此方式的限制在于，pre-signed URL 不知道整个上传对象的大小，因此不能使用 S3 multi-part，对于大文件的传输效率比较低。

在 Cognito 的环境下，移动客户端上传时，先要进行自定义或者联合认证。验证通过后，与 Cognito 交换 token。之后客户端以 Cognito token 向 STS 获取临时 credentia 以访问 S3。以此方式上传，客户端可以使用正常的 API，包括multi-part。

中国区 Cognito 目前还没有用户池功能，不支持 Google, Facebook 认证。可以自行进行用户管理，比如 LDAP/AD。对于不大的文件上传，pre-signed URL 一般可以满足需求。

Q:S3最终一致性如何？

A: 对于新创建的 S3 object，采用 read-after-write 一致性，上传完成后立刻可以访问。

对于覆盖或者 HEAD/GET 操作过的 object，采用最终一致性。如果覆盖后立刻访问，可能会是新内容，也可能是之前的内容，但是最终会是新的内容。

Q: 我帐号下 S3 的 ELB 访问日志，bucket 策略已经授权别的帐号可以方案，为什么别的帐号还是不能访问？

A: ELB 访问日志是 AWS 系统帐号经过授权，向您的帐号下 S3 上传的对象。日志文件的所有者是 AWS 帐号，在上传时把您的帐号添加到 Object ACL，因此您可以访问。但是，文件所有者并非您的帐号，别的帐号没有添加到 Object ACL，即使 bucket policy 允许别的帐号访问，仍然不能访问。

解决方法：在 object ACL 加入别的帐号的 canonical id，ID 可以通过 AWS CLI 命令行获得：

aws s3api list-buckets
{
    "Owner": {
        "ID": "633eb40d3277ec23db4bc5a394dc363f48e41c85358c5618f0de3df382855242"
},

注意：对于上传到别的帐号 bucket 的 object，如果没有授权 object ACL 给 bucket 所有者，bucket 所有者也不能下载或者修改 ACL，只能删除。

Q:设置生命周期为何不生效？

A: S3 生命周期设置后，于 UTC 时间第二天的0点开始工作。所有对象，按照创建时间，或者变成 non-current version 的时间，如果满足条件，就会被转移到 Glacier/Standard IA 类型，或者删除。在对象太多的情况下，此工作可能需要更长时间。

如果一直不生效，可以检查生命周期规则是否带了空格，或者通过 s3api head-object 查看是否在进行转换。

如果是转换成 Standard IA 类型， S3 对象大小需要在 128KB 以下。

Q: 浏览器访问 S3 对象 URL 链接，出现 401 Unauthorized 错误。（中国）

A: 请进行 ICP 备案，打开帐号的 80/443/8080 端口。

Q: 通过浏览在 AWS 控制台下载 S3 对象，出现 Unexpected IP 错误。（中国）

A: 控制台下载 S3 对象，会生成一个特殊的 pre-signed URL，带有 x-amz-expect-ip 参数，限制了能使用此 URL 的 IP。返回客户端以此 URL 上传时，如果 IP 发生变化（包括公司出口 IP 变化，使用代理，等等），就会出现 Unexpected IP 错误。

Q: 如何同步 Global 海外到中国 S3？（中国）

A: AWS Global 和中国使用不同的帐号，不能直接通过 S3 Cross-region replication 进行同步。

如果要自动同步，可以考虑 S3 Notification + Lambda 方式。当 S3 对象有变化时，通知触发 Lambda，自动调用函数，复制对象。需要注意，此方法受到中国到海外Internet 网络状况影响，对于大文件支持不够好。

另外一个方法，S3 Notification + SQS。S3 通知发送到 SQS 消息队列，EC2 运行程序，定期从 SQS 获取消息。如果有更新，海外 EC2 下载海外S3对象，复制到中国区 EC2，再从中国区 EC2 上传到中国 S3。此方式虽然比较复杂，但是可以充分利用 AWS 跨区域 EC2 的优化网络，并且可以使用 S3 multi-part  特性，更适合大文件的传输。

Q: EC2 实例状态检查失败，停止一直卡住。

A: EC2 实例状态，如果是 0/2，说明底层硬件出现故障。可以停止 (stop) 实例，然后启动 (start)，虚拟机迁移到别的物理主机。如果停止操作时一直卡住，可以再次强制停止。如果仍然不行，请开启技术支持案例。对于 C3, C4, C5, M3, M4, M5, R3, R4, T2, or X1 类型实例，建议开启 EC2 自动恢复功能。当底层硬件出现故障时，可以自行恢复。

请注意：实例存储 (instance store) 的数据会丢失。重要数据尽量使用 EBS，并且进行快照备份。

如果状态检查是1/2，说明底层硬件正常，但是操作系统出现故障，需要结合日志信息自行排查。

Q: EC2 实例带宽是多少？

A: EC2 实例根据类型不同，网络性能分低、中、高等。由于客户端到 AWS 网络状况不同，需要测试来获得实际数值，例如 iperf 工具。有些类型，例如 C4，可以达到 10Gb 的网络带宽，这是对于 EC2 实例内部之间而言，到 Internet 的网络性能，仍然需要实际测试。

有些类型支持增强型联网，可以提高网络性能。此功能可能需要在操作系统安装驱动并启用模块。

Q: 访问位于 EC2 的网站，速度很慢。

A: 访问速度，在整个过程中的服务器、网络、客户端都会受到影响。

服务器层面，CPU / 内存 / IO 资源的使用情况，操作系统的内核参数，应用程序的优化，都会影响整个用户体验。通过 Cloudwatch 监控 CPU / IO/ 网络情况，在操作系统上查看内存和进程，检查操作系统和应用日志，必要时用 strace 等工具追踪调用。

网络层面，从客户端到服务器，中间要经过多个路由器，运营商可能会出现一些网络拥塞或者路由问题。以双向 traceroute/mtr 工具，检查哪些网络路由可能存在问题。请确认网络问题是否具有普遍性，检查其他地区用户是否也存在同样问题。如果是运营商网络拥塞，或者客户端接入了一些复杂网络，这已经超出了 AWS 所能解决的范围。

客户端层面，自身的 CPU / 内存等资源情况需要检查。对于请求本身，一般来说，带数据库复杂查询的动态 HTTP 请求，或者需要下载很多图片 / 视频 / css / js 的页面，要比简单的 HTML 页面要快。可以换一个别的客户端，以同样的请求，再进行测试。

Q: EC2 被停止或终止了，但不是自己操作的。

A: AWS 不会关闭用户 EC2 实例，哪怕是底层硬件故障。请检查是否有 Autoscaling / Cloudformation 等其他服务触发了操作。打开 Cloudtrail 可以看到 API 调用记录。

Q: EC2 是否支持广播？

A: EC2 不支持广播和组播，只支持单播。一些应用中，例如 LVS keepalived，需要特别设置为单播模式。

Q: EC2 设置安全组，允许另外一个安全组访问，但是不通。

A: 安全组里允许另外一个安全组访问，在连接时，需要使用私有 IP。如果使用公有 IP，安全组里要设置为公有 IP CIDR。

另外，EC2 内部访问尽量使用私有 IP，这样可以减少网络传输成本。

Q: 创建 CentOS 实例，根盘使用 10GB EBS，但是 df 命令只能看到 8GB。

A: 默认 CentOS 根盘分区表是 8GB，需要自行更改分区表，并扩展文件系统。

Q: 创建实例时，挂了 3TB 的根盘，启动后实例马上被终止了。

A: Windows 使用 MBR 分区，最大支持 2TB 根盘。 Linux MBR 也受到同样限制。

解决办法：根盘使用小于 2TB 的 EBS，数据放在单独添加的 EBS。Linux  也可以使用 GPT 分区，不受 2TB 限制。

Q: CentOS 配置多网卡不生效。

A: CentOS 等非 Amazon Linux 系统，缺少某些网络安装包，需要自己配置策略路由。这样，从哪个网卡接收到的包，还从这个网卡发送回去。

Q: 创建 C4 类型 CentOS 实例，出现 1/2 检查状态，不能登录。

A: C3/C4 等类型实例，默认启用增强网络。一些非 Amazon Linux，可能没有 ixgbev f增强网络驱动，实例不能正常启动。

解决办法：安装 ixgbevf 增强网络驱动。

Q: 如何在中国区使用 CentOS？（中国）

A: 中国区暂时没有官方 CentOS。可以自己以 VM Import 方式从本地虚拟机镜像导入，或者，从 AWS 海外区域通过dd 镜像文件导入中国区 AMI。

由于安全原因，不推荐使用非官方的社区 Centos。

Q: 为什么 EBS 没有达到预期的 IOPS，却被限制了？

A: EBS 除了IOPS，还有最大吞吐量限制 (GP2 160MB/s, IO1 500MB/s)。这个与 IO 大小有关。请检查 Cloudwatch 的吞吐量指标是否达到上限。

另外，对于连续的小 IO，会合并成单个 IO。

Q: 创建了 EBS，在 attach 实例时，找不到需要的实例。

A: EBS 要与 EC2 实例位于同一个可用区 (Availability zone)，才能 attach 到实例。

Q: 如何为 EBS 自动创建快照？

A: 方法1：创建定时任务，定期执行 AWS CLI 命令进行快照。

方法2：使用 Cloudwatch Events + Lambda，无服务器方式自动运行。

Q: 访问 ELB，有的请求正常，有的超时。

A: 公开的 ELB 要位于 VPC 里的公有子网，即有 IGW，可以从 Internet 访问。如果 ELB 所在的子网，包括了私有子网，这样 ELB 会在私有子网里创建节点。当从 Internet 访问时，DNS 解析到私有子网的节点，这部分请求就不可达。

Q: 后端服务器日志发现所有的请求源 IP 都是 ELB，如何获取客户端真正的 IP？

A: HTTP 监听方式时，后端服务器启用 X-Forwarded-For 特性。

TCP 监听方式，ELB 要开启 forward protocol，加入特定 header。

Q: ELB/ALB 采用什么算法转发请求到后端实例？

A: ELB TCP 监听端口使用轮询算法，HTTP 监听端口使用未完成最少请求算法。

ALB 使用轮询算法。

如果只有1个健康的后端实例，所有请求都会被转到此实例。如果没有任何健康的后端实例，请求会被转发到所有已注册但是不健康的实例。

Q: ELB 不是由客户控制，出现服务器错误如何排查？

A: 客户端请求返回 5XX 错误，可以根据 HTTP 代码，结合 Cloudwatch HTTP 5XX、ELB 5XX、Backend Connection Errors 等监控指标，初步判断是 ELB 还是后端服务器问题。

如果是 504 网关超时，还要打开 ELB 访问日志，在客户端和后端服务器进行抓包分析。一般来说，如果后端 web 服务器启用 keep-alive，超时时间要大于 ELB 空闲超时。

Q:NLB 如何选择子网？

A: NLB 要位于公有子网。后端目标实例，可以位于公有子网，也可以位于私有子网。注意：如果后端实例位于私有子网，需要设置 NAT，让数据包能有回到客户端的路由。这一点与 ELB/ALB 不同。

Q: 应用程序访问 ELB，有时候会出现 Unknown host 无法解析的错误。

A: ELB 会根据流量自动扩展或者缩减，IP 发生变化。DNS 服务器需要及时更新变化。ELB DNS TTL 是60秒，ELB IP 变化后，会在60秒之内更新 DNS 记录。但是由于客户端有缓存，如果一直不更新，就会出现无法解析的问题。

默认 Java DNS TTL 是永久生效，重启 Java 可以临时解决问题。建议修改 Java DNS TTL 为60秒。

Q: ELB 预热或者固定 IP 申请时，如何估算 ELB 的请求/响应平均流量？

A: 举例：一个200KB 的网页通常不太可能是在一次请求/响应中将200KB 的流量全部流过 ELB。更可能的分布是：20KB 是 HTML，30KB 是 Javascript/CSS，150KB 是10个15KB 图片，总共12个请求。这样一个经过 ELB 的请求/响应平均流量不是200KB 而是17KB (200/12=16.67)。如果您将静态内容和下载内容优化在了 S3 或者 CDN 中，这个 ELB 的请求/响应平均流量会更加小。

Q: 归档到 Glacier 的文件，如何根据文件名取回？

A: Glacier 的归档对象都有archive id，以此取回数据。但是 archive id 是一串字符，并非文件名。可以使用数据库（例如 DynamoDB）记录文件名和 archive id 的对应关系。或者，在归档对象的描述中，写入文件名。在归档文件很多的情况下，建议使用数据库方式，提高效率。

Q: 是否支持高可用性架构？

A: 无论使用哪种类型的网关，都是需要在本地或者 EC2 安装网关虚拟机，作为本地和 AWS 之间的存储网关。此网关只有一个，虚拟机本身不支持高可用架构。

Q: 使用文件共享类型网关，传输速度很差。

A: 影响性能的因素有：网络、S3、存储网关、客户端。

NFS 客户端挂接存储后，所有读请求是要先到网关。如果网关缓存有数据，则直接返回客户端。

写请求也是要先到达网关，先写入网关的本地存储磁盘，然后再异步复制到 S3。

S3不会限制传输带宽。一般来说，本地网络到 Internet 的出口带宽，只会影响到网关向 S3 复制数据。

对于客户端来说，传输速度是对于客户端到本地存储网关而言。客户端的设置，以及本地网关的性能，是最大的决定性因素。

Windows 2008 支持 NFSv3，Windows 2012/2016 支持 NFSv4。V4 cache 比 V3 大了很多，对于 NFS 来说，性能影响很大。

网关服务器要有足够的 CPU 处理能力和内存。Upload buffer 最小150GB，Cache 建议是 upload buffer 的1.1倍。存储网关的物理机上，在创建虚拟机磁盘文件时，系统和 cache/upload buffer 所在的物理磁盘要分开，并且尽量使用 SSD。

Q: 如何让登录 AWS 控制台的 IAM 用户只能启动或停止某些 EC2 实例？

A: IAM 用户登录到 AWS 控制台，要么列出所 有EC2 实例，要么什么都不能列出。因为，DescribeInstances 权限不支持资源级别，不能单独对于某些资源（EC2 实例、VPC 等）做权限控制。对于不支持资源级别的权限，在策略的 Resource 部分，只能用*来代表所有资源。

StartInstances/StopInstances 支持资源级别权限，可以定义实例 ID，或者通过其他条件来控制。

以下 IAM 策略，允许列出所有 EC2 实例和状态，并且只能对于标签 Group=test 的实例进行 start/stop 操作。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "arn:aws-cn:ec2:cn-north-1:794767850066:instance/*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Group": "test"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceStatus",
                "cloudwatch:Describe*",
                "cloudwatch:Get*",
                "cloudwatch:List*"
            ],
            "Resource": "*"
        }
    ]
}

除了标签，还可以直接定义实例 ID，或者其他符合的条件，来进行 stop/start 权限控制。

参考：

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-iam-actions-resources.html

Q: 分别在物理机和 AWS RDS 进行测试，为什么类似的机型，同样的测试方式，结果却显著不同？

A: 测试对比的一个前提是，环境一致。除了服务器处理能力，测试方法外，存储性能，以及数据库本身的参数，都会影响结果。

RDS 如果是从快照恢复，EBS 存储会有一个预热过程，需要先对 EBS 里的数据块进行读取，才能达到最佳性能。测试建议使用新建 RDS，而不是从快照恢复，这样使用全新的 EBS，不会有预热问题。

EBS 的 IOPS 也会有影响。可以通过 Cloudwatch 监控，确保 EBS IOPS 或者吞吐量，没有达到上限。

数据库参数对性能影响极大，例如 innodb_flush_log_at_trx_commit。确保测试比较时，数据库参数一致。

Q: 访问不同 AZ 可用区的应用，连接 RDS，延迟差异明显。

A: 为了实现高可用性，把应用部署到不同 AZ 的 EC2。RDS 位于某个 AZ。当从 EC2 访问不同 AZ 的 RDS 时，有微小的网络延迟。如果应用程序在 EC2 和 RDS 之间有多次交互，那么会把微小的网络延迟放大。

对于网络延迟要求很高的业务，可以优化应用，避免在一次交易中进行多次数据库访问。如果应用不能调整，尽量把应用服务器放在与 RDS 同一 AZ，但是这样会有高可用的隐患，需要在性能和可用性之间做出权衡。

Q: RDS 很多命令执行出现权限错误。

A: RDS 是托管服务，有很多机制来保证数据库的高可用。涉及到操作系统或者数据库底层的方面（例如系统表），一般不能修改。常见的数据库操作，可以通过一些定义好的存储过程来进行。

例如，杀掉 mysql 进程：

CALL mysql.rds_kill(processID);

其他的一些操作，例如修改数据库参数，可以通过参数组里的参数来修改。

参考：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html

Q: RDS Mysql 主从复制，能否选择表？

A: RDS 和外部 Mysql 之间的主从复制，可以通过外部 Mysql 的 /etc/my.cnf，replicate-ignore-db 或 replicate-do-db 来选择表。

RDS 内部的复制，目前还不支持选择表。

Q: RDS 显示磁盘容量耗尽，但是似乎并没有那么多的数据。

A: 除了数据库表的数据，还有索引、日志、临时空间，都会占用存储。Mysql 日志会占据最高 20% 或者 10GB 的存储空间。一些复杂查询可能会使用大量的临时存储。可以设置 Mysql binlog 保留时间，以及是否开启 general log。

Q: RDS MysQL 数据库重启，提示 Out of memory

A: 内存耗尽，和数据库参数有关。max_connections 定义了最大连接=内存字节 /12582880。如果修改了此参数，突破限制，可能会造成内存耗尽。监控机制发现问题，自动重启数据库。

Q: RDS Mysql 主从复制延迟一直在增加。

A: 主库和从库实例类型要一致，否则容易因为处理能力有差异，在数据量大时，产生滞后。

分别检查主从库的 EBS IOPS 和吞吐量，是否达到上限。

检查从库是否有锁操作。

查看 slave 状态，show slave status \G; 检查是否复制过程中有错误产生而产生停滞。如果有，跳过错误重试。

Mysql 5.7 允许并行复制，以提高同步效率。数据量大时可以打开此功能。

slave_parallel_type=LOGICAL_CLOCK

slave_parallel_workers>1

Q: RDS 设置为公开访问。如何从同一个 VPC 内的 EC2 访问 RDS，不走外网？

A: RDS 域名在创建 RDS 时生成。应用程序需要访问 RDS 域名。如果 EC2 和 RDS 位于同一个 VPC，DNS 解析出内网 IP，通过私有网络连接。

Q: 为何 RDS MySQL 不能通过时间点恢复数据？

A: RDS MySQL 要启用 binlog，通过快照 +binlog 的方式，恢复到之前的某个时间点。

如果没有启用自动快照功能，binlog 不会保存，也就不能通过时间点恢复。

另外，只有 innoDB 表才能使用此功能。MyISAM 不基于事务，重启或者数据库故障时可能会丢失数据。如果没有特别要求，建议使用 innoDB 存储引擎。

Q: 如何进行数据库迁移？

A: Mysql: 采用全量 Mysqldump+ 增量 replication 方式。但是，在 mysqldump 导出数据并复制到目标数据库这段时间内，主库要设置为只读，避免新的数据写入。

Oracle：Dataguard 或者 GoldenGate。但是需要特定的 Oracle 企业版本，或者单独购买许可。

AWS DMS 服务：在线数据库同步。主库无需设置只读，同步过程中通过中转节点读取日志变化，并在同步到目标数据库时重放这些变化。即使数据库位于私有子网，DMS 也可以访问数据库，并设置为源或者目标。DMS支持不同数据库迁移，包括 RDS 支持的数据库，以及 Redshift。

AWS DMT 工具：中国还没有上线 DMS 服务，可以申请 DMT AMI，创建 EC2 实例，带有 DMT 图形化迁移工具。

Q: DynamoDB 预配置很多读写容量，但是没用多少，就出现受限错误。

A: DynamoDB 预配置读写容量按照整个表来统计。DynamoDB 有分区，每个分区的资源是有限的。当预配置读写容量，或者数据量超过一定程度时，DynamoDB 会自动分区。根据主键 partition key 哈希值，确定每个 item 的所在分区。如果某些特定的 item 读写量巨大，落在某个分区，耗尽此分区的 IO 资源，就会出现受限。

举例，为某个表设置了10000读容量和4000写容量，可能需要总共8个分区。根据预设值的容量计算，每个分区的读容量上限为1250。某些热点数据读取过于频繁，达到1250会出现错误。

还有一种可能，之前设置了大读写容量，自动进行分区。后来减少读写容量，但是分区不会减少，这样分配给每个分区的读写容量更少，更容易出现热点分区数据受限的问题。

解决办法：

• 增加读写容量。
• 避免过度的热点数据访问。
• DynamoDB 之前加入 Elasticache 缓存，或者 DynamoDB DAX 缓存功能，来减少读写压力。

Q: DynamoDB 中国区如何备份？

A: DynamoDB 在海外区域已经有备份恢复功能，但是中国区目前还没有。可以使用 DynamoDB 自带的导出 csv 功能，或者第三方工具，把数据导出成文件。

Q: 如何监控 Elasticache Redis 性能指标？

A: Cloudwatch 有以下指标需要关注：

• • CPUUtilization：CPU利用率。对于Redis这种缓存服务来说，一般CPU利用率不高。
  • SwapUsage：交换分区。内存不足时会使用。但是，如果只是偶尔出现少量的 swap 使用，也有可能是操作系统某些动作所产生。如果其他指标，例如BytesUsedForCache, Evictions 正常，可以不必过于关注。
  • Evictions：由于超过最大内存限制，而被驱逐出的key数量。这是重要指标。检查 BytesUsedForCache 指标，如果几乎用满了分配的内存，说明内存不足。

BytesUsedForCache：分配给 Redis 的内存。注意，有部分内存是保留给备份或者复制等操作所使用。有可能看到的情况是，选择了16GB内存的 Redis 实例类型，最多只能使用12GB。新创建的 Redis，默认保留25%内存。请检查 reserved-memory 和 reserved-memory-percent 这两个参数。

CurrConnections：当前客户端连接数。如果与之前相比，出现异常，请检查应用程序。Redis是单线程，客户端一般是通过连接池来管理，提高效率。

FreeableMemory：操作系统层面的可用内存。Linux 的一个机制是，尽量使用 buffer/cache，很多内存用于缓存，可用内存一般很少。如果可用内存很少，而其他 Redis 指标正常，不必担心。

Q: Elasticache Redis 如何做持久化？

A: AOF (Append Only Files ) 把数据放在本地磁盘，此功能2.8以及之前的版本默认不开启，3.2以上版本进禁止修改。建议使用复制组，而不是 AOF。本地磁盘位于实例存储 (instance store)，用于存储临时数据。如果出现底层硬件故障，本地磁盘的数据，包括 AOF，也会丢失。而复制组位于多可用区，数据自动复制到只读副本，可以自动实现故障转移。

Q: Elasticache Redis 复制组如果出现故障，应用是否需要调整？

A:如果只读副本出现故障，那么会自动启动新的只读副本以替代故障节点。应用程序需要修改只读请求，到新的只读副本。到主节点的读写请求无需修改。

如果主节点出现故障，那么会自动提升某个只读副本为新的主节点，DNS 会指向新的 IP。对于应用程序来说，读写请求还是指向主节点 DNS，无需修改。而只读请求要修改，包括新的只读副本。

Q: 如何设置Redis用户名密码登录？

A: Elasticache Redis 不支持用户名密码登录。可以通过安全组和网络 ACL，只允许信任的 IP 访问。

Q: 如何设置 Redis 允许从外网访问?

A: Elasticache Redis 设计成内部访问，DNS 解析出来的 IP 都是 VPC 内的私有地址。从外网访问，网络延迟会影响性能，并且也不安全。

如果一定要从外网访问，可以在 VPC 内把一个 EC2 实例做成 NAT，添加 iptables 规则，从外网访问 EC2 某个端口（例如6379），通过 NAT 端口映射到内网 Redis 端口。请注意，这些外网流量不加密，谨慎选择此方式。

Q: Elasticache Redis 有集群和非集群模式，如何选择？

A: 两种模式都支持主从方式实现高可用性。集群模式中，每个分片中都有一个复制组，包括一个主节点和多个只读副本。

两种模式的不同在于扩展性。

非集群模式中，主节点只有一个，如果内存不足，只能通过升级节点类型的方式。只读副本最大5个。

集群模式提供了分区功能。如果主节点写请求压力大，使用集群模式进行分区，最大15个，把数据写入到多个节点，实现更好的扩展。对于读请求，集群模式可以有最多15*5=75个只读副本。

Q: 将 S3 中的大量 Gzip CSV 导入 Redshift，如何提高并发 COPY 性能？

A: Redshift COPY 性能受以下因素影响：

• 并行传输。将数据拆分成多个文件，同一个 COPY 命令可以把多个文件并行写入到同一个表。请注意，此特性不适用于多个 COPY 命令写入同一个表，需要等待前一个 COPY 完成才能继续。
• 表压缩。默认情况下， COPY 空表自动压缩。压缩消耗资源，会牺牲一部分 COPY 性能，以换取更小的存储空间。需要在性能和存储之间做出权衡。COMPUPDATE OFF（或 FALSE），将禁用自动压缩。
• 表分析。默认情况下，COPY 命令会在将数据加载到空表后执行分析。分析就是运行 ANALYZE 命令，以构建和选择最佳计划的统计元数据，也需要消耗资源。在导入过程中，COPY 命令加入 STATUPDATE OFF（或 FALSE），不会更新统计数据。
• 排序键。如果表定义了排序键 (sort key)，可以在 COPY 导入数据的时候更有效率，并且提高查询效率。
• 分配。Redshift 导入数据时，会把每一行数据按照 distribution style 存储到不同的计算节点。这对于之后的查询性能也很重要。
• 文件压缩。多个csv gzip 文件直接放在 S3，在导入 redshift 的时候，需要解压，会影响性能。如果都是小的压缩文件，请解压后再上传到 S3，然后再 copy 到 redshift。

Q: Redshift 为多个表创建联合视图，表已经创建了SORT KEY，但是查询性能很低。

A: Redshift sort key 默认为 COMPOUND。如果查询条件中使用了这个 sort key 所包含的所有列，那么查询效率将会很高。相反的，如果查询条件中，并没有包括 sort key，或者只包含 COMPOUND SORT KEY 某一部分，查询效率将会下降。

查询视图需要遍历所有数据，视图会创建临时表，并扫描此临时表。即使源表设置了sort key，视图也不会使用，从而降低查询效率。

解决方案：

• 修改 sort key 为最需要排序的列，并且在查询中使用 sort key 的所有列，而不要只指定 sort key 的部分列。如果只需要其中一些列作为优化排序，在创建表时，使用 INTERLEAVED SORT KEY语句。
• 只创建一个表，每天的数据通过 COPY 命令导入 Redshift 这个表。单个表的查询，可以直接使用 SORT KEY 优化。
• 如果有别的表需要 JOIN 操作，设置正确的 DISTKEY，避免不必要的节点之间数据传输。
• 如果表排序已经很乱，或者有一些空间标记为删除，但是没有回收，请运行 vacuum 命令以回收空间，并执行排序。

Q: Redshift 无法并行跑大 Query，出现 out of memory。

A: 以下是 Redshift 的一些统计信息。

skew_rows 表示不同切片中，最多行数与最少行数的比率。这些表倾斜严重，说明分配不当，消耗更多内存，严重时耗尽内存资源。并且，一些表使用了 date 类型的字段作为 dist key，但是 date 类型并不适合。

这些问题会消耗大量内存。

解决方案：

重建倾斜严重的表，选择适当的 DIST KEY，要与其他表最为关联的列。

Q: Redshift 是否可以在线扩容？

A: Redshift 可以修改节点数量，实现在线扩容。修改过程是，新建一个 Redshift 集群，把数据复制过去。如果数据量很大，修改可能需要很长时间。也可以考虑把原有集群创建快照，从快照恢复新的集群，再进行改名操作。这样可能会节省时间。

Q: 为什么访问 API Gateway，出现 403 Forbidden 错误？（中国）

A: 由于中国政策原因，在中国使用 API Gateway，需要提交申请，把帐号加入白名单。

Q: SNS 是否支持移动消息推送？（中国）

A: 中国区目前不支持移动消息推送功能，以及 SMS 手机短信功能。SNS 可以发送消息到 Lambda 或者 SQS 消息队列，您可以自己开发程序，进行移动消息推送。

Q: EMR 数据如何选择，存放于 HDFS 还是 S3？

A: HDFS 运行于 EC2，与 S3 都位于 AWS 内部网络。访问 S3 并不比 HDFS 有明显的网络延迟差异。

相对于 HDFS，数据存放于 S3，有更多好处：

• S3 具有11个9的持久性，基本不会丢失数据。
• S3 具有无限容量，而 HDFS 要受到本地存储容量限制，以后扩展性受限。
• 如果数据要迁移到新集群，位于 S3 的数据会一直存在，而 HDFS 则需要进行数据迁移。

Q: EMR 资源不足，如何扩容？

A: EMR 可以更改节点数量。如果数据量大，时间会很长，甚至几天。修改一旦开始，就不能停止。如果有大量数据都存放在 S3，那么可以重建 EMR，甚至使用自定义 AMI，数据也不会丢失。

Q: EMR 出现磁盘容量不足。

A: EMR 上的应用，在可能的情况下，尽量使用 S3 替代 HDFS，不用占用本地存储。

/mnt /mnt1 这些本地目录一般用于存储临时数据和日志。有时候临时数据没有清理，会出现这些目录占满磁盘。需要经常清理，或者运行自定义 Cloudwatch 磁盘使用率监控脚本，当磁盘不足时，自动发送通知。

Q: 如何把 S3 多个小文件合并成大文件？

A: s3distcp 运行MR任务，把 S3 或者 HDFS 的多个文件合并。例如：

s3-dist-cp --src s3://support-billing/ --dest s3://pingaws-support/billing/ --groupBy='.*(794767850066*?).*'

AWS 常见问题汇总，首发于服务器安全维护工作室。

除了提供IP资源及网络连接，Amazon VPC还提供DNS及DHCP等基础设施服务。当您将实例启动到默认 VPC 中时，我们为实例提供与其公有 IPv4 和私有 IPv4 地址对应的公有和私有 DNS 主机名。当您在非默认 VPC 中启动实例时，我们会为实例提供私有 DNS 主机名，并根据您为 VPC 和实例指定的设置来决定是否提供公有 DNS 主机名。

对于 us-east-1 区域，公有 (外部) DNS 主机名采用 ec2-<public-ipv4-address>.compute-1.amazonaws.com 形式，对于其他区域，则采用 ec2-<public-ipv4-address>.region.amazonaws.com 形式。例如，公有IP为54.222.212.110的EC2实例，其公有DNS名为ec2-54-222-212-110.cn-north-1.compute.amazonaws.com.cn。我们将公有 DNS 主机名解析为该实例在所在网络外的公有 IPv4 地址及其在所在网络内的私有 IPv4 地址。

私有 (内部) DNS 主机名解析为实例的私有 IPv4 地址，并对 us-east-1 区域采用 ip-<private-ipv4-address>.ec2.internal 形式，对其他区域采用 ip-<private-ipv4-address>.region.compute.internal 形式 (其中 private.ipv4.address 是反向查找 IP 地址)。例如，私有IP地址为10.206.2.239的EC2实例，其私有DNS名为ip-10-206-2-239.cn-north-1.compute.internal。您可以使用私有 DNS 主机名在同一网络中实现实例之间的通信，但我们无法解析实例所在网络之外的 DNS 主机名。要解析实例所在网络之外的主机名，可自建DNS服务器来为VPC及外部网络提供DNS服务。

常见的应用场景是在混合IT架构下，客户数据中心通过VPN或是Direct Connect专线连接到AWS上的VPC，在VPC中配置1台DNS服务器，在客户数据中心也配置1台DNS服务器，服务器的主从角色客户可自行定义。通过多台DNS服务器为不同位置的客户端提供DNS服务，即能保证服务的高可用，又能就近提供服务，减少DNS查询延迟。

接下来，我将基于上述架构图一步一步说明如何使用BIND搭建DNS服务器。本文不会涉及BIND的高级配置，如需了解BIND的高级配置，可参考BIND官方网站。

安装配置DNS主服务器

首选需要准备一台EC2实例用于安装BIND软件，如何创建EC2实例可参考Amazon EC2入门指南。本次示例选用Amazon Linux操作系统的AMI来创建实例，实例类型选用了通用型实例类型: m4.large。BIND对服务器硬件资源要求不高，在不启用DNSSEC的情况下(不在本文讨论范围)，普通配置的服务器即可承载DNS服务。m4.large配置有2颗vCPU和8G内存，运行DNS服务能够支持中等规模的DNS请求，当请求增加时，也可方便的调整实例类型到更大的配置。

创建EC2实例时需要指定安全组来开放服务端口，DNS服务通过UDP 53端口提供DNS查询相应，通过TCP 53端口提供区域传送。因此，安全组队VPC网段开放UDP 53端口，对客户数据中心的DNS服务器开放TCP 53端口，如下图所示：

DNS服务器作为基础设施服务的重要性无须多言，Amazon EC2持续监控EC2实例的状态以及底层硬件的状态，分别称为实例状态检查和系统状态检查。我们可创建状态检查报告，当任一状态检查失败时，执行重启操作，并将警报发送至指定邮箱。

创建好警报之后，通过SSH登陆至EC2实例，并yum命令安装bind软件：

yum install bind-utils bind

安装好之后，我们接下来将创建一个示例的DNS域：aws.local，我们首先需要编辑/etc/named.conf文件，修改以下内容：

listen-on 缺省配置为127.0.0.1，DNS服务只会绑定到系统的环回接口，其他客户端无法访问，需要添加EC2实例的私有IP地址，才能提供外部访问

allow-query缺省配置为localhost，即只允许DNS服务器所在的EC2实例对自己进行DNS查询，添加VPC的网段可允许来自VPC内部的主机进行DNS查询。注：也可将此参数设置为0.0.0.0/0，因为前面安全组设置里只允许了VPC内的IP访问UDP 53端口。

此外，还需要增加对aws.local这个域的定义，在/etc/named.conf中增加以下内容，allow-transfer指定了只允许从DNS服务器进行区域传送，限定允许区域传送的范围颗可提高DNS服务的安全性：

上述配置说明aws.local域的具体解析配置在文件/var/named/aws.local.db 里，其内容如下，在这个示例配置中，定义了两条A记录，分别是dns.aws.local对应10.206.0.212和www.aws.local对应10.206.0.213

配置Amazon VPC使用自建DNS服务器

Amazon VPC通过DHCP服务为VPC中的EC2及其他连网组件动态分配IP地址，动态主机配置协议 (DHCP) 提供了将配置信息传递到 TCP/IP 网络中主机的标准。DHCP 消息中的options字段包含配置参数。这些参数包括域名、域名服务器以及“netbios-node-type”。接下来我们将创建一个新的DHCP选项集，并在选项集中将域名服务器指向刚才创建的DNS服务器。

在AWS控制台中选择VPC服务，并在左边的菜单中选择“DHCP选项集”，点击“创建DHCP选项集”按钮，输入以下信息，域名服务器可指定多个DNS服务器，按照顺序第一个为VPC内的DNS服务器，第二个为客户数据中心的DNS服务器：

创建好DHCP选项集之后选择左边菜单中“您的VPC”选项，选中要修改的VPC，从“操作”下拉菜单中选择“编辑DHCP选项集”

选择刚才创建的DHCP选项集并保存：

在您将新的 DHCP 选项集与 VPC 关联之后，任何现有实例以及您在 VPC 内启动的所有新增实例都将使用这些选项。 无需重新开始或重新启动实例。根据实例更新 DHCP 租赁权的频率，它们会在几个小时内自动拾取更改。如果您愿意，您也可以使用实例上的操作系统，直接更新租赁权。

安装配置DNS从服务器

在客户数据中心安装配置DNS服务器的步骤与在Aamazon EC2中安装配置DNS服务器的步骤相同，除了/etc/named.conf的配置稍有差别：

从服务器的type类型为slave，file参数对应的域配置文件会自动根据从主DNS服务器接收到的更新来进行创建和更新，masters指定aws.local域的主域名服务器，最后一个参数allow-transfer禁用了区域传送。

配置好从DNS服务器之后，可将客户数据中心内的连网设备设置为从DNS服务器，第二DNS服务器设置为AWS上的主DNS服务器。

总结

Amazon VPC提供DHCP服务和DNS服务，为VPC中的EC2实例提供IP地址分配和域名解析服务，为每个EC2实例创建特定格式的DNS域名。如果用户希望使用自定义域名，或者希望使用一套域名统一管理云上和云下的资源，可自行搭建DNS服务器来提供DNS解析服务，Amazon VPC能够支持客户。

在Virtual Private Cloud中自建基于BIND的DNS服务器，首发于服务器安全维护工作室。

随着云的普及以及即用即付的模式，正在被大家逐渐接受，那么在初期从原始数据中心到云迁移的过程中，为了保证数据的平稳迁移，并不推荐将应用以及数据库一次性的迁移到云中。所有项目都应该分阶段来进行，阶段迁移的情况下就必须要将云资源与本地数据中心的资源互连互通。

要做到互连互通，有三种备选方案，互联网，专线直连（DX）和 VPN。从三个方面比较下这三种解决方案，安全，稳定性以及费用。DX 服务无疑是最优的一种解决方案，提供安全稳定的网络性能，高吞吐量。由于国内专线铺设所带来的高昂费用，所以在初期阶段，DX 并不是一个最优的。这里面互联网是最便宜的，因为本身数据中心就已经支付了这部分费用，只要保证云中的资源可以上互联网就可以了，但互联网面临的问题是网络依赖互联网，互联网的网络性能并不是可控的，另外一方面是互联网的安全性。VPN 呢是基于互联网的服务，虽然不能保证网络性通的可控，但可以做到数据的安全。

就以上比较而言，在初期阶段，VPN 无疑是一种高性比的安全以及节约成本的方案。考虑到目前北京区域并不支持硬件VPN的服务，即Global区域的VPN Connection。那么有没有可以替代的方案呢？答案是肯定的，一切问题都难不倒我们伟大的开源组织，开源方案如 OpenSwan （今天的主角），StrongSwan，Raccoon等等了。除了开源的解决方案外，还有一些商业解决方案，比如Sanfor 深信服，Hillstone 山石，Checkpoint , Cisco CSR1000v等也可以部署，有兴趣的可以与相应的软件提供商联系。

前面说了那么多关于VPN的各种软件，那么该如何选择呢？这里我们从使用上来划分下吧，将VPN主要划分为两类，一类是工作于客户端到服务端的模式，像OpenVPN，SSL VPN，L2TP，PPTP这些都是需要客户端主动发起连接，拨到Server端在两者之间建立一个逻辑上的隧道 (tunnel)进行通信。这种方式一般适用于个人到总部场景。服务器是无法主动发起连接到客户端。

另外一种就是站点到站点（site-to-site）的模式，像OpenSwan，StrongSwan， Raccoon 等软件，这种情况下两端会各有一个设备负责来建立两个站点之间安全通信的隧道，任何需要到对端的通信都会触发设备来建立安全隧道通信。

那么公司原有数据中心与云通信都是双向通信，所以站点到站点更合理。

实际上这里说的 VPN 即是指 IPsec VPN，IPsec 是一种工业标准，只要支持这种标准的设备都可以互相协商建立一个安全的隧道出来，比如支持的硬件设备有路由器，防火墙以及专业的 VPN 设备。

说了这么多，下面我们就以 AWS 端为 OpenSwan 与 Cisco 的路由器之间的配置为例。

场景及拓扑

拓扑如上图，AWS端建立一个VPC（CIDR：192.168.0.0/16），包含两个子网，一个可以上互联网的Public子网192.168.1.0/24以及私有子网Private 192.168.2.0/24。在公有子网上会配置一台OpenSwan实例与公司的Cisco设备做VPN连接。

OpenSwan的EIP地址为54.223.152.218 子网：192.168.1.0/24

Cisco设备的公网地址为54.223.170.5 子网：10.1.2.0/24

目标：实现AWS上私有子网192.168.2.0/24和数据中心10.1.2.0/24双向互通

详细配置步骤

1.配置 VPC 基础环境

1.1 创建 VPC

在AWS console界面点击VPC，在左侧点击“您的VPC”, 创建VPC

名称标签： MyVPC

CIDR块： 192.168.0.0/16

租赁：默认

1.2 创建子网

将鼠标点到子网，选择创建子网

标签名称：Public

VPC：选择第一步创建好的VPC

可用区：保持默认

CIDR块：192.168.1.0/24

以同样的方法创建一个192.168.2.0/24的子网

1.3 创建路由表

点击路由表，创建路由表

名称标签：PrivateRoute

VPC：选择1.1创建好的VPC

创建完成以后，点到刚刚创建好的路由表，在页面下列点击子网关联，点击编辑

在192.168.2.0/24的路由前打勾，点击保存。

1.4 创建 IGW

点击Internet网关，创建Internet网关

名称标签：MyIGW

创建完成，点击附加到VPC

选择新创建好的VPC

2. 启动并配置 VPN 实例

2.1 启动实例

到EC2页面，点击启动实例。选择Amazon Linux

在详细信息页中，网络请选择新创建的VPC

子网选择192.168.1.0/24

点击下一步，存储标签等按需配置

配置安全组，选择创建一个新的安全组

添加规则

自定义的UDP规则，端口500 来源任何位置

自定义的UDP规则，端口4500 来源任何位置

自定义协议， 协议 50 来源任何位置

所有流量 来源为 192.168.2.0/24

注意：一定要放行来自于192.168.2.0/24的流量，否则无法通信。

最后审核启动，启动时指定一个用于登陆实例的key文件,如果没有创建一个新的。

2.2 配置弹性 IP （EIP）

在EC2页面，左侧导航栏找到弹性IP，申请分配新地址，并将其关联到新创建的OpenSwan实例。这里申请到的为 54.223.152.218。

2.3 关闭源/目的检查

在EC2页面点击OpenSwan实例，右键选择联网，更改源/目标检查，点“是，请禁用”

3. 安装配置 OpenSwan

3.1 登录到实例安装 OpenSwan

如何登陆实例请参考如下文档：

https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/putty.html

登陆完成以后，运行如下命令安装OpenSwan

$ sudo yum -y install openswan

3.2 根据Cisco 参数来配置 OpenSwan

修改/etc/ipsec.conf去掉最后一行include /etc/ipsec.d/*.conf 的注释

$ sudo vim /etc/ipsec.conf

include /etc/ipsec.d/*.conf

Cisco路由器的配置如下：

crypto isakmp policy 10

encr aes

authentication pre-share

group 2

crypto isakmp key aws123 address 54.223.152.218

!

!

crypto ipsec transform-set OpenSwan esp-aes esp-sha-hmac

mode tunnel

!

!

!

crypto map OpenSwan 10 ipsec-isakmp

set peer 54.223.152.218

set transform-set OpenSwan

match address 100

!

!

interface GigabitEthernet1

ip address 54.223.170.5 255.255.255.252

ip mtu 1400

ip tcp adjust-mss 1360

crypto map OpenSwan

!

access-list 100 permit ip 10.1.2.0 0.0.0.255 192.168.2.0 0.0.0.255

ip route 0.0.0.0 0.0.0.0 54.223.170.6

根据cisco的配置创建OpenSwan的配置如下：

$ sudo vim /etc/ipsec.d/cisco.conf

conn cisco

authby=secret

auto=start

leftid=54.223.152.218

left=%defaultroute

leftsubnet=192.168.2.0/24

leftnexthop=%defaultroute

right=54.223.170.5

rightsubnet=10.1.2.0/24

keyingtries=%forever

ike=aes128-sha1;modp1024

ikelifetime=86400s

phase2alg=aes128-sha1

salifetime=3600s

pfs=no

配置解释：

leftid 标明本地对应公网IP

letftsubnet为本地子网

right为对端公网地址

rightsubnet为对端子网

ike为第一阶段参数

ikelifetime为第一阶段的生存时间

phase2alg为第二阶段参数

salifetime为第二阶段生存时间

结果如下图：

配置预共享密钥：

$ sudo vim /etc/ipsec.d/cisco.secrets

54.223.152.218  54.223.170.5: PSK “aws123”

启动openswan服务并做配置检查

$ sudo service ipsec start

$ sudo ipsec verify

3.3 修改系统参数

更改系统参数做IP转发并关闭重定向功能

编辑/etc/sysctl.conf内核配置文件，做如下修改

$ vim /etc/sysctl.conf

$ vim /etc/sysctl.conf

net.ipv4.ip_forward = 1

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.eth0.send_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.eth0.accept_redirects = 0

配置完成以后，启用新的配置

$ sudo sysctl –p

3.4 更改 OpenSwan 的网卡 MSS 值

$ sudo iptables -t mangle -A FORWARD -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1387

3.5 修改 VPC 私有子网路由表

找到VPC Console页面，在左侧点路由表，找到192.168.2.0/24关联的路由表（1.3中创建）， 在页面下方点击路由，编辑

添加其他路由，

目标： 10.1.2.0/24

目标：OpenSwan实例ID (i-xxxxx)

4. 测试连通性

以上步骤都完成以后，就可以在192.168.2.0网段的实例进行测试了。使用 ping 测试到 10.1.2.x private 私有地址段的一个地址。

ping 10.1.2.3

检查 IPsec tunnel 状态：

$ sudo service ipsec status

IPsec running - pluto pid: 25674

pluto pid 25674

1 tunnels up

some eroutes exist

常见问题及排错

1.  IPsec Tunnel 没有正常建立

首先检查到对端 IP 是否可以通信，检查安全组是否放行 IKE 需要的端口 UDP 500。如果网络层没问题，检查各项参数配置是否有错误。

2. 隧道建立成功，但是无法进行通信

首先检查 IP forward 是否设置为 1？VPN 实例安全组是否放行了相应的策略？路由是否正确？NAT 是否影响？

3. NAT 问题

如果您的 CGW 配置了 NAT 与 VPN 工作，根据厂家不同对 VPN 包的处理顺序不一致，如果源 NAT 在 VPN 之前被处理了，因为源地址发生了改变，所以也就不会再被 VPN 处理，造成通信失败。像 Cisco 设备就需要做 NAT 的例外策略。主流的 Cisco ASA 就需要做相应修改，参考如下：

8.2 及以前的版本：

nat (inside) 0 access-list nat_exemption
access-list nat_exemption extended permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0

8.3 及更新的版本：

object network obj-192.168.1.0

subnet 192.168.1.0 255.255.255.0

object network obj-10.0.0.0

subnet 10.0.0.0 255.255.255.0

nat (inside,any) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-10.0.0.0 obj-10.0.0.0 no-proxy-arp

如果您经过以上步骤还是不能成功搭建 VPN，AWS Support 提供专业化的技术支持，可根据您当前或计划的使用案例为您提供一套独特的工具和专业知识。建议您开案例联系Support 技术支持。

如何在AWS上构建基于 OpenSwan 的软件 VPN 解决方案，首发于服务器安全维护工作室。

1     构建混合云的关键技术点

1.1   网络连接

第一点，公有云具备用户自定义网络的能力。这里自定义网络泛指云上的私有网络，Amazon VPC允许企业用户在AWS云上自定义逻辑隔离的专用网络的能力，包括允许用户可以自行划分子网、配置路由，设置公网、VPN网关等基础能力。

第二点，多样、稳定的网络接入能力。混合云最突出的特点就是连接，连接方式主要分为两种：公网接入和专线接入。

为保护用户的信息安全，公网接入在Internet上的流量通常需要经过IPsec VPN加密，AWS提供了托管VPN服务和用户自建VPN两种方式，如果采用用户自建方式，一般小型VPN网关（200Mbps以下）可以通过虚拟软件VPN网关实现，中或大型VPN网关（300Mbps及以上）可通过硬件VPN网关设备实现。VPN部署一般半天即可完成，可以快速满足企业用户需求。

AWS Direct Connect（简称DX专线）为企业上云提供了专线接入能力，能够全时段、全方位的保障用户数据传输隔离加密，并保证可用网络带宽，用户无需担心容量太大而无法承载的问题。

示图1：AWS DX专线与VPN混合组网示意图

1.2   安全与监控

混合云在网络层面上将私有云和公有云进行了连接，如果发生网络故障或者攻击，需要有能力保障网络间故障不会相互影响，将攻击或者故障限制在一定范围之内。云上的网络环境需要具备灵活、易配置的网络安全访问控制能力。Amazon VPC提供了有状态的EC2实例级别的网络防火墙功能（安全组），还则提供了无状态的子网级别的网络访问控制（网络ACL）。

监控方面，Amazon VPC 提供了流日志（flow log）功能，可以利用此项功能来捕获传入和传出的网络IP流量信息。流日志数据使用 Amazon CloudWatch Logs 存储，创建流日志后，用户可以在 Amazon CloudWatch Logs 中监控和查看其VPC网络的流量传入和传出状态，并可通过CloudWatch预设告警策略以及时反馈网络异常。VPC流日志还可以帮助用户排查网络故障等问题，比如流量为什么没有进入到EC2实例的原因。另外，针对VPC流日志的分析，可以帮助检查AWS云上的网络安全设置，消除网络安全漏洞。

1.3   统一服务，混合云管理平台

云管理平台的定义是Gartner提出来的，总结起来就是两块，第一是管理，管理公有云、私有云，形成混合云。第二是自服务，镜像划分，计量与计费，以及基于策略的负载优化。云管理平台最终的目标是应用在云平台上运行时取得最优化的效果。

企业用户构建混合云平台之后，首先需要解决的就是服务门户的统一，资源状态监控界面的统一，在一个平台上实现本地数据中心（或私有云）和公有云资源的统一申请、统一审批、统一监控、统一计费。这样能够大幅度降低用户跨平台切换带来的复杂运维工作量，让用户跨平台的资源使用与监控更加方便。

示图2：混合云管理平台（CMP）功能示例图

2     常见的混合云应用场景

2.1   利用AWS公有云应对业务的爆发式增长

大多数互联网业务呈指数型增长，很难预测基础设施的储备量。一般在业务成长初期很长一段时间内，小规模的物理机托管可以满足用户需求。但随着市场推广活动展开，业务规模爆发增长，原物理托管机房可部署机位有限，只能选择公有云作为弹性手段，快速部署业务，满足用户需求。

今天已经有越来越多的企业用户将他们的互联网业务系统，诸如电子商务系统、Web网站、移动端产品和信息订阅服务系统迁移到AWS云上。应对业务规模爆发增长的用户需求，AWS云服务采用多种方式确保应用系统的可靠性和稳定性，作为最基础的云服务，Amazon EC2提供了大小可调的计算容量，用户可以根据自己的实际需求，完全控制所需的计算资源。配合AWS的Auto Scaling功能，用户可以按照事先设定的条件自动扩展Amazon EC2容量，确保所使用的Amazon EC2数量在需求峰值期间实现无缝增长以保持性能，同时也可以在需求平淡期间自动减少Amazon EC2数量以降低成本。此外，Elastic Load Balancing可以在多个Amazon EC2实例之间自动分配应用程序的访问流量，也可以检测出系统中不健康的实例并自动更改路由，将应用的访问流量导向健康的实例。通过不同功能云服务之间的组合，AWS云平台可以确保应用系统的高可靠性和稳定性。

示图3：混合云架构下的电商平台三层系统架构图

与早期基于传统数据中心的系统相比，依托AWS云平台的新系统在稳定性、可靠性和响应速度等方面都有了极大的提升，同时大幅度降低了固定资产投资(CAPEX)和运营成本（OPEX）。在传统数据中心模式下，用一台服务器的寿命大约为5年来计算，购入一台与Amazon EC2 c3.4xlarge机型（16 vCPU,30 GB 内存）配置对应的物理服务器，加上网络和托管费用， 核算出5年的总费用；如果按这个需求迁移到AWS云平台后，企业用户在总费用上可以节省20%。

使用AWS云服务也大幅度降低了用户的运营成本。在传统数据中心模式，企业用户的运维团队工作任务繁重，需要做很多简单、重复的工作，比如服务器的上下架、系统重装、硬件检修等。采用AWS云服务之后，运维人员可以把主要精力放在研究和部署更好的技术架构和方案上，提升了工作效率，减少了人力投入，运维人员的人力成本可以节省一半左右。

2.2   利用AWS公有云实现多地容灾的高可用架构部署

与前一类用户不一样，很多企业用户已经具有很大规模，在本地数据中心或运营商机房中运行大量服务器，他们的核心问题不再是担心基础设施部署速度无法满足业务增长，更多的是从稳定性、可靠性等寻求从单中心向多中心化发展，通过消灭单点，解决单数据中心故障带来的业务风险。

根据业务可靠性要求不同，一般多地容灾常见的采用方式有同城容灾、异地双活、两地三中心等。按照传统建设模式，用户只能重新选址并租赁数据中心，发起服务器、网络设备采购，部署网络环境等，中间涉及到一系列的商务沟通、基础设施建设等操作，周期往往从6个月到1年不等。而在公有云蓬勃发展的今天，他们可以不必担心此类问题，直接注册个账号，购买服务器，拉个专线，基础架构就搞定了。

AWS的混合云容灾架构，就是在AWS的云环境中实现“两地三中心”，同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。AWS云资源池通过软件定义的方式，能够打造与企业内部完全相同的复杂IT环境，实现企业级应用的完整镜像。

成立于2005年的IGG，是全球领先的手机游戏开发商及运营商，为全球游戏玩家提供游戏和相关服务。为了给玩家提供最佳的用户体验，IGG需要在全球多个区域部署服务器。在使用AWS云服务之前，IGG拥有自建的机房，同时也采用多家公司的主机租用服务。随着业务的快速发展，原有的服务部署模式开始面临多方面的挑战，主要体现在三个方面：其一是服务器资源管理不方便、扩展性和灵活性受限制，当访问峰值来临时，部署新服务器的周期较长，而当某款游戏的访问量暂时降低时，又会造成已有服务器资源的浪费；其二是开发和运营新游戏时难以控制成本，因为对游戏运营公司来说，一款游戏是否成功受很多因素的影响，但在运营每一款新游戏时都需要投入大量的IT资源，万一不成功，则会浪费已购置的服务器资源；其三是如何建立双活的灾备系统以确保在任何情况下都能为全球玩家提供持续可靠的服务。

为了应对这些挑战，IGG开始考虑采用公有云服务作为自有数据中心（下面简称：自有IDC）的补充。经过考察、分析和对比，IGG决定采用AWS云服务，并从几年前开始尝试使用AWS在新加坡、法兰克福、日本、美国等可用区的云服务部署海外游戏节点。2016年8月，为了提升整个游戏运营系统的稳定性和可靠性，IGG决定为其位于北加州的核心业务系统建立双活灾备系统。使用AWS云服务给IGG带来的最大好处是用较低的成本建立起远程的双活灾备中心，实现了核心业务异地实时同步备份，在主机房出现故障时能快速切换到云端，保证服务的连续性。整个灾备系统完全满足IGG的业务需求：RTO不超过30分钟、RPO为0，增强了IGG游戏运营系统的稳定性和可靠性。除此之外，使用AWS云服务也节省了灾备系统的成本，因为利用AWS云服务建立双活灾备系统时并不需要1:1的资源配置，这点相比传统的本地灾备具有极大的性价比优势。

示图4: 基于AWS云服务的IGG双活灾备中心

AWS混合云容灾架构的用户价值: 从容灾系统的TCO上看，AWS混合云容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装，省去了大量前提投入成本。更重要的是，容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源，对于不开机的资源将完全不收取EC2虚拟机资源的费用，又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算，一个典型的容灾系统项目，以5年为周期进行计算，TCO只需花费原有私有云容灾环境的1/3，而第一年的投入资金更是传统项目的1/10。

另外，随着应用容灾系统迁移至AWS云中，可以将企业现有的容灾中心转变成生产中心，从而扩大客户自建数据中心的承载能力，或大幅降低IT资源的运营成本，享受更多AWS云带来的好处。下图从AWS混合云容灾开始，到容灾切换，到生产系统平滑上云的进阶演进图：

 示图5：AWS混合云容灾，到容灾切换，到生产系统平滑上云的进阶演进图

2.3   利用AWS公有云实现混合云备份

将数据备份到云端的好处显而易见：管理和操作更加便捷，无需搭建IT备份系统架构、将一次性大额支付变为每月或每年的按需付费，进而减少企业对IT资源的投入等等。现在越来越多的企业客户更倾向于通过其现有的备份软件或云网关，将其现有的备份体系架构扩展到云上。这样做的好处可以用云备份替换离线磁带，大大降低本地存储的资源开销，利用云端完成备份工作，更具性价比。

AWS Storage Gateway （又称“AWS存储网关”，架构图见示图6）是AWS提供的一种混合云存储服务，企业本地数据中心的内部应用程序可以借助它来无缝地使用 AWS 云上的存储资源（如S3，Glacier等），AWS存储网关可以帮助企业用户实现本地数据中心向AWS云端进行备份、存档、灾难恢复、云突增、分级存储分层和迁移。并具有无缝集成能力，企业应用程序或备份工具可以使用 NFS、iSCSI 等标准存储协议通过本地存储网关镜像设备连接到AWS云端的该存储网关，同时存储网关连接 Amazon S3、Amazon Glacier、Amazon EBS 等 AWS 存储服务，可实现文件、卷和虚拟磁带的存储或备份。

示图6：AWS存储网关服务架构示意图（Gateway-Cached Volume）

AWS存储网关具有高度优化的数据传输机制，能够进行带宽管理、自动实现网络弹性、高效传输数据，并为活动数据的低延迟本地访问提供本地缓存。

当然从企业用户的混合云备份需求角度，通常需要考虑：

• 如何实现对于虚拟机和物理机进行统一管理?
• 如何缩短备份时间?
• 如何快速恢复? 能否恢复到任何环境（如物理机,虚拟机,云中的虚拟机） ?
• 能否确保备份与恢复数据的完整性及安全性?
• 如何实现冷热数据的分级存储，降低云上的存储成本？
• 如何避免重复备份数据?

目前已经有很多国内外备份服务厂商基于AWS存储网关构建了一体化AWS混合云备份方案，利用AWS云存储资源便宜的特点帮助企业用户实现AWS云端备份，而且方案能很好的满足前述提到用户对混合云备份的要求。下图为国内某备份服务厂商基于AWS存储网关的混合云备份解决方案。

示图7：国内某备份服务厂商基于AWS存储网关的混合云备份解决方案

该备份服务厂商的AWS混合云备份解决方案具有如下优势和技术特点：

• 操作简便：提供功能丰富，操作简便的用户界面，支持手工备份、时间计划、多任务多计划、备份状态监控、版本管理、恢复操作、并提供一键式故障转移切换功能。
• 块级别全局重复删除数据：基于源端的重复数据删除技术，相同数据块仅发送和存储一次，可以减少备份时间80%以上，这不仅带来效率的提高、带宽、存储空间的节约；还保证窄带宽条件下大数据异地灾备。
• 瞬间恢复：通过Snapshot技术，保证备份期间不需要关闭应用，定时对发生变更的数据块进行标记并实施迁移 （最小支持一分钟），在下一个备份时间点只检索被标记的数据块，这不仅节省磁盘IO，并且能够瞬间恢复数据。
• 冷热数据分级存储功能：充份利用Amazon S3提供的生命周期管理策略的功能，用户通过简单的策略制定就可以自动化实现冷热数据的分级存储，冷数据自动归档存储到更便宜的Amazon Glacier上，既实现了用户长期归档的需求，还可以大幅降低云上的存储成本。
• 支持Windows/Linux/Unix等多种环境的网络集中备份，同时支持多种应用服务类型，如各种常见的应用服务器、数据库（如MySQL、SQL Server、Oracle、Sybase、DB2）、 Domino、AD、Exchange、File server等等。
• 三重数据安全：

1. 硬盘锁：数据与设备进行绑定，数据只能恢复到原有硬件
2. 无规则存放：数据以无规则的块存储，避免坚守自盗
3. 通信与数据加密：私有通信协议,可选AES数据加密

• 异地灾备与恢复: 备份到异地云计算中心，支持恢复到本地物理机、虚拟机、AWS云上虚拟机等多种不同平台，当本地数据中心出现物理故障时，这种异地恢复机制既可以满足企业用户异地灾备恢复的需求，还可以实现数据异地使用的业务价值。
• 传输优化：经优化的灾难恢复和复制，几分钟内返回到联机状态。

AWS之旅：混合云构建及常见的应用场景，首发于服务器安全维护工作室。