产品亮点

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

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

在本文中，我们将向您展示如何使用 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 角色，首发于服务器安全维护工作室。

背景

随着移动互联网的发展，越来越多的图片分享、短视频、在线直播等应用越来越火，如何安全、经济高效、低延迟的将内容分发到终端用户受到开发者越来越多的关注。内容分发网络（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 配置，首发于服务器安全维护工作室。

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

错误一  源访问权限未放开

这种错误常见于用S3做源的情况, 引起这种错误的原因是s3的访问控制没有对CloudFront开放。从浏览器中返回的错误通常类似于下图：

更具体些，可分为以下两个场景：

场景1. CloudFront使用了Restrict Bucket Access

在创建distribution的时候选择了Restrict Bucket Access 为yes, 但 Grant Read Permissions on Bucket, 选择的是”No, I Will Update Permissions”， 而用户事后却没有在s3的桶里更新policy。如下图所示。

解决方法：

方法1, 在S3中增加桶的策略，使该桶允许该CloudFront访问，以下是policy示例，其中标黄部分需要替换成用户自己的信息。

{

                "Version": "2008-10-17",

                "Id": "PolicyForCloudFrontPrivateContent",

                "Statement": [

                                {

                                                "Sid": "1",

                                                "Effect": "Allow",

                                                "Principal": {

                                                                "AWS": "arn:aws:iam::CloudFront:user/CloudFront Origin Access Identity E344H6KAFBMK0I"

                                                },

                                                "Action": "s3:GetObject",

                                                "Resource": "arn:aws:s3:::elastictcoutputthumb/*"

                                }

                ]

}

方法2, 重新创建distribution, 新建的distribution中Grant Read Permissions on Bucket选择yes, Update bucket policy， 这样当distribution创建完成后，s3桶的policy会被自动更新。

场景2. 普通的S3回源

CloudFront 并未使用Restrict Bucket Access, 这种情况下如果s3中的对象没有设置成可被公共访问，也会出现Access Denied的错误。

解决方法：

可以通过设置s3桶的bucket policy或者设置s3中对象的Object ACL来实现。 例如，通过 AWS 控制台设置存储桶的bucket policy:

通过 AWS 控制台设置S3对象的Object ACL:

注：如果想了解S3访问控制的详细内容，请参考：http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

错误二 使用自定义域名但未在CloudFront中配置

用户有时不直接使用CloudFront的distribution产生的域名，而是使用了自定义的域名并用CNAME的方式指到CloudFront的域名, 例如使用cdn.mydomain.com  CNAME到d1cbzf61pdxxxx.CloudFront.net。此外，如果使用Route53作为DNS, 也可以不采用CNAME的方式，而是采用Alias的方式。

CloudFront规定当使用自定义域名并配置该域名使用CNAME或Alias的方式指向CloudFront distribution的域名的时候，需要在CloudFront相应的distribution中提供该自定义的域名，如果使用了多个自定义的域名，则提供多个自定义的域名。如果没有提供，就会出现类似下图的错误：

解决方法：

可以通过AWS控制台，对distribution中的Alternate Domain Names(CNAMEs)进行设置：

错误三 访问路径错误

配置完CloudFront的Behavior后，用户有时不能给出正确的url来访问想要的资源。 出现访问错误, 如果是回源s3, 返回的错误通常如下：

如果是回源的自定义网站，返回的错误根据网站的不同而不同，例如：返回”找不到相应的页面”等错误。

解决方法：

避免这种错误很简单，了解CloudFront Behavior的url与所访问的源站资源的对应方法，即可判别自己的url是否正确. 以下举例说明：

某Behavior如下，该Behavior对应的origin ID是S3-hxybucket/Picture:

进入到Origin查看,可知Origin Domain Name and Path是hxybucket.s3.amazonaws.com/Picture

如果通过d1cbzf61pdxxxx.CloudFront.net/dog.jpg访问的话， 对应的源站资源是hxybucket.s3.amazonaws.com/Picture/dog.jpg

如果通过d1cbzf61pdxxxx.CloudFront.net/jpg/dog.jpg访问的话，对应的源站资源是hxybucket.s3.amazonaws.com/Picture/jpg/dog.jpg

即: 将CloudFront域名后面的路径追加到Origin Domain Name and Path (注意，除了Domain Name之外，还有Path) 所对应的路径后面, 就是对应到源站的资源, 用户通过该路径即可判断所使用的url是否正确。

错误四 HTTP Method 设置不当

在创建Behavior的时候， allowed http methods选项的默认值是GET和HEAD, 有时用户会使用其他的HTTP method, 例如POST, 此时如果还是用默认值，就会出错，返回的错误通常如下：

