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

为了使用户更容易的将数据库迁移到云中，AWS已经在海外区域推出了AWS Database Migration Service服务，如果您的数据库在海外，DMS可以在源数据库不停机的情况下，帮您将数据迁移到AWS云中。DMS的功能非常强大，支持同构数据库的迁移（如Oracle迁移到Oracle)，也支持异构数据库直接的迁移，如Oracle到Mysql等）。在数据库迁移期间，源数据库无需停机，并且能将迁移期间数据的更改持续复制到目标数据库。因此迁移完成后，您只需在短暂的停机时间内直接切换数据库，从而保证业务数据的完整性。
在中国BJS区域，还没有推出DMS服务，但是提供了Database Migration Tool(DMT)工具，您可以使用DMT工具来完成数据库迁移。

2.使用DMS完成迁移

使用DMS服务必须确保源或目标数据库有一个在AWS云中。 使用DMS服务的步骤如下：

步骤一：Create migration

登陆AWS全球区域的Console，选择DMS,点击“Create migration”,我们便来到了“welcome”界面，从该界面我们可以看到，通过DMS进行数据迁移我们至少需要一个源数据库、目标数据库和复制实例。当然，DMS 也支持多个源数据库向一个目标数据库的迁移以及单个源数据库向多个目标数据库的迁移。迁移时，数据通过一个运行在复制实例上的任务将源数据库复制到目标数据库。点击“Next”进行复制实例的创建。

步骤二：创建“Replication Instance”

您在进行数据库迁移过程中的第一个任务是创建具有足够存储空间和处理能力的复制实例，通过复制实例来执行您分配的任务并将数据从您的源数据库迁移到目标数据库。此实例所需的大小取决于您要迁移的数据和您需要执行的任务量。具体配置参数见下表1。

如果您需要为网络和加密设置值，请选择高级选项卡。具体参数见表2。

步骤三：创建数据库连接

当您在创建复制实例时，您可以指定源和目标数据库。源数据库和目标数据库可以在AWS的EC2上，也可以是AWS的关系数据库服务（RDS）的DB实例或者本地数据库。在设置源和目标数据库时，             具体参数可以参见表3。您也可以通过高级选项卡来设置连接字符串和加密密钥的值。

等图示上部分的显示变成”Replication instance created successfully”并且“Run test“按钮变成正常，然后测试，确保测试结果为”Connection tested Successfully”,由于需要从AWS服务端连接测试数据库，因此需要设置好security group，设置的security group必须确保复制实例能够访问源和目标数据库。需要的话，可以短暂的将security group 1521　的访问设置为 0.0.0.0/0,测试成功后，点击”Next”按钮。

步骤四：创建“task”

当源数据库和目标数据库建立连接后，您需要创建一个任务来指定哪些表需要迁移，使用目标架构来映射数据并且在目标数据库中创建新表。作为创建任务的一部分，您可以选择迁移类型：迁移现有数据、迁移现有数据并复制正在进行的更改，或只复制更改的数据。

如果选择”Migrate existing data and replicate data changes”选项需要打开Task Settings 中的supplemental loging开关。在Table Mapping中Schema to Migrate选择“Oracle”,点击“Create Task”。

当您创建的task状态从creating变为ready的时候，您的task便创建好了。点击该“task”并点击上方的“Start/Resume”,您数据迁移任务便开始了！

数据库迁移完成后，目标数据库在您选择的时间段内仍会与源数据库保持同步，使您能够在方便的时候切换数据库。

3.总结

从上面过程我们可以看到，只需要简单的配置，DMS就可以帮助我们完成数据库的迁移任务，并且DMS服务是免费的，迁移过程中用到的资源是收费的。

使用AWS的数据库迁移DMS服务，首发于服务器安全维护工作室。

错误一  源访问权限未放开

这种错误常见于用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常见错误配置及解决方法，首发于服务器安全维护工作室。

• 用户权限策略
• 访问控制策略
• 服务器安全策略
• 应用接入策略
• 网络分区策略
• 数据传输策略
• 数据存储策略
• 备份归档策略
• 日志记录策略
• 审计管理策略

……….

在实际的应用场景中，标准策略可能会因为业务的变化或管理方式的变化动态调整，如何持续评估和审核在AWS云端的资源配置的合规性是否与企业规划一致？如何帮助用户在云端更好的实现变更管理，安全分析甚至自动修正不合规的配置 ？这种场景下，可以考虑用AWS Config 服务来帮忙。

一、AWS config 是什么

AWS Config 是一项托管服务,借助 Config您可以盘点AWS 资源、查看配置更改以及 AWS 资源之间的关系并深入探究详细的资源配置历史记录。使用 Config，还能通过自定义规则来定义所需的资源配置、内部最佳实践和指南，并依据这些规则评估您记录的配置。

AWS Config的主要应用功能：

• 评估您 AWS 资源配置是否具备所需设置。
• 获得与您的 AWS 账户关联的受支持资源的当前配置快照。
• 检索您的账户中的一个或多个资源配置。
• 检索一个或多个资源的历史配置。
• 在资源被创建、修改或删除时接收通知。
• 查看不同资源之间的关系。例如，您可能想要找到使用特定安全组的所有资源

AWS Config工作原理

更多AWS Config的信息可以参考https://aws.amazon.com/cn/config/

二、 AWS config 配置测试

为了更好了解AWS Config的工作过程，以下 将以AWS安全组的配置监控为例做一个简短测试 。

1. 测试场景：

• 一个为web服务器配置的安全组，该安全组策略只允许对Internet开放HTTP和HTTPS两个端口；
• 配置AWS Config 规则，当该安全组配置规则中添加了其他端口时，AWS Config 自动记录，并触发修复机制自动删除新加入的不合规的配置。

2. 配置过程

a. 权限准备。为成功配置AWS Config 规则，需要创建IAM 角色，授予 AWS Config 权限，使其可以访问Amazon S3 存储桶、Amazon SNS 主题，获取受支持的 AWS 资源的配置详细信息。IAM内置了一个AWSConfigRole的托管策略 。

新建一个IAM Role 命名为awsconfigrole, 可以直接附加该策略：

另外，测试过程中将使用lambda自动对安全组执行安全组操作，cloudwatch log操作，也需要建立好对应的IAM role并编辑策略赋予对应的权限,在测试中该IAM role为：awsoncifgec2security

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "logs:CreateLogGroup",

                "logs:CreateLogStream",

                "logs:PutLogEvents"

            ],

            "Resource": "arn:aws:logs:*:*:*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "config:PutEvaluations",

                "ec2:DescribeSecurityGroups",

                "ec2:AuthorizeSecurityGroupIngress",

                "ec2:RevokeSecurityGroupIngress"

            ],

            "Resource": "*"

        }

    ]

}

b. 配置AWS Config Setting。在AWS 控制台，打开 AWS Config ,具体过程可以参考：http://docs.aws.amazon.com/zh_cn/config/latest/developerguide/gs-console.html

在本测试过程中，我们选择资源类型为SecurityGroup:

在配置过程中，指定一个存储桶保存日志，并指定预先为AWS Config 的IAM Role ,当然也可以在这个步骤选择新建角色：

在上述页面中，可以选择是否通过SNS 启用通知将信息流式传输到 Amazon SNS 主题，发送配置历史记录传输、配置快照传输和合规性等通知。

在Resources页面中验证一下，评估的对象是否能正常的筛选出来，本例中我们是对测试的安全组进行查找：

c. AWS Config 规则配置。AWS Config提供一些内置的规则，也支持自定义规则创建。在前文中提及测试的背景中需要通过自动机制保证安全组规则符合设定的合规配置，我们将通过lambda完成该步骤。在创建规则的过程中，按向导设置规则名称，点击新建lambda功能按钮：

在lambda创建过程中，选择blank blueprint 并为函数指定runtime为python2.7 ，将准备好的代码保存在s3（可以在github中找到相关代码参考，比如https://github.com/awslabs/aws-config-rules ）并上传。

Lambda函数主要完成以下工作：

• lambda函数中按照要求只开启tcp 80 和tcp 443端口；
• 如果有其他端口添加到配置规则中将被删除，最终保证安全组的配置规则条目中只有tcp80和tcp443相关的配置；
• 相关的操作将记录在cloudwath logs中。

在创建过程中，为lambda指定对应的IAM Role.

lambda创建完成后，需要在AWS Config 规则页面中指定Lambda ARN,  配置触发器。本例中,当安全组配置发生变化时即触发对安全组的评估，也可以配置按照时间周期的评估对象。 另外，为了详细记录评估信息，为规则启用debug级别的记录。

AWS config  规则后，当前的安全组配置将自动被评估。

d. 验证。为触发AWS Config 对安全组的评估， 我们在对应的安全组规则中除tcp 80 和tpc443，额外新添加tcp445 端口。在cloudwathc logs中创建了logs group,可以进行相关日志查看：

在日志中可以清楚看到对安全组有revoking的行为，操作的端口正是额外添加的tcp445 ， 并且最终将安全组只开启tcp80 和tcp443 端口。

三、进一步讨论

在上述测试过程中，大致可以了解AWS Config的工作机制和配置流程，下面进一步对一些场景的应用场景做进一步说明。

资产发现

AWS Config 不仅会发现账户中的资源、记录其当前配置并捕获对这些配置所做的任何更改，Config 还会保留已删除资源的详细配置信息。所有资源及其配置属性的完全快照在您的账户中提供完整的资源库。

持续安全分析

AWS Config 提供的数据可使您持续监控您的资源配置情况，并评估这些配置是否具有潜在的安全弱点。对您的资源配置进行更改，将触发系统发送 Amazon Simple Notification Service (SNS) 通知，这些通知可发送给您的安全团队，以便他们查看通知并采取相应措施。发生潜在的安全事件后，您可以使用 Config 查看资源的配置历史记录并检查您的安全状况。

正如测试过程中展示，企业IT团队只需明确制定相关的策略，配置AWS Config规则，AWS Config提供了托管规则和自定义规则，能满足各种就能持续监控相关的安全标准是否合规。借助 AWS Config，利用 AWS Lambda 中的自定义规则将合规性要求编制成代码，这些代码会定义资源配置内部最佳实践和指南。您可以使用 Config 自动评估您的资源配置和资源更改，从而确保整个 AWS 基础设施实现持续合规性和自主监管。通过这个机制，为企业的安全自动化提供了一个可行选项。

变更管理

在创建、更新或删除资源时，AWS Config 会将这些配置更改流式传输到 Amazon Simple Notification Service (SNS)，如此便会收到所有配置更改通知。根据通知机制也可以考虑引入基于事件触发的机制，进一步集成各个管理环节。

在AWS Config按照既定规则完成评估后，可以在规则的详细信息中查看到具体的变更事件记录：

审计

AWS CloudTrail 将记录账户上的用户 API 活动，将保存有关 API 操作的完整详细信息，如发起人的身份、该 API 调用的时间、请求参数和 AWS 服务返 。AWS Config 与AWS CloudTrail 集成 ,回答“谁进行了修改此资源的 API 调用？”例如下图， 使用集成的 AWS CloudTrail 信息，可以发现是哪个用户错误配置了安全组。

综合上述讨论，企业内部资产管理团队可以清楚明确当前在AWS云端的数字资产，安全团队可以将严格制定的安全体系持续的在云端自动化运行，任何相关的变更和配置管理都能详尽的记录，方便后续的审计。

更多关于AWS Config的一些常见问题可参考：https://aws.amazon.com/cn/config/faq/

通过AWS Config 管理AWS服务配置，首发于服务器安全维护工作室。

购买Amazon预留实例(Reserved Instance)时，其实无需停止现在使用的EC2及RDS等，购买Reserved Instance就跟购买折扣券一样,是对现在使用的EC2及RDS费用打折，长期使用AWS服务时，可以购买Reserved Instance节省成本。

购买Reserved Instance的流程

1.登录到AWS管理页面以后，点击EC2。

2.点击「Reserved Instances」以后，「Purchase Reserved Instances」。

3.进行搜索。

进行搜索之前需要，选择以下信息。需要谨慎的选择。

• Platform：Linux/Unix
• Instance Type：m3.xlarge
• Availability Zone:ap-northeast-1a
• Term:1month – 12month
• Tenancy:Default
• Offering Type:Heavy Utilization

4.加入购物车。

5.选择完购买的Reserved Instance以后,点击购买。

信用卡结算以后，购买Reserved Instance的工作就结束了。

AWS节约成本之购买AMAZON预留实例(RESERVED INSTANCE)，首发于服务器安全维护工作室。

通过本文章，您将了解如何通过AWS CodePipeline，AWS CodeBuild，AWS CloudFormation 来实现基于Amazon ECS的持续集成持续部署方案。

开发人员在GitHub中提交的新版本代码，会自动触发代码获取，打包镜像，上传镜像仓库，更新新版本容器服务，注册到负载均衡器等操作。

方案中会涉及使用如下组件：

GitHub：示例使用的源，一个提交到GitHub上的PHP示例网站。AWS CodePipeline支持GitHub， AWS CodeCommit服务，或者S3作为源。此次实例使用的Demo软件工程可以从以下链接Fork：

https://github.com/awslabs/ecs-demo-php-simple-app

Docker：作为发布服务使用的容器。演示方案的Build阶段会使用AWS CodeBuild托管的ubuntu／docker 1.12.1基础镜像。

Amazon EC2：作为ECS的容器宿主机集群。

Amazon VPC：服务所在的网络。

Amazon ECS：AWS托管的容器编排服务。文档链接 http://docs.aws.amazon.com/zh_cn/AmazonECS/latest/developerguide/Welcome.html

Amazon ECR：AWS 托管的容器镜像仓库。文档链接 http://docs.aws.amazon.com/zh_cn/AmazonECR/latest/userguide/what-is-ecr.html

AWS CodePipeline：AWS 托管的持续集成持续交付服务，可以快速可靠的更新应用程序和服务，集成支持GitHub，Jenkins等主流开源工具。文档链接 http://docs.aws.amazon.com/zh_cn/codepipeline/latest/userguide/welcome.html

AWS CodeBuild：AWS 托管的构建服务，用于打包代码生成可部署的软件包。文档链接 http://docs.aws.amazon.com/zh_cn/codebuild/latest/userguide/welcome.html

AWS CloudFormation：批量创建和管理AWS资源的自动化脚本。文档链接http://docs.aws.amazon.com/zh_cn/AWSCloudFormation/latest/UserGuide/Welcome.html

2.方案架构

流程如下：

1. 开发者将一个新版本的代码工程提交到GitHub
2. Pipeline的Source阶段，检测到指定GitHub的repo有新版本的更新，从GitHub上拉取代码工程，开启已设定好的CICD Pipeline
3. Pipeline的Build阶段，AWS CodeBuild将新版本的代码工程打包为Docker镜像
4. AWS CodeBuild将打包好的镜像推送到Amazon ECR
5. Pipeline的Deploy阶段，AWS CodePipeline触发AWS CloudFormation，其定义了Amazon ECS的Task definition和service
6. AWS CloudFormation创建新版本的Task definition关联到新版本的Docker镜像，并更新Service
7. Amazon ECS从Amazon ECR中取到新版本的Docker镜像，并运行来替换旧Task以完成服务的更新部署

3. 搭建

搭建部分分为以下几个步骤：基础设施，与CICD Pipeline的搭建。

3.1   基础设施部分的搭建

这里需要准备好网络，负载均衡器，S3以及运行ECS所需要的宿主机集群。

3.1.1 网络搭建

创建VPC，子网，Internet Gateway，路由表。将Internet Gateway Attach到VPC上，路由表配置0.0.0.0/0指向Internet Gateway，并关联子网。

之后的EC2宿主机集群，负载均衡器等都使用在这个网络里。

3.1.2 负载均衡器

创建ALB应用负载均衡器，监听80端口

选择对应的子网

新建安全组，端口80，并新建目标组

注册目标此时不选择，ECS创建服务时会注册集群和对应端口进来。

下一步审核后创建。

3.1.3 ECS宿主机集群

在ECS的界面下，创建集群

实例配置保持默认或根据情况自行选择，示例中保持默认。

联网配置，选择创建好的VPC，子网，创建Role允许宿主机上的ECS代理调用ECS服务的API。

创建后画面下面会显示集群信息

集群一览会显示

修改ECS宿主机集群的安全组，inbound源设置为建好的应用负载均衡器的安全组ID

3.1.4 ECR镜像仓库创建

创建一个用于Build阶段上传存放软件工程Docker镜像的镜像仓库

ECS界面下，创建存储库，创建好后如下

3.1.5 S3桶创建

创建一个S3桶用来存放Deploy阶段CloudFormation使用的脚本模版，创建桶时选择和以上服务同一Region，并且打开桶的版本控制。

将CloudFormation模版压缩zip后上传到桶中。

示例中将模版文件service.yaml放在templates文件夹后压缩为templates.zip。

service.yaml如下，注意缩进

Parameters:

  Tag:

    Type: String

    Default: latest


  DesiredCount:

    Type: Number

    Default: 0


  TargetGroup:

    Type: String


  Cluster:

    Type: String


  Repository:

    Type: String


Resources:

  ECSServiceRole:

    Type: AWS::IAM::Role

    Properties:

      Path: /

      AssumeRolePolicyDocument: |

        {

            "Statement": [{

                "Effect": "Allow",

                "Principal": { "Service": [ "ecs.amazonaws.com" ]},

                "Action": [ "sts:AssumeRole" ]

            }]

        }

      Policies:

        - PolicyName: root

          PolicyDocument:

            Version: 2012-10-17

            Statement:

              - Resource: "*"

                Effect: Allow

                Action:

                  - ec2:*

                  - elasticloadbalancing:*


  Service:

    Type: AWS::ECS::Service

    Properties:

      Cluster: !Ref Cluster

      Role: !Ref ECSServiceRole

      DesiredCount: !Ref DesiredCount

      TaskDefinition: !Ref TaskDefinition

      LoadBalancers:

        - ContainerName: simple-app

          ContainerPort: 80

          TargetGroupArn: !Ref TargetGroup


  TaskDefinition:

    Type: AWS::ECS::TaskDefinition

    Properties:

      Family: !Sub ${AWS::StackName}-simple-app

      ContainerDefinitions:

        - Name: simple-app

          Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${Repository}:${Tag}

          EntryPoint:

            - /usr/sbin/apache2

            - -D

            - FOREGROUND

          Essential: true

          Memory: 128

          MountPoints:

            - SourceVolume: my-vol

              ContainerPath: /var/www/my-vol

          PortMappings:

            - ContainerPort: 80

          Environment:

            - Name: Tag

              Value: !Ref Tag

        - Name: busybox

          Image: busybox

          EntryPoint:

            - sh

            - -c

          Essential: false

          Memory: 128

          VolumesFrom:

            - SourceContainer: simple-app

          Command:

            - /bin/sh -c "while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"

      Volumes:

        - Name: my-vol

到此基础设施部分的搭建工作结束。

3.2   Pipeline的搭建

分为Source，Build以及Deploy三阶段：

Source阶段设置GitHub上的软件工程位置，并设置Deploy阶段会使用的CloudFormation脚本模版来更新ECS服务，

Build阶段使用AWS CodeBuild来打包软件工程到Docker镜像并上传到ECR，

Deploy阶段使用Source阶段引入的CloudFormation脚本，找到对应的宿主机集群，负载均衡器，以及上传到ECR的Docker镜像等对象，更新服务。

AWS CodePipeline创建后的展示图是这样的，串起了整个CICD流程

在AWS CodePipeline界面点击创建管道Pipeline，可以看到画面左侧一个基本流程，从源，到生成Build，到部署Deploy，到角色等配置。实际应用中用户可以随实际需要，或随着CICD流程的由简入繁在创建后编辑加入新的阶段或操作。

点击下一步。

3.2.1 Source阶段配置

源提供商下拉菜单选择GitHub，

点击连接到GitHub来授权访问权，来允许AWS CodePipeline从GitHub上获取软件工程源内容，认证后选择GitHub上软件工程所在位置和分支

此次实例使用的Demo软件工程可以从以下链接Fork：

https://github.com/awslabs/ecs-demo-php-simple-app

点击下一步。

3.2.2 Build阶段配置

AWS CodePipeline在Build阶段支持包括AWS CodeBuild，Jenkins在内的引擎，此方案选用AWS 托管的CodeBuild服务

选择新建构建项目

选择AWS CodeBuild托管的镜像，支持Ubuntu系统，运行时支持包括Java，Python，Go语言，Node.js，Docker在内的众多选择，此次方案使用Docker。

构建规范这里选择使用buildspec.yml，里面预定了AWS CodeBuild在Build生命周期中要执行的动作，如login到ECR，打包Docker镜像，给Docker镜像打tag，上传Docker镜像到已login的ECR镜像仓库。

Buildspec.yml放在GitHub软件工程源代码目录中，如果复制粘贴的话注意yaml文件的缩进

version: 0.2

phases:

  pre_build:

    commands:

      - $(aws ecr get-login)

      - TAG="$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | head -c 8)"

  build:

    commands:

-    docker build --tag "替换创建好的ECR镜像仓库的URI:${TAG}" .

  post_build:

    commands:

      - docker push "替换创建好的ECR镜像仓库的URI:${TAG}"

      - printf '{"tag":"%s"}' $TAG > build.json

artifacts:

  files: build.json

选择Role

新建一个Role，这个Role允许AWS CodeBuild来调用相关的AWS服务，此方案中需要调用包括S3，ECR，CloudWatch在内的服务。

*默认创建的Role不具备对ECR的权限，需要在保存构建项目后，到IAM找到新创建的Role，编辑添加对ECR的权限否则后面Pipeline执行到Build时会报错。

保存构建项目。

点击下一步。

3.2.3 Deploy

AWS CodePipeline部署阶段支持包括AWS CloudFormation，AWS CodeDeploy，AWS Elastic Beanstalk在内的服务提供商，此方案选用AWS CloudFormation来部署ECS容器服务。

这里暂时选择无部署，等Pipeline创建好后，编辑引入Deploy的CloudFormation模版源，再进行配置。

点击下一步。

3.2.4 角色

配置AWS CodePipeline对AWS服务的调用权限，包括S3，AWS CodeBuild，AWS CloudFormation，IAM等。点击创建角色到IAM界面选择相对应的策略创建。

创建好后画面回到Pipeline，IAM创建好的Role已经显示在里面。

点击下一步。

3.2.5 审核后创建管道。

管道创建好后会自动运行，现有的从GitHub软件工程源代码抓取工程，打包Docker镜像并推送到ECR上。界面上显示如图

3.2.6 添加Deploy阶段CloudFormation需要的模版源以及配置Deploy阶段

点击编辑，点击Source阶段右上角的画笔图标

可以看到AWS CodePipeline的编辑界面在南北纵向和东西横向都可以添加

在GitHub这个Source右侧，点击添加操作，选择源，操作名称Template，选择S3，输入创建好的S3桶的地址

画面往下拉，注意在输出项目这里，输入Template。

Pipeline中各阶段的传递需要制定南北向的输入输出，即Source阶段S3源的输出Template，在Deploy阶段用输入Template来衔接。

点击更新。

点击Build阶段下面的添加阶段，画面右侧选择部署，选择AWS CloudFormation

操作模式选择创建或更新堆栈，输入创建的堆栈名称，模版这里输入Template::templates/service.yaml，也就是对应的输入是S3源桶中templates.zip里的service.yaml文件。功能选择CAPABILITY_NAMED_IAM。

同样需要创建一个Role，允许AWS CloudFormation调用包括IAM，ECS，ECR在内的AWS服务。

在IAM界面创建好后选择Role。

高级这里点开

在参数覆盖这里输入CloudFormation需要传入的参数，其中的固定参数也可以在S3的service.yaml中直接定义。

{

  "Tag" : { "Fn::GetParam" : [ "MyAppBuild", "build.json", "tag" ] },

  "DesiredCount": "2",

  "Cluster": "CICD-DEMO-CLUSTER-01",

  "TargetGroup": "arn:aws:elasticloadbalancing:us-east-2:305890642658:targetgroup/CICD-DEMO-TG-01/b7649674ee8ab97b",

  "Repository": "cicd-demo-ecr-01"

}

Tag是Build阶段传出的Docker镜像Tag使用的值，传入CloudFormation中用于建立Task Definition的Container时从ECR拉取对应版本的Docker镜像。

DesiredCount，即想要在ECS的Service中建立的Task的数量。

Cluster，即建立好的宿主机集群的名称。

TargetGroup，即建立好的宿主机集群的应用负载均衡器的ARN。

Repository，即建立好的ECR的镜像仓库名称。

输入项目这里输入Build阶段和S3模版源的输出。

点击添加操作。

保存管道更改。

4. 运行以及模拟版本更新

4.1   运行

访问负载均衡器的DNS地址来确认目前服务已经运行正常。

4.2   模拟版本更新

4.2.1 修改代码

在开发本地更新代码，示例中在src/index.php加入一行文字

<h1 style="color:FF7F00;">Amazon ECS Awesome!</h1> 4.2.2 提交新版本后查看AWS CodePipeline各阶段触发 

4.2.3 刷新服务来确认新修改的部分已经发布

使用AWS CodePipeline，AWS CodeBuild与AWS CloudFormation实现Amazon ECS上的持续集成持续部署解决方案，首发于服务器安全维护工作室。

Linux系统上目前主要使用Apache和php-fpm来解析运行PHP Web程序。php-fpm仅支持多进程，Apache支持多进程和多线程，但绝大多数环境中均为多进程方式，这里也只讨论多进程。

从实践来看，单实例最多可以开到200-300左右的进程，开到500以上就容易出错了。
每个进程占用的内存在5M-15M左右，按平均10M计算，500个进程也只有5G，而现在很多高性能机都是64G甚至128G的内存，这样单实例是无法全面使用上内存资源的。

这几年部署过的多实例环境并不多，因为访问量不是十分高的话，是用不上的。
上次配置多实例是一个100万左右PV的Discuz论坛，配置之后是很有效的。现在做的这个是千万PV的静态站，请求主要在点击计数上，在300和500之间调整进程数还是会偶尔的挂掉，机器配置是足够用的，是稳定性的问题。

LNMP或者LNAMP环境的配置这里不做介绍，只讲在LNMP环境的基础上配置多实例的过程。因为我在使用的是LNAMP环境，所以额外编译一份php到/usr/local/php-fpm/，配置文件在/etc/php-fpm/，并在此基础上做的笔记。

先修改三个值：
1，以static方式，也就是固定进程数量运行php-fpm。
2，每个实例建立100个worker进程。（不宜太多，避免不稳定）
3，每个进程执行完200次请求即退出。（避免PHP的内存泄露问题，也就是内存越用越多）

以下为复制php-fpm.conf和php-fpm服务管理脚本的命令

执行完上面的命令即复制了一份php-fpm，服务名和配置文件名均为php-fpm-1。
再复制更多份，把上面的命令上的-1替换为-2，listen监听端口往上修改，然后再执行一遍就OK。

然后写一个restart_php_fpm.sh的文件，内容为

可以用来启动和重启所有的php-fpm实例。关闭用命令killall php-fpm即可。

然后是Nginx配置。
在http段加入：

修改server段：

配置结束。

多实例在效果上基本等于多台机器的负载均衡，但是我个人还是比较倾向于在单台上配置多实例（累加资源相等的情况下），在一台机器上配置、维护、使用都要方便的多。

Linux系统配置多实例php-fpm服务，首发于服务器安全维护工作室。

由于为了让内网服务器借助EIP访问公网，所以设置所有目标地址0.0.0.0/0下一跳都转发到绑定了公网IP的ECS实例上。这里的下一跳ECS不支持搜索，有点麻烦。

其中3网段是内网局域网的网段，172.16.1.2是绑定了EIP的ECS自身IP，以便完成源地址转换

完成后测试，内网服务器已经可以访问外网了:

阿里云VPC配置SNAT，首发于服务器安全维护工作室。

测试环境：

配置完毕后的拓扑如下：

环境搭建完毕后，登陆主备ECS服务器，分别配置nginx+keepalived

MASTER服务器（nginx1）配置文件/etc/keepalived/keepalived.conf内容以及解释如下：

BACKUP服务器（nginx2）的配置需要修改：

其它保持一致即可

为了实现nginx服务异常的时候能够自动切换，需要自己写一个脚本，脚本没有硬性的要求，能够实现目标即可，这里 监控nginx进程数为例：

重新启动nginx1的nginx和keepalive服务

查看日志可以看到keepalive重新发送了IP宣告的报文

1 2 3 4 5

Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) Entering MASTER STATE Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) setting protocol VIPs. Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.1.3 Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_healthcheckers[25609]: Netlink reflector reports IP 192.168.1.3 added Oct 23 17:22:19 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.1.3

重新访问http://121.43.187.37/测试，重新访问到了服务器NGINX1，到HAVIP控制台查看，192.168.1.1的服务器重新夺回了控制权，成为了为主服务器

这样就实现了阿里云环境下的HA切换。

实际测试，阿里云的多个HAVIP可以绑定到同样的两台机器，可以配置多组vrrp_instance来实现双主。或者两台服务器同时为两个业务服务，避免资源浪费。同时能够做到主备

阿里云下配置keepalive，利用HAVIP实现HA，首发于服务器安全维护工作室。

1、如果对HTTP或者TCP转发协议不挑剔，换成TCP转发并不开启http健康检查就OK了。

优势：方便，控制台操作下就好了。

劣势：只是这样也失去了应用层异常的发现能力。

2、为健康检查单独建立一个没有开启日志的virtualhost，通过不同的端口或者hostname，让健康检查请求不会请求到业务host。

优势：web service级别的异常依然能够被健康检查发现。

劣势：virtualhost级别的异常，SLB健康检查就无法发现了。

3、利用nginx等web服务器的规则，为健康检查的文件名（URI）做单独的日志配置，以Nginx为例：

如下配置，健康检查配置一个业务上无意义的check.html。针对这个文件做的请求，不记录日志。

阿里云SLB健康检查的日志特殊处理，首发于服务器安全维护工作室。