下面我们将借助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 媒体服务构建全球直播解决方案，首发于服务器安全维护工作室。

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 常见问题汇总，首发于服务器安全维护工作室。

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

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

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

解决方案

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

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

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

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

参考示例

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

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

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

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

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

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

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

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

深入分析

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

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

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

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

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

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

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

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

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

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

结论

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

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

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 —— 管理众多代付账号，首发于服务器安全维护工作室。

除了提供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 IAM 是我们接触的第一个服务, 它具有强大的功能，可使您在AWS IAM中通过管理用户, 用户组, 策略, 角色, 证书, 密钥等来灵活而精确的控制对AWS 服务和资源的访问和权限. 同时在很多企业内部, 一般都已经部署了自己的用户管理及授权系统, 如何将AWS的用户管理及授权纳入现有系统则成为企业的想要解决的一个问题. 本文将介绍如何将企业内部Windows活动目录(Active Directory)和AWS通过ADFS(Active Directory Service) 进行集成, 从而实现在活动目录中管理用户对AWS服务和资源的访问和授权.

在AWS IAM中, 我们提供了对SAML的支持, 这个功能可以让我们可以和支持该标准的身份提供商进行联合从而实现单点登陆. 对于很多使用微软活动目录的企业, 我们可以使用Windows自带的ADFS进行和AWS IAM的集成.

工作原理:

在我们进行详细配置之前, 可以先看一下工作原理:

1.       首先用户访问和AWS做了集成的ADFS站点 (https://ADFS/adfs/ls/IdpInitiatedSignOn.aspx)

2.       用户在登陆页面输入用户名及密码, 提交以后ADFS将联系AD进行用户验证

3.       用户浏览器收到ADFS返回的SAML 断言

4.       用户浏览器将用户断言Post到AWS的Sign-in SAML终结点 (https://signin.amazonaws.cn/saml), Sign-in将调用AssumeRoleWithSAML API接口请求临时安全凭证并使用其构建管理控制台的登陆链接

5.       用户浏览器转向使用构建的登陆链接进行登陆

配置活动目录:

1.       在活动目录中及建立用户adfsuser, 邮件地址设为adfsuser@examplecom

2.       在活动目录中建立两个组AWSBJS-Admin, AWSBJS-ReadOnly, 这两个组会和AWS中新建的角色进行匹配

3.       将用户adfsuser添加到AWSBJS-Admin, AWSBJS-ReadOnly这两个组中

安装部署Active Directory Federation Service

我们可以参考如下的文档部署ADFS服务

https://technet.microsoft.com/en-us/library/dn486775.aspx

导出SAML Metadata Document

访问ADFS服务器并导出 SAML Metadata Document (将ADFS换成你ADFS服务器的名称)

https://ADFS/FederationMetadata/2007-06/FederationMetadata.xml

配置AWS

1.       登录 AWS管理控制台https://console.amazonaws.cn/

2.       在IAM服务中, 点击身份提供商, 选择SAML, 导入从ADFS服务器上导出的SAML Metadata

3.       记录下提供商ARN记录

4.       新建IAM 角色ADFSBJS-Admin和ADFSBJS-ReadOnly [注意选择 授予 SAML 提供商 Web 单点登录 (Web SSO) 访问权限, 这两个角色会和活动目录中的新建的用户组AWSBJS-Admin和AWSBJS-ReadOnly对应]

5.       记录各个角色的ARN

配置ADFS将AWS作为 信赖方信任

1.       打开ADFS管理界面, 选择信任关系-信赖方信任

2.       右键点击信赖方信任, 点击 添加信赖方信任

3.       点击 启动

4.       选择 导入有关在线或在本地网络发布的信赖方的数据, 在联合元数据地址栏输入以下地址,点击 下一步

https://signin.amazonaws.cn/static/saml-metadata.xml

5.       在 显示名称 中输入AWS China, 然后点击下一步

6.       选择 不配置多重身份验证, 点击 下一步:

7.       选择 允许所有用户访问此信赖方, 点击下一步

8.       点击下一步:

9.       点击 关闭

10.    点击 关闭, 并打开编辑声明规则

为AWS 信赖方信任 建立 声明规则

1.       在编辑声明规则中, 点击 添加规则

2.       选择 转化传入声明, 点击下一步

3.       声明规则名称使用 NameId, 传入声明类型 选择 Windows帐户名, 传出声明类型 选择 名称ID, 传出名称ID格式 选择 永久标识符, 点击完成

4.       再次点击 添加规则

5.       选择以声明方式发送LDAP特性, 点击 下一步

6.       声明规则名称 输入RoleSessionName, 特性存储选择 Active Directory, LDAP特性 选择 E-Mail-Address, 传出声明类型输入 https://aws.amazon.com/SAML/Attributes/RoleSessionName, 点击完成

7.       再次点击 添加规则

8.       选择 使用自定义规则发送声明, 点击 下一步

9.       声明规则名称输入 Get AD Groups, 自定义规则输入以下文本 (这一步用来取出登录用户所在的AD用户组, 并将其传入到临时声明 http://temp/variable中), 点击完成

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”]

=> add(store = “Active Directory”, types = (“http://temp/variable”), query = “;tokenGroups;{0}”, param = c.Value);

10.    再次点击 添加规则

11.    选择 使用自定义规则发送声明, 点击下一步

12.    声明规则名称 输入 Roles, 自定义规则中输入以下文本 (这部分主要是用来映射AD中的用户组 和 AWS中的角色之间的对应关系, 其中红色部分需要根据我们前面所建的AD用户组名称 和 身份提供商的ARN和角色的ARN调整), 点击完成

c:[Type == “http://temp/variable”, Value =~ “(?i)^AWSBJS-“]

=> issue(Type = “https://aws.amazon.com/SAML/Attributes/Role”, Value = RegExReplace(c.Value, “AWSBJS-“, “arn:aws-cn:iam::761602622223:saml-provider/ADFS,arn:aws-cn:iam::761602622223:role/ADFSBJS-“));

13.    重新启动 Active Directory Federation Service

测试配置效果

1.       访问https://ADFS/adfs/ls/IdpInitiatedSignOn.aspx (将ADFS换成你ADFS服务器的名称)

2.       输入用户名和密码

3.       验证以后, 服务器将根据它所在的组返回它拥有的角色, 用户选择不同的角色就可以拿到不同角色的权限

4.       登录以后在右上角可以看到当前用户及其所使用的角色信息

总结:

上述是将ADFS和AWS管理控制台集成从而实现使用AD账号系统登录访问AWS管理控制台的详细流程. 同时我们还可以通过调整ADFS本身的身份验证策略来实现多重验证等功能.

为AWS北京区管理控制台集成ADFS访问，首发于服务器安全维护工作室。

为达到更好的安全性，需要进行恰当的规划，通常可以考虑以下几个问题：

1. 跳板机应该放置在哪个子网？
2. 如何安全访问跳板机？
3. 跳板机如何安全访问受管理服务器？

以下是结合这些问题基于AWS部署linux跳板机相关步骤。

一．网络规划

对于vpc的规划通常需要划分为若干个子网，分为公有子网和私有子网。公有子网中的实例可以直接从 Internet 接收入站数据流，私有子网中的实例则不可。公有子网中的实例可以直接向 Internet 发送出站数据流，私有子网中的实例则不可。但是，私有子网中的实例可以使用位于公有子网中的网络地址转换 (NAT) 网关访问 Internet。

根据以上描述不同子网的特点，我们需要把跳板机放置在公有子网中，以便接受管理人员通过internet的访问，受管理的服务器根据其在业务系统中充当的角色选择放置在公有子网或私有子网。在实际生产环境中根据需要可为跳板机设置一个独立的公有子网 。

如下图所示的vpc规划中，为跳板机实例划分了一个专用的公有子网，管理员可以通过登录到跳板机对放置在私有子网的服务器的管理：

二．跳板机部署

请参考以下链接，在公有子网中部署一台linux EC2实例，并为跳板机EC2分配  EIP:

http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EC2_GetStarted.html

在实际部署中考虑到跳板机所需的工作负载，可以部署配置较低的实例类型。此外，出于成本和安全考虑，您也可以在不进行运维操作的时候将跳板机状态设置为”停止”,在每次运维需要的时候再“开启”跳板机。

为跳板机实例配置安全组。在创建EC2的过程中，在安全组规则中添加SSH服务的安全规则，根据实际情况限定连接的源 IP地址。如下图所示，只接受特定的 管理终端连接：

配置受管理服务器的安全组。配置安全组规则仅接受来自跳板机所对应安全组的访问请求：

配置管理终端。在管理终端依次导入跳板机和受管理服务器的证书私钥，登录跳板机后私钥信息将转发到受管理服务器完成身份验证。以下是针对linux环境和windows环境的管理终端为例：

在linux管理终端下通过ssh从跳板机登录到受管理服务器：

步骤一：在linux管理终端上运行ssh-agent启动ssh-agent进程

步骤二：将跳板机和受管理服务器对应证书的私钥依次添加到管理终端，执行方式如下（例如，私钥文件名称为xxx.pem）：

ssh-add  xxx.pem

步骤三：使用ssh －A 参数登录跳板机，-A 表示通过跳板机转发本地管理端保存的私钥信息，实现跳板机与受管理服务器之间的身份验证：

ssh  –A  ec2-user@跳板机公网 ip地址  ——（以下假定linux ssh用户名为ec2-user）

步骤四：从跳板机直接通过受管理服务器的内网IP SSH登录服务器：

ssh  ec2-user@受管理服务器的内网ip地址

 在windows环境下通过Putty从跳板机登陆到受管理的服务器：

下载putty客户端，并且通过puttygen将私有证书生成ppk格式。

下载Putty环境下的SSH agent—-pageant

步骤一：将受管理服务器及跳板机所对应证书的私钥添加进pageant

启动pageant并右击图标，您可以先查看key list，如果受访问服务器所需私钥没有添加进key list里，则执行”Add Key”的操作。并将保存在本地的私钥添加进去。

步骤二：通过putty登陆跳板机

在这一步中，如图填写跳板机公有IP地址，并在左侧SSH-Auth目录下勾选“Allow agent forwarding” 来允许跳板机上的ssh客户端与管理终端本地的ssh-agent通信并使用管理终端本地的密钥完成与受管理服务器的ssh认证流程。下面以AWS 上的一台EC2为例登陆跳板机：

这里需要添加的私钥为跳板机所对应证书的私钥。

步骤三：从跳板机直接登录受管理的服务器

通过命令”ssh  ec2-user@受管理服务器内网ip地址”来实现对受管理服务器的访问，需要注意的是，在这里输入受管理服务器的私有IP地址实现对其的访问，提高了受管理服务器的安全性。

这样，您便实现了从跳板机上登陆受管理服务器的操作。

三．安全加固

在上面部署跳板机的过程中，跳板机所附件的安全组规则中开放了TCP 22端口，根据实际情况建议严格限制来源ip地址，只允许指定的IP地址访问。在这基础上，还可以对安全进行优化：

• 当管理员需要登录跳板机通过AWS CLI在安全组添加规则打开tcp 22 端口；

完成管理任务后，退出ssh会话，AWS CLI将从安全组中关闭tcp 22端口；实现以上效果，可以执行以下脚本 ，请根据实际环境替换安全组id。

#!/bin/bash

aws ec2 authorize-security-group-ingress –group-id 安全组id –protocol tcp –port 22 –cidr 0.0.0.0/0 &

sleep 5

ssh -A  ec2-user@跳板机公网IP

aws ec2 revoke-security-group-ingress –group-id 安全组id –protocol tcp –port 22 –cidr 0.0.0.0/0

要成功运行以上脚本，需要配置 AWS CLI运行环境，具体请参考：

http://docs.aws.amazon.com/cli/latest/userguide/installing.html

执行脚本登录前，将跳板机安全组中的ssh服务规则删除，即无法访问tcp 22端口：

执行脚本登录时，将执行脚本中的第一条语句，通过AWS CLI添加了ssh服务相关规则，然后ssh成功登录到跳板机：

在跳板机上完成管理任务后exit结束ssh会话，AWS CLI删除安全组ssh服务规则，即无法访问tcp22端口：

下图显示，安全组规则相应被删除：

四．跨vpc管理服务器

跳板机是否可以管理不同vpc中的服务器呢？答案当然是可以的。如下图所示，需要在vpc之间建立peering连通两个vpc，跳板机即可实现跨vpc安全管理应用服务器。

建立vpc peering的过程如下，也可以参考以下链接获取更详细的信息：http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html

步骤一：新建Peering Connection

进入console里面VPC下的”Peering Connections”页面，新建”VPC Peering Connection”。 在这里您需要提供跳板机以及受管理服务器所在VPC的ID，点击”Create VPC Peering Connection”。

步骤二： 配置路由表

创建成功之后，您可以看到peering 的相关信息，比如”status” ,”Local Vpc”以及”Peered Vpc”信息。同时您可以看到peering的状态为”pending-accept”，您需要点击上方的”Action”,并选择接受请求。

当您接受请求之后，您会收到创建新的路由表的通知，您需要点进页面进行路由表的配置。当为本地VPC 配置路由表信息时，您需要提供受访服务器所在VPC的CIDR作为跳板机路由表的Destination，新创建的peering  作为Target。

同理，在配置受访服务器所在VPC 的路由表信息时，您只需将本地 VPC 的CIDR作为Destination。

在配置完路由表信息后，您可以看到peering的状态变成了”active”,并且可以看到路由表的相关信息。

步骤三： 通过本地跳板机登陆受访服务器

这一步类似于前面提到的在同一VPC下从公有子网的跳板机访问私有子网的受管理服务器。您需要配置好您的安全组信息，在访问的时候，您需要在管理终端保存受管理服务器公钥所对应的私钥。然后在跳板机上执行ssh  ec2-user@受管理服务器内网ip地址

如下图：位于192.168.0.0/24网段的跳板机 直接ssh访问位于172.16.0.0/24网段的应用服务器

五．关于windows 环境下的跳板机配置

Windows Server的管理基于windows RDP协议实现，可以通过配置RDP 网关服务器管理位于私有子网的windows服务器，具体的规划及配置请参考以下白皮书：

https://aws.amazon.com/windows/resources/whitepapers/rdgateway

基于AWS 平台跳板机配置，首发于服务器安全维护工作室。

为了使用户更容易的将数据库迁移到云中，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常见错误配置及解决方法，首发于服务器安全维护工作室。

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

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

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

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

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

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

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

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

场景及拓扑

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

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

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

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

详细配置步骤

1.配置 VPC 基础环境

1.1 创建 VPC

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

名称标签： MyVPC

CIDR块： 192.168.0.0/16

租赁：默认

1.2 创建子网

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

标签名称：Public

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

可用区：保持默认

CIDR块：192.168.1.0/24

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

1.3 创建路由表

点击路由表，创建路由表

名称标签：PrivateRoute

VPC：选择1.1创建好的VPC

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

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

1.4 创建 IGW

点击Internet网关，创建Internet网关

名称标签：MyIGW

创建完成，点击附加到VPC

选择新创建好的VPC

2. 启动并配置 VPN 实例

2.1 启动实例

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

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

子网选择192.168.1.0/24

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

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

添加规则

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

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

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

所有流量 来源为 192.168.2.0/24

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

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

2.2 配置弹性 IP （EIP）

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

2.3 关闭源/目的检查

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

3. 安装配置 OpenSwan

3.1 登录到实例安装 OpenSwan

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

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

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

$ sudo yum -y install openswan

3.2 根据Cisco 参数来配置 OpenSwan

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

$ sudo vim /etc/ipsec.conf

include /etc/ipsec.d/*.conf

Cisco路由器的配置如下：

crypto isakmp policy 10

encr aes

authentication pre-share

group 2

crypto isakmp key aws123 address 54.223.152.218

!

!

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

mode tunnel

!

!

!

crypto map OpenSwan 10 ipsec-isakmp

set peer 54.223.152.218

set transform-set OpenSwan

match address 100

!

!

interface GigabitEthernet1

ip address 54.223.170.5 255.255.255.252

ip mtu 1400

ip tcp adjust-mss 1360

crypto map OpenSwan

!

access-list 100 permit ip 10.1.2.0 0.0.0.255 192.168.2.0 0.0.0.255

ip route 0.0.0.0 0.0.0.0 54.223.170.6

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

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

conn cisco

authby=secret

auto=start

leftid=54.223.152.218

left=%defaultroute

leftsubnet=192.168.2.0/24

leftnexthop=%defaultroute

right=54.223.170.5

rightsubnet=10.1.2.0/24

keyingtries=%forever

ike=aes128-sha1;modp1024

ikelifetime=86400s

phase2alg=aes128-sha1

salifetime=3600s

pfs=no

配置解释：

leftid 标明本地对应公网IP

letftsubnet为本地子网

right为对端公网地址

rightsubnet为对端子网

ike为第一阶段参数

ikelifetime为第一阶段的生存时间

phase2alg为第二阶段参数

salifetime为第二阶段生存时间

结果如下图：

配置预共享密钥：

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

54.223.152.218  54.223.170.5: PSK “aws123”

启动openswan服务并做配置检查

$ sudo service ipsec start

$ sudo ipsec verify

3.3 修改系统参数

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

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

$ vim /etc/sysctl.conf

$ vim /etc/sysctl.conf

net.ipv4.ip_forward = 1

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.eth0.send_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.eth0.accept_redirects = 0

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

$ sudo sysctl –p

3.4 更改 OpenSwan 的网卡 MSS 值

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

3.5 修改 VPC 私有子网路由表

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

添加其他路由，

目标： 10.1.2.0/24

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

4. 测试连通性

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

ping 10.1.2.3

检查 IPsec tunnel 状态：

$ sudo service ipsec status

IPsec running - pluto pid: 25674

pluto pid 25674

1 tunnels up

some eroutes exist

常见问题及排错

1.  IPsec Tunnel 没有正常建立

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

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

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

3. NAT 问题

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

8.2 及以前的版本：

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

8.3 及更新的版本：

object network obj-192.168.1.0

subnet 192.168.1.0 255.255.255.0

object network obj-10.0.0.0

subnet 10.0.0.0 255.255.255.0

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

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

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