“This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.”

解决办法：

办法很简单，在Behavior中重新设定一下Allowed HTTP Methods选项，使其包含所用的HTTP Method.

错误五 设置了Restrict Viewer Access 却没有使用Signed URL或Signed Cookie

在创建Behavior的时候，Restrict Viewer Access (Use Signed URLs or
Signed Cookies)选项的默认值是No, 如果用户改成了Yes, 此时该Behavior对应的资源必须使用Signed URL 或者Signed Cookie的方式访问，如果使用普通的Url访问，返回的错误通常如下：

解决方法：

方法１.使用signed url 或signed Cookie进行访问，具体参考：http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html

方法2. 将Restrict Viewer Access (Use Signed URLs or
Signed Cookies)的值改为No。如图：

错误六  Object Caching 设置不当

虽然能够访问到源，但有时用户会反映使用了CloudFront并没有加速访问，有时甚至效果还不如未使用CloudFront时。 这很可能是由于Object Caching设置不当造成的。

解决方法:

Object Caching有两个选项，分别是Use Origin Cache Headers 和 Customize。默认选项是前者。但是，当默认选择了Use Origin Cache Headers，而源的HTTP header中却没有Cache-control的头，那返回内容就不被缓存了。 因此，用户需谨慎选择，当源的返回值中没有Cache-control头的情况下，选择Customize，Customize中的Default值将会成为TTL时间(时间单位是秒)。

另外，如果源的返回值中存在Cache-control，而Object Caching又选择了Customize, 这种情况下返回的内容肯定会在CloudFront边缘节点中被缓存。但CloudFront会使用哪个值作为TTL呢？ 这个在CloudFront 文档中有详细的描述， 详见： http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

Amazon CloudFront常见错误配置及解决方法，首发于服务器安全维护工作室。

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 – 持续安全监控和威胁检测，首发于服务器安全维护工作室。

ELB(Elastic Load Balancer)

Amazon ELB(Elastic Load Balancer)，是AWS提供的弹性负载均衡器，可根据实际情况为外部访问分配最合适的服务器。在实际使用过程中，会需要对经由ELB的客户端访问加以限制，本文将介绍如何通过配置EC2实例来实现对此类客户端的限制访问。

如图所示，由于ELB不属于安全组，所以对于安全组实施限制并不会对ELB生效，经由ELB的客户端访问依然可以抵达EC2。

然而倘若限制ELB访问EC2，ELB对EC2发出HealthCheck（健康检查）动作时，ELB将无法访问成功检查，而判断该EC2出现异常情况。所以只有通过在EC2实例上的Web服务器上配置访问限制，才能对经由ELB的客户端访问加以限制。

可是在对访问的客户端实施限制时，由于访问全部经由ELB，则检知的访问IP均为ELB的IP，此时需要借助XFF头（X-Forwarded-For）实施确认和限制。

举例说明

1.只允许地址为172.24.40.83的IP访问该网站。

编辑网站配置文件，添加或修改配置文件如下：

SetEnvIf X-Forwarded-For "172.24.40.83" allow_ip
Order deny,allow
Deny  from all
Allow from env=allow_ip

2.拒绝地址为172.24.40.83和17224.40.84的IP访问该网站。

编辑网站配置文件,添加或修改配置文件如下：

SetEnvIf X-Forwarded-For "172.24.40.83" deny_ip01
SetEnvIf X-Forwarded-For "172.24.40.84" deny_ip02
Order allow,deny
Allow from all
Deny  from env=allow_ip01
Deny  from env=allow_ip02

X-Forwarded-For的功能是在ELB接受客户端的请求后，分配到EC2时在数据包的尾部添加上真正客户端的IP地址。

采用Apache的Web服务器，通过mod_extract_forwarded的安装和配置，可以将客户端的IP修改成X-Forwarded-For，具体的方法目前还有待研究。

# yum install mod_extract_forwarded

负载均衡器分配方式简介

ELB弹性负载均衡器是一款比较简单易用的负载均衡器，其采用Round Robin方式平均的将外部访问分配到ELB管理下的EC2实例中，保障实例群在大访问量下最好的分配使用系统资源。

此外，常见的高性能的负载均衡器，一般含有：Least Connections，Observed，Dynamic Ratio，Round Robin，Ratio，Fastest，Predictive等等。由于ELB只提供Round Robin功能所以说是简单的，通过万维网只几步就可以拥有负载均衡器,因此说它又是易用的。

AWS在AMAZON ELB环境下限制客户端的访问配置，首发于服务器安全维护工作室。