网站启动失败，网站无法访问，网站无法打开，服务器重启服务启动异常，数据库启动失败，MySQL无法连接，数据库无法连接，故障排除，故障排查，网站问题排查，网站中毒，数据库启动不了等。

网站无法访问 网站中毒 业务异常 服务器故障排查 应用故障排查 数据库无法连接，首发于服务器安全维护工作室。

网站挂马 网站无法访问 服务器故障排查 应用故障排查 数据库故障排查，首发于服务器安全维护工作室。

数据迁移服务（上云或云云迁移），首发于服务器安全维护工作室。

下面我们将借助AWS Elemental MediaLive ， MediaPackage，CloudFront服务构建一套完整的直播OTT转码打包分发服务，通过这个实验您可以直观的体会到AWS的媒体服务是多么便捷，而您所需要的仅仅是一个AWS Global账号和一天可以上网的电脑。

1.  准备直播源

MediaLive支持RTP，RTMP(Push), RTMP(Pull),HLS四种输入源，如果您已经有RTMP直播源可以直接用在本实验中。

本次实验以HLS为例，使用存储在S3上的一个预先转码完成的文件做为输入源，对于MediaLive来说，这个输入源就是一个直播源。

例如https://s3-us-west-2.amazonaws.com/mytestbucket-og-media-3/keynote-hls/testvideo.m3u8

确认此目录已经开启公开访问（关于S3的更多信息请参阅https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/Welcome.html）

2.  创建MediaPackage Channel

a.  登陆AWS Global 控制台，在Services中选择MediaPackage，

b.  在Channel页面，选择 Create Channel

c.  输入ID，即自行命名这个Channel，例如ch1。可选填Description栏

d.  Input type选择Apple HLS

e.  点击Create channel

f.  点击新创建的Channel，在Channel Overview页面选择Add/edit endpoint

g.  在endpoints页面点击Add，填写 ID，例如ch1-ep1，点击Save

h.  重复上述步骤创建第二个Channel和对应的endpoint

i.  记下channel的Input URL，username和password

3.  创建MediaLive Channel

a.  在控制台Services 中选择MediaLive

b.  选择Channels页面，点击Create Channel

c.  在Channel Name中填入自行创建的通道名

d.  在IAM Role 选择Create role from template。选中Remember ARN

（关于IAM Role更多信息请参见https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_roles.html）

创建MediaLive Input

e.  在Channel input部分点击Create input

f.  在Input name 创建一个名字

g.  Input type选择HLS

h.  将第一步准备的HLS源的地址填入Input source A和Input source B的URL中。注意，出于高可用性的考虑，MediaLive Input要求2个互为主备的输入源，本试验使用两个不同的存储桶的HLS URL做为输入源，在实际生产环境中也要两个不同的输入源地址来提供高可靠性。

i.  点击Create

创建HLS Output Group

j.  在channel template部分，选择HTTP live streaming模版，将会自动添加不同分辨率和码率的10个输出。也可以不使用模版，通过手动添加自定义output

k.  点击Output groups下的模版名TN2224，点击Credentials(optional)，选中Create AWS Elemental MediaLive parameter 将第2步创建的两个channel的URL，Username，password依次填入HLS Group destination A和HLS Group destination B。见下图

l.  点击 Create channel

4.  启动channel并查看

a.  Channel创建完成后是idle状态，选中之后点击Start

b.  使用第2步创建的endpoint，使用VLC player来播放这个直播流，，例如：

https://103xxxxxxxxe303.mediapackage.us-west-2.amazonaws.com/out/v1/c78bcxxxxxxxxxxxxxxxxxxxxxx45/index.m3u8

c.  如果不能看到直播视频流，请查看并确认MediaLive Channel 和MediaPackage Channel 的network in&out都有流量

MediaLive Channel网络状态

MediaPackage Channel网络状态

5.  使用CloudFront创建CDN发布

a.  登陆AWS Global 控制台，在Services中选择CloudFront，选择Distributions，点击Create Distribution

b.  使用Web方式，点击Get Start

c.  在Origin Domain Name中填入第2步创建的MediaPackage end point域名，例如：https://103xxxxxxxxe303.mediapackage.us-west-2.amazonaws.com

在Origin Path 中填入MediaPackage end point中的路径，例如： /out/v1/c78bcxxxxxxxxxxxxxxxxxxxxxx45

Origin Protocol Policy 选择HTTPS only

其他选项可以不修改，（更多CloudFront相关信息，请参阅https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cf_dg.pdf）

点击Create Distribution

d.  等待创建完成后，status由In progress变为Deployed，即可使用CLoudFront分配的域名，加上index.m3u8即可例如d2xxxxxxxxxxx4n4m.cloudfront.net/index.m3u8

使用VLC player打开这个地址即可播放，这样就完成了播放流的CDN发布，CloudFront会选择距你延时最小的边缘站点进行加速。

现在，您的直播业务就已经完成了构建，并具有全球分发和加速能力。AWS媒体服务具备内置可靠性和弹性。该服务可透明地管理多个可用区中的资源，并自动监控其运行状况，以便在不中断实时频道的情况下检测并解决任何潜在问题。借助 AWS 媒体服务，您可以获得比通常用于广播工作负载的基础设施更高的可靠性

MediaLive输入支持SD, HD, UHD，支持H.264 (AVC), HEVC (H.265), MPEG-2视频编码格式，支持AAC, Dolby Digital, Dolby Digital Plus, MPEG Audio, PCM音频格式，支持AFD，支持帧率控制，支持GOP结构设置，支持多种编码profile，支持多种字幕标准，支持时码插入，支持数字版权管理等等。

除了MediaLive+MediaPackage，您还可以使用MediaConvert做视频文件转码，使用MediaStore做内容存储，使用MediaTailor做广告插播。AWS媒体服务与包括 Amazon CloudFront、AWS CloudFormation、Amazon CloudWatch 在内的补充性 AWS 服务，以及适用于安全、管理和生产的第三方应用程序相集成，提供一整套工具来处理和交付实时的按需视频内容。最重要的是，AWS 媒体服务使您专注于内容，而非管理复杂的基础设施，让您能为观众提供卓越的体验。

使用AWS 媒体服务构建全球直播解决方案，首发于服务器安全维护工作室。

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

动态创建子网的方案概述

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

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

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

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

• SharedInfra – 对应 python 程序 create_shared_infra.zip

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

• CreateExternalRoute – 对应 python 程序 create_external_route.zip

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

• SubnetAutomation – 对应 python 程序 subnet_creation.zip

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

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

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

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

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

安装和运行

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

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

创建的 Subnet 如下：

公共子网路由表：

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

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

1. 运行结果如下:

创建的子网：

内部子网路由表：

外部子网路由表：

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

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

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

• 账户结构

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

• 账户安全基线

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

• 网络结构

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

• AWS 用户访问管理

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

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

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

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

创建 CloudFormation 宏

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

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

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

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

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

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

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

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

使用 CloudFormation 宏

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

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

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

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

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

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

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

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

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

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

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

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

示例宏

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

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

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

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

现已推出

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

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

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

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

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

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

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

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

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

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

背景

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

一、什么是 Amazon CloudFront

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

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

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

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

二、如何配置 CloudFront Distribution

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

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

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

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

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

本节将涉及如下内容：

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

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

2、源站设置

部分解释如下：

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

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

3、添加源站

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

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

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

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

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

4、添加 Behavior

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

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

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

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

三、缓存优化

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

1、TTL 设置建议

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

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

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

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

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

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

对于 Cache-Control Header 设置样例：

2、错误处理

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

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

四、内容更新

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

1、版本号控制

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

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

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

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

五、监控与日志

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

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

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

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

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

六、合规与安全

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

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

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

1、回源保护

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

当源站为 ELB/EC2 时：

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

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

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

（3）回源 HTTPS

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

当源站为 S3 存储桶时：

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

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

2、传输安全

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

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

3、内容保护

（1）签名 URL、签名 Cookie

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

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

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

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

（3）Geo 限制

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

4、与 AWS WAF、Shield 集成

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

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

七、可编程 CDN

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

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

参考资料

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

AWS Organizations 可为多个 AWS 账户提供基于策略的管理。借助 AWS Organizations，您可以创建账户组，然后将策略应用于这些组。Organizations 支持您针对多个账户集中管理策略，无需使用自定义脚本和手动操作流程。

使用 AWS Organizations，您可以创建服务控制策略 (SCP)，从而集中控制多个 AWS 账户对 AWS 服务的使用。Organizations 支持您通过 包括API，SDK和Console界面创建新账户。Organizations 还有助于简化多个账户的计费模式，即您可以通过整合账单(Consolidated Billing)为您组织中的所有账户设置一种付费方式。所有 AWS 客户都可以使用 AWS Organizations，且无需额外付费。要注意的是任意的AWS账户只能存在一个Organization中.

AWS Organizations关键性概念

在正式接触AWS Organizations之前我们必须要先弄清楚其中的关键性名词和概念

Organization – 组织

•     组织是指一系列AWS账户，您可以将其整理为一个层次结构并进行集中式管理

AWS account – 账户

•     AWS账户是您AWS资源的容器，例如： Amazon S3 存储桶、 Amazon EC2 实例等

•     通过AWS Identity and Access Management (IAM) 规则  (users, roles) 管理AWS资源

•     AWS Organizations中最小的管理单元

Master account – 主账户

•     在组织中为所有账户付款的账户

•     管理您的组织的Hub（中心）节点

Organizational unit (OU) – 组织单元

•     组织单元是组织内的一组AWS账户

•     把AWS账户添加到逻辑组中，账号管理更方便

•     AWS账户和组织单元OU可以是另外一个组织单元OU的成员

•     一个AWS账户可以是多个组织单元OU的成员

Administrative root – 管理根

•     管理根是整理AWS账户的起始点，也是整个组织层次架构中的最顶层的容器。

Organization control policy (OCP) – 组织控制策略

•     含有一个或多个语句的配置，这些语句用于定义您要应用于某组AWS账户的控制策略

•     不同应用场景使用不同的组织控制策略

下图可以帮助您更直观的理解这些概念之间的关系：

下面我会更详细的介绍以上提出的这些概念：

Account加入Organization的方式

1. 从Organization中创建新账户

• 新的AWS账户只能通过主账户来创建
• 在创建账户的过程中，您可以配置下面的信息

Ø  电子邮件地址 (必须)

Ø  账户名称 (必须)

Ø  IAM 角色名称 (可选 – 默认的名称是 OrganizationAccountAccessRole)

§  为主账户通过AssumeRole方式访问当前账户开启信任权限

§ 权限设置为完全控制

Ø  IAM 访问账单 (可选) 。注意! IAM 用户仍然需要相关的IAM权限才可以访问账单

• 新AWS账户

Ø  自动成为您组织的一部分

Ø  可以从组织中删除，但是可以通过策略让其没有执行Leave Organization的权限

2. 让已有账户加入Organization

• 邀请只能通过主账户发起
• v 被邀请的AWS账户可以选择接受或者拒绝邀请

Ø  默认的行为是拒绝

Ø  可以通过IAM权限来控制

• 当邀请被接受

Ø  这个AWS账户就成为组织的一个成员

Ø  可应用的OCP规则会被自动引用到这个账户

• 被邀请的AWS账户可以被从组织中移除，但是可以通过策略让其没有执行Leave Organization的权限

AWS Account的逻辑组(OU)

•     把AWS账户添加到逻辑组中，账号管理更方便

•     AWS账户和组织单元OU可以是另外一个组织单元OU的成员

•     一个AWS账户可以是多个组织单元OU的成员

如下图所示：

OCP(Organization Control Policy)

• 描述要应用的控制策略
• 不同的使用场景有不同的应用控制策略 OCP
• 应用控制策略OCP可以被附加到

Ø  组织(Organization)

Ø  组织单元(OU)

Ø  AWS账户(Account)

• OCP拥有继承属性(AWS账户, 组织单元OU, 组织)

Ø  Policy是继承关系的，也就是说OU会继承organization的policy，而AWS Account会继承OU的policy

Ø  Account的policy会跟随其移动，如果这个Account从一个OU移动到另一个OU，那么属于这个Account的Policy也会移动。但是它不会再接收之前OU的Policy，而是会接收新OU的Policy

OCP support in V1：Service Control Policies(SCPs)

• 允许您对AWS服务 API进行访问控制

Ø  定义一个允许访问的API列表 – 白名单

Ø  定义一个禁止访问的API列表 – 黑名单

• 服务控制策略无法被本地管理员覆盖
• 对于IAM用户和角色，最终生效的权限是服务控制策略和相关的IAM权限的交集
• 必要但不充分，本地用户拥有某行为权限，必须要同时拥有SCP权限和IAM权限
• IAM 规则模拟器对SCP有感知
• SCP的控制权限大于本地administrator的权限

下图是使用白名单和使用黑名单写SCP的案例:

SCP使用的是IAM policy的语法，和IAM Policy一样，但是有以下两点不同

•     Resource必须是”*”

•     没有condition

一定注意，允许最终用户行为的话，必须要SCP和IAM Permission同时拥有。下图所示，如果在SCP允许S3和EC2，但是在IAM Permission允许EC2和SQS。那么最终用户只能拥有EC2的权限

简单化的账单管理

•     单个付款账户为所有账户付款

•     组织内所有的AWS账户的资源被核算到统一的账单中并应用相关的阶梯价

•     所有已存在的整合账单家族将会被迁移到组织的账单模式中

Organization不同的管理级别

您可以在创建新组织的时候选择不同的管理级别

账单模式(Billing mode)

•     和当前的整合账单模式向下兼容 (CB)

•     从整合账单家族中创建的的组织自动被设置为账单模式

完全控制模式(Full-control mode)

•     账单模式中的所有功能

•     开启所有类型的OCP管理功能

•     从账单模式转换成完全控制模式需要得到组织中所有AWS账户同意

动手利用AWS Organizations来管理您的组织

下面我就给大家演示一下，使用AWS Organizations服务如何能做到快速，方便，准确的来管理您的多个账户

进入AWS Organizations服务

进入AWS Organizations服务的方式，可以通过在service上搜索的方式进入，或者通过在Account菜单下点击My Organization进入。在Service的下拉菜单中没有这项服务。

服务栏搜索：

账号栏下拉：

创建新的Organization

在AWS Organizations服务界面上选择创建组织，选择希望创建的组织的种类，这里我演示时选择Full Control模式，如果希望仅进行账单整合(Consolidated Billing)，那么选择右边的“Enable Only Consolidated Billing”。无论是哪种模式，账单都会是整合的。区别只在于Master Account能不能对加入的账号进行控制

注意：现在Consolidated Billing功能已经迁移到AWS Organization下了，如果点击主账号下的My Account-> Consolidated Billing，可以看到该提示，并且点击View Linked accounts也是直接就会跳转到AWS Organization界面

创建完毕之后，会出现组织架构管理界面，前面带星号的账号就是Master Account

添加新Account到Organization下

在创建完Organization之后，添加账号到Organization下有两种方式

•     直接添加账户

•     邀请其他账户加入

1. 直接添加账户(Account)

填写你希望添加的账号的全名和邮箱，并分配一个IAM Role，这个IAM Role是用来给予这个新Account一个full administrative control的权限

大约等待几秒钟，Account即可创建。对比如果是要自己在AWS网页创建账号，速度上提升了非常多。不过创建时没有设置密码，需要用户登录时在控制台点击忘记密码来重置。

在Global根账号控制台登录新创建的账号，因为不知道密码，所以需要点击忘记密码来重置。随后会在注册邮箱收到重置密码的链接，点击重置密码之后，重新登录即可

登录账户之后，可以看到这个新账号已经可以工作，并且Consolidated Billing功能是默认开启的。并指示该账户已经在一个Organization下了。

2. 邀请其他账户(Account)加入

点击Invite account来邀请其他账号加入，添加账号号码或者邮箱，并点击邀请即可

在界面右侧，点击Invitations可以看到已经邀请的账号的信息

此时在被邀请的账号的注册邮箱中会收到来自Master Account的邀请邮件，如果希望接受这个邀请加入Organization。那么可以选择点击邮件中的链接或者直接进入自己账号下的Organization界面接受也可以。

在Invitation界面中可以看见Organization的ID，邀请人的Account以及申请控制的类型，最后还有申请加入时的留言(Notes)

最后回到主账号下，可以看见包括Master Account，主动创建的Account以及受邀请加入的Account的信息

从Organization删除Account

有两种方式可以从Organization下面删除加入的Account：

1. Master Account主动从Organization删除Account，点击单个或多个Account，点击删除即可

2. 加入Organization的Account脱离Organization，在该Account下选择My Organization，可以看见其加入的Organization信息以及选择离开该Organization

利用OU(Organization Unit)来管理多个Account

开始时Organization下是没有任何OU的，需要用户自己手动去添加。每一级OU又可以添加自己下一级的OU，从而形成一个树状结构

你可以创建一个多级OU组织，包括一个根OU，两个一级OU和两个二级OU

所有的Account默认都在根OU下，你可以选择一个或者多个Account，并把他们移动到任意OU下。目前只能移动Account到OU，不能从OU主动加Account

针对不同的OU可以开启不同的Policy来控OU下面的Account，不过要开启这个feature，必须首先在Root OU下启动这个功能

利用Policy(Service Control Policy)来管理Account的行为

在使用Policy开管理Account时，始终记住两个原则：

1. Policy是继承关系，并且可以随Account移动

•     Policy是继承关系的，也就是说OU会继承organization的policy，而AWS Account会继承OU的policy

•     Account的Policy会跟随其移动，如果这个Account从一个OU移动到另一个OU，那么属于这个Account的Policy也会移动。但是它不会再接收之前OU的Policy，而是会接收新OU的Policy

2. 最终Account下的User的行为是SCP和IAM Permission共同决定的

一定注意，允许最终用户行为的话，必须要SCP和IAM Permission同时拥有。下图所示，如果在SCP允许S3和EC2，但是在IAM Permission允许EC2和SQS。那么最终用户只能拥有EC2的权限

Service Control Policy在Policies下面可以进行设置，默认情况就有一个什么权限都有的FullAWSAccess Policy并且是attach到Root OU的。这也就意味着默认情况下，只有有Account加入这个Organization，那么这个Account就拥有操作所有AWS服务的权限。如果希望修改SCP，那么可以点击右侧的Policy editor进行修改

SCP的格式和IAM Policy格式一致，但有下面两点不同。在修改完或创建完Policy之后，可以attach给任何OU或Account

•     Resource必须是”*”

•     没有condition

点击Policies界面下左上角的Create Policy可以从头创建一个SCP，你既可以选择使用Policy generator帮助你生成一个新的SCP，也可以从你已经创建的一个SCP中进行复制。在创建时，你可以选择白名单模式或者黑名单模式

这里我选择白名单模式，创建一个名为“SCP_Allow_access_VPC_subnet”的SCP，仅允许Account创建和查看VPC和Subnet，其余动作都禁止

将创建的SCP分配给OU，进而这个SCP会传递给下面添加的Account

在SCP配置界面下，将原来的FullAWSAccess策略解除，添加新创建的“SCP_Allow_access_VPC_subnet”策略。这个时候问题就来了，因为这个Account会继承所在OU的SCP，而所在OU又会继承上层OU的SCP。所以其实目前来说，这个Phoenix Yao的Account是会拥有两个SCP，包括拥有所有权限的“FullAWSAccess”和限制权限的“SCP_Allow_access_VPC_subnet”

在这种情况下会怎么样呢？其实和IAM Policy一样，SCP只会允许最小权限，所以当你用Phoenix Yao账号打开VPC界面时，会发现你无法查看除了VPC和Subnet的任何信息。另外，注意一下，这个Policy生效有时候需要一些时间，不是马上能看到结果。

我们再来看下IAM policy和SCP一起作用的结果。使用Phoenix Yao这个root账号创建一个User，并赋予其除了查看Subnet其余动作都可以做的IAM Policy。

将这个Policy绑定到新创建的IAM User的IAM Permission中

将SCP恢复成“FullAWSAccess”以单独测试IAM Permission是否生效，发现已经生效。

最后将SCP和IAM Permission一起使用。得到的结果应该是取最小权限，即只能查看VPC的情况

使用AWS Organizations时的最佳实践

下面介绍一些在使用AWS Organizations服务时的最佳实践：

1.      使用CloudTrail服务监控Master Account的行为活动

2.      不要通过Master Account来管理资源

3.      在管理你的组织时要采用”最小权限分配”的原则

4.      使用OU来对账号进行权限的分配管理

5.      仅给Organizations的根账号(root)分配仅需要的权限

6.      在测试权限时先使用单个AWS Account来测试

7.      避免在一个组织中同时使用”白名单”策略和”黑名单”策略

8.      每创建一个新的AWS Account都需要有足够合理的原因

给予Organization最小权限

•     对所有AWS组织行为设置相对应的IAM权限

•     您也可以把AWS组织相关的元素（组织，组织单元，AWS账户）作为IAM规则的资源进行管理

•     您可以把管理您组织的权限通过IAM role功能委托给一个在其他AWS账号中的IAM用户

•     所有的组织管理行为可以通过AWS CloudTrail服务记录

AWS Organizations —— 管理众多代付账号，首发于服务器安全维护工作室。

AWS Organizations 可为多个 AWS 账户提供基于策略的管理。借助 AWS Organizations，您可以创建账户组，然后将策略应用于这些组。Organizations 支持您针对多个账户集中管理策略，无需使用自定义脚本和手动操作流程。

使用 AWS Organizations，您可以创建服务控制策略 (SCP)，从而集中控制多个 AWS 账户对 AWS 服务的使用。Organizations 支持您通过 包括API，SDK和Console界面创建新账户。Organizations 还有助于简化多个账户的计费模式，即您可以通过整合账单(Consolidated Billing)为您组织中的所有账户设置一种付费方式。所有 AWS 客户都可以使用 AWS Organizations，且无需额外付费。要注意的是任意的AWS账户只能存在一个Organization中。

AWS Organizations关键性概念

在正式接触AWS Organizations之前我们必须要先弄清楚其中的关键性名词和概念

Organization – 组织

• 组织是指一系列AWS账户，您可以将其整理为一个层次结构并进行集中式管理

AWS account – 账户

• AWS账户是您AWS资源的容器，例如： Amazon S3 存储桶、 Amazon EC2 实例等
• 通过AWS Identity and Access Management (IAM) 规则  (users, roles) 管理AWS资源
• AWS Organizations中最小的管理单元

Master account – 主账户

• 在组织中为所有账户付款的账户
• 管理您的组织的Hub（中心）节点

Organizational unit (OU) – 组织单元

• 组织单元是组织内的一组AWS账户
• 把AWS账户添加到逻辑组中，账号管理更方便
• AWS账户和组织单元OU可以是另外一个组织单元OU的成员
• 一个AWS账户可以是多个组织单元OU的成员

Administrative root – 管理根

• 管理根是整理AWS账户的起始点，也是整个组织层次架构中的最顶层的容器。

Organization control policy (OCP) – 组织控制策略

• 含有一个或多个语句的配置，这些语句用于定义您要应用于某组AWS账户的控制策略
• 不同应用场景使用不同的组织控制策略

下图可以帮助您更直观的理解这些概念之间的关系：

下面我会更详细的介绍以上提出的这些概念：

Account加入Organization的方式

1.从Organization中创建新账户

1.1 新的AWS账户只能通过主账户来创建

1.2 在创建账户的过程中，您可以配置下面的信息：

电子邮件地址 (必须)

账户名称 (必须)

IAM 角色名称 (可选 – 默认的名称是 OrganizationAccountAccessRole)

• 为主账户通过AssumeRole方式访问当前账户开启信任权限
• 权限设置为完全控制
• IAM 访问账单 (可选) 。注意! IAM 用户仍然需要相关的IAM权限才可以访问账单

1.3 新AWS账户

自动成为您组织的一部分

可以从组织中删除，但是可以通过策略让其没有执行Leave Organization的权限

2. 让已有账户加入Organization

2.1 邀请只能通过主账户发起

2.2 被邀请的AWS账户可以选择接受或者拒绝邀请

默认的行为是拒绝

可以通过IAM权限来控制

2.3 当邀请被接受

这个AWS账户就成为组织的一个成员

可应用的OCP规则会被自动引用到这个账户

2.4 被邀请的AWS账户可以被从组织中移除，但是可以通过策略让其没有执行Leave Organization的权限

AWS Account的逻辑组(OU)

• 把AWS账户添加到逻辑组中，账号管理更方便
• AWS账户和组织单元OU可以是另外一个组织单元OU的成员
• 一个AWS账户可以是多个组织单元OU的成员

如下图所示：

OCP(Organization Control Policy)

1. 描述要应用的控制策略

2. 不同的使用场景有不同的应用控制策略 OCP

3. 应用控制策略OCP可以被附加到

• 组织(Organization)
• 组织单元(OU)
• AWS账户(Account)

4. OCP拥有继承属性(AWS账户, 组织单元OU, 组织)

• Policy是继承关系的，也就是说OU会继承organization的policy，而AWS Account会继承OU的policy
• Account的policy会跟随其移动，如果这个Account从一个OU移动到另一个OU，那么属于这个Account的Policy也会移动。但是它不会再接收之前OU的Policy，而是会接收新OU的Policy

OCP support in V1：Service Control Policies(SCPs)

1. 允许您对AWS服务 API进行访问控制

• 定义一个允许访问的API列表 – 白名单
• 定义一个禁止访问的API列表 – 黑名单

2. 服务控制策略无法被本地管理员覆盖

3. 对于IAM用户和角色，最终生效的权限是服务控制策略和相关的IAM权限的交集

4. 必要但不充分，本地用户拥有某行为权限，必须要同时拥有SCP权限和IAM权限

5. IAM 规则模拟器对SCP有感知

6. SCP的控制权限大于本地administrator的权限

下图是使用白名单和使用黑名单写SCP的案例:

SCP使用的是IAM policy的语法，和IAM Policy一样，但是有以下两点不同

• Resource必须是”*”
• 没有condition

一定注意，允许最终用户行为的话，必须要SCP和IAM Permission同时拥有。下图所示，如果在SCP允许S3和EC2，但是在IAM Permission允许EC2和SQS。那么最终用户只能拥有EC2的权限。

简单化的账单管理

• 单个付款账户为所有账户付款
• 组织内所有的AWS账户的资源被核算到统一的账单中并应用相关的阶梯价
• 所有已存在的整合账单家族将会被迁移到组织的账单模式中

Organization不同的管理级别

您可以在创建新组织的时候选择不同的管理级别

1. 账单模式(Billing mode)

• 和当前的整合账单模式向下兼容 (CB)
• 从整合账单家族中创建的的组织自动被设置为账单模式

2. 完全控制模式(Full-control mode)

• 账单模式中的所有功能
• 开启所有类型的OCP管理功能
• 从账单模式转换成完全控制模式需要得到组织中所有AWS账户同意

动手利用AWS Organizations来管理您的组织

下面我就给大家演示一下，使用AWS Organizations服务如何能做到快速，方便，准确的来管理您的多个账户

1. 进入AWS Organizations服务

进入AWS Organizations服务的方式，可以通过在service上搜索的方式进入，或者通过在Account菜单下点击My Organization进入。在Service的下拉菜单中没有这项服务。

服务栏搜索：

账号栏下拉：

2. 创建新的Organization

在AWS Organizations服务界面上选择创建组织，选择希望创建的组织的种类，这里我演示时选择Full Control模式，如果希望仅进行账单整合(Consolidated Billing)，那么选择右边的“Enable Only Consolidated Billing”。无论是哪种模式，账单都会是整合的。区别只在于Master Account能不能对加入的账号进行控制

注意：现在Consolidated Billing功能已经迁移到AWS Organization下了，如果点击主账号下的My Account-> Consolidated Billing，可以看到该提示，并且点击View Linked accounts也是直接就会跳转到AWS Organization界面

创建完毕之后，会出现组织架构管理界面，前面带星号的账号就是Master Account

3. 添加新Account到Organization下

在创建完Organization之后，添加账号到Organization下有两种方式

• 直接添加账户
• 邀请其他账户加入

3.1 直接添加账户(Account)

填写你希望添加的账号的全名和邮箱，并分配一个IAM Role，这个IAM Role是用来给予这个新Account一个full administrative control的权限。

大约等待几秒钟，Account即可创建。对比如果是要自己在AWS网页创建账号，速度上提升了非常多。不过创建时没有设置密码，需要用户登录时在控制台点击忘记密码来重置。

在Global根账号控制台登录新创建的账号，因为不知道密码，所以需要点击忘记密码来重置。随后会在注册邮箱收到重置密码的链接，点击重置密码之后，重新登录即可。

登录账户之后，可以看到这个新账号已经可以工作，并且Consolidated Billing功能是默认开启的。并指示该账户已经在一个Organization下了。

3. 2 邀请其他账户(Account)加入

点击Invite account来邀请其他账号加入，添加账号号码或者邮箱，并点击邀请即可

在界面右侧，点击Invitations可以看到已经邀请的账号的信息

此时在被邀请的账号的注册邮箱中会收到来自Master Account的邀请邮件，如果希望接受这个邀请加入Organization。那么可以选择点击邮件中的链接或者直接进入自己账号下的Organization界面接受也可以。

在Invitation界面中可以看见Organization的ID，邀请人的Account以及申请控制的类型，最后还有申请加入时的留言(Notes)

最后回到主账号下，可以看见包括Master Account，主动创建的Account以及受邀请加入的Account的信息

从Organization删除Account

有两种方式可以从Organization下面删除加入的Account：

1. Master Account主动从Organization删除Account，点击单个或多个Account，点击删除即可

2. 加入Organization的Account脱离Organization，在该Account下选择My Organization，可以看见其加入的Organization信息以及选择离开该Organization

利用OU(Organization Unit)来管理多个Account

开始时Organization下是没有任何OU的，需要用户自己手动去添加。每一级OU又可以添加自己下一级的OU，从而形成一个树状结构

你可以创建一个多级OU组织，包括一个根OU，两个一级OU和两个二级OU

所有的Account默认都在根OU下，你可以选择一个或者多个Account，并把他们移动到任意OU下。目前只能移动Account到OU，不能从OU主动加Account

针对不同的OU可以开启不同的Policy来控OU下面的Account，不过要开启这个feature，必须首先在Root OU下启动这个功能

利用Policy(Service Control Policy)来管理Account的行为

在使用Policy开管理Account时，始终记住两个原则：

1. Policy是继承关系，并且可以随Account移动

• Policy是继承关系的，也就是说OU会继承organization的policy，而AWS Account会继承OU的policy
• Account的Policy会跟随其移动，如果这个Account从一个OU移动到另一个OU，那么属于这个Account的Policy也会移动。但是它不会再接收之前OU的Policy，而是会接收新OU的Policy

2. 最终Account下的User的行为是SCP和IAM Permission共同决定的

一定注意，允许最终用户行为的话，必须要SCP和IAM Permission同时拥有。下图所示，如果在SCP允许S3和EC2，但是在IAM Permission允许EC2和SQS。那么最终用户只能拥有EC2的权限

Service Control Policy在Policies下面可以进行设置，默认情况就有一个什么权限都有的FullAWSAccess Policy并且是attach到Root OU的。这也就意味着默认情况下，只有有Account加入这个Organization，那么这个Account就拥有操作所有AWS服务的权限。如果希望修改SCP，那么可以点击右侧的Policy editor进行修改

SCP的格式和IAM Policy格式一致，但有下面两点不同。在修改完或创建完Policy之后，可以attach给任何OU或Account

• Resource必须是”*”
• 没有condition

点击Policies界面下左上角的Create Policy可以从头创建一个SCP，你既可以选择使用Policy generator帮助你生成一个新的SCP，也可以从你已经创建的一个SCP中进行复制。在创建时，你可以选择白名单模式或者黑名单模式

这里我选择白名单模式，创建一个名为“SCP_Allow_access_VPC_subnet”的SCP，仅允许Account创建和查看VPC和Subnet，其余动作都禁止

将创建的SCP分配给OU，进而这个SCP会传递给下面添加的Account

在SCP配置界面下，将原来的FullAWSAccess策略解除，添加新创建的“SCP_Allow_access_VPC_subnet”策略。这个时候问题就来了，因为这个Account会继承所在OU的SCP，而所在OU又会继承上层OU的SCP。所以其实目前来说，这个Phoenix Yao的Account是会拥有两个SCP，包括拥有所有权限的“FullAWSAccess”和限制权限的“SCP_Allow_access_VPC_subnet”

在这种情况下会怎么样呢？其实和IAM Policy一样，SCP只会允许最小权限，所以当你用Phoenix Yao账号打开VPC界面时，会发现你无法查看除了VPC和Subnet的任何信息。另外，注意一下，这个Policy生效有时候需要一些时间，不是马上能看到结果。

我们再来看下IAM policy和SCP一起作用的结果。使用Phoenix Yao这个root账号创建一个User，并赋予其除了查看Subnet其余动作都可以做的IAM Policy。

将这个Policy绑定到新创建的IAM User的IAM Permission中

将SCP恢复成“FullAWSAccess”以单独测试IAM Permission是否生效，发现已经生效。

最后将SCP和IAM Permission一起使用。得到的结果应该是取最小权限，即只能查看VPC的情况

使用AWS Organizations时的最佳实践

下面介绍一些在使用AWS Organizations服务时的最佳实践：

1. 使用CloudTrail服务监控Master Account的行为活动

2. 不要通过Master Account来管理资源

3. 在管理你的组织时要采用”最小权限分配”的原则

4. 使用OU来对账号进行权限的分配管理

5. 仅给Organizations的根账号(root)分配仅需要的权限

6. 在测试权限时先使用单个AWS Account来测试

7. 避免在一个组织中同时使用”白名单”策略和”黑名单”策略

8. 每创建一个新的AWS Account都需要有足够合理的原因

给予Organization最小权限

• 对所有AWS组织行为设置相对应的IAM权限
• 您也可以把AWS组织相关的元素（组织，组织单元，AWS账户）作为IAM规则的资源进行管理
• 您可以把管理您组织的权限通过IAM role功能委托给一个在其他AWS账号中的IAM用户
• 所有的组织管理行为可以通过AWS CloudTrail服务记录

AWS Organizations —— 管理众多账号，首发于服务器安全维护工作室。