Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们今天继续Route53的内容。

首先，可以使用 Route 53 作为内部私有DNS，需要创建私有托管区域，并将VPC的enableDnsHostnames和enableDnsSupport设置为True，这是私有DNS必须要设置的，否则将无法正常工作。

然后DNSSEC，这个协议是用来保护域不受劫持或者中间人攻击。这种攻击方式是攻击者劫持用户DNS查询并返回攻击者自己配置的IP让用户访问，然后返回的这个IP可能是虚假网站。

Route 53 支持将 DNSSEC 用于域注册。但是，Route 53 不支持将 DNSSEC 用于 DNS 服务。也就是说如果您想要使用DNSSEC保护您的域不受劫持，则必须使用其他 DNS 服务提供商或在EC2上自行配置您自己的 DNS 服务器，比如通过bind，dnsmasq等三方应用。要牢记这一点，目前Route 53不支持DNSSEC协议。

您可以在第三方注册机构注册域名，然后使用Route 53提供DNS服务，只需要在三方注册机构更新域名的NS记录指向Route 53就可以了。

Route53 – 运行状况检查

接下来，Route53运行状况检查，运行状况检查是Route53的核心功能之一，它能够监控资源的运行状况，在状态更改时获取通知，还可以配置DNS实现自动故障转移。

举个例子，假设我们有两台EC2实例运行着网站，可以通过Route53创建加权或延迟策略记录，或任何支持附加运行状况检查的记录然后附加2个运行状况检查，这样的话Route53运行状况检查就会监控终端节点对应这个例子中的两台WEBSERVER，终端节点可能是您的负载均衡器，WEBSERVER，或者其他资源。

前面是监控终端节点，您也可以使用运行状况检查监控其他的运行状况检查，在其他运行状况检查达到配置的阈值时通知。

还支持将运行状况检查用于监控CloudWatch警报，CloudWatch警报的触发条件是我们自己定义的，您可以定义任何您需要的触发条件，如定义ELB的健康主机数量、RDS警报，以及自定义指标等，然后通过运行状况检查监控CloudWatch警报，当其中运行状况检查失败时进行通知或进行相应的动作。

最后，Route53的运行状况检查与CloudWatch指标集成在一起，所以可以为运行状况检查创建警报，发送SNS通知等等。

另外还支持配置运行状况检查为 使用字符串匹配的 HTTP 和 HTTPS 运行状况检查 。

这种方式是您可以配置特定的字符串，然后Route 53 的运行状况检查将在响应的内容中搜索您指定的字符串，注意该字符串必须完全在响应正文的前 5120 个字节中，如果未找到配置的字符串则终端节点将无法通过运行状况检查。

运行状况检查的终端节点必须使用2xx和3xx的HTTP状态代码来响应才能通过运行状况检查。

我们来看一下，创建一个运行状况检查，指定状况检查请求终端节点上的路径，比如默认的/；终端节点的HTTP服务器可以是EC2实例或者其他公网的服务器，然后终端节点必须使用2xx和3xx的HTTP状态代码来响应时，或者通过前面介绍的在响应正文前5120字节中包括指定的内容时，终端节点才会通过运行状况检查。

除了配置监控终端节点，也可以配置运行状况检查监控其他运行状况检查的状态，这种方式也被称为已计算的运行状况检查。比如可以指定子运行状况检查至少有多少项运行状况检查正常时，才认定父运行状况检查通过。通过这种方式，您可以配置复杂的条件来达成您的需求。

最后，运行状况检查可以配置触发cloudwatch警报。

运行状况检查 – 私有子网

Route 53的运行状况检查是通过Internet向您的应用、服务器或其他资源发起请求的。对于私有子网以及不可路由到的资源、终端节点是没有办法创建运行状况检查的 ，因为发起运行状况检查的节点根本就无法访问到这些终端节点资源。

所以呢，假设您的一台EC2实例在私有子网中，那么就自然无法为其创建运行状况检查。

不过可以通过一些其他的方式，采用一些折中的办法达到差不多的目的。我们来看一下：

首先，终端节点要运行状况检查，就要为终端节点比如EC2实例分配公网IP地址并使其公网可访问，我们上面的例子EC2实例在私有子网，我们也不打算调整，所以这个方式显而易见是行不通的。

或者如果这台私有子网的EC2实例，有其他依赖的如EC2实例在公有子网中，那么可以做个中转，运行状况检查监控其依赖的EC2实例，比如网站前端，数据库等假设公网可访问的资源。

还有一个方式也是前面讨论过的，您可以为私有子网的这台EC2实例创建一个CloudWatch指标，在为其创建警报。然后创建一个运行状况检查 监控CloudWatch警报。我们来看一下这个架构图：

我们为私有子网的这台EC2创建了一个CloudWatch警报，警报是基于您选择的CloudWatch指标来触发监控、产生告警。【然后在通过创建的Route 53的运行状况检查关联这个CloudWatch警报。通过这种方式，我们使用运行状况检查来有效的监控私有子网的一台EC2实例，这是直接使用状况检查做不到的。

这个架构非常的重要，大家一定要熟悉。

通过运行状况检查实现RDS跨区域故障转移

接下来的内容我们看两个解决方案，首先第一个解决方案—通过运行状况检查实现RDS跨区域故障转移。

假设我们在us-east-1有一个RDS主数据，然后在us-west-2区域创建了一个该数据库的只读副本，它们之间是使用异步复制。

这个方案实现的就是在当主数据库出现问题时，自动故障迁移至另一个AWS区域的只读副本提供服务。

那么首先在RDS数据库有问题时要能及时监控到，如可采用2种方式：

1、创建一台公网EC2实例来检查RDS主数据库的运行状况，这台EC2还需要提供一个可供HTTP调用的路径，如/health-db，实现通过调用/health-db能够返回RDS的运行状况，然后Route 53的运行状况检查通过调用EC2实例的/health-db，来监控RDS主数据库的运行状况。

2、通过创建这个RDS的CloudWatch警报，通过CloudWatch警报监控RDS运行状况，然后将CloudWatch警报与运行状况检查关联起来。

这是2种监控RDS主数据库的运行状况的方式，我们继续。

然后，当RDS主数据库故障，运行状况检查被触发时，可以配置触发一个关联了这个状况检查的CloudWatch警报，并配置当警报触发后发送通知到SNS主题或通过读取CloudWatch警报事件，【然后配置SNS主题或者CloudWatch警报事件触发一个lambda函数，这个lambda函数需要实现2个操作：

1.通过API调用，提升只读副本为主数据，使其作为主数据库可接受读取和写入数据；

2.更新Route53中的数据库的DNS记录，指向只读副本。

好的，以上这个整个架构组成，实际上这个解决方案是通过Route53、运行状况检查以及Lambda函数等来实现RDS的跨区域自动故障转移的实现，非常有趣。

将自由托管区域与多个AWS账号下的VPC关联

好的，我们讨论的第二个解决方案—将私有托管区域与多个AWS账号下的VPC 关联。

通常，很多组织会在AWS上通过Route53配置私有托管区域，作为内部私有DNS解析；大部分组织都拥有多个AWS账号，且不同的账号下会有一个或多个VPC，那如何将这些不同AWS账号下的VPC与私有托管区域关联在一起呢？

我们来看一下这个架构。

一般组织都会设置一个共享服务的AWS账号， 然后在账号下配置一个内部私有的共享DNS，作为在AWS上资源内部DNS解析。

共享服务账号中使用Route 53创建了一个私有托管区域，然后组织中的其他的AWS账号下的VPC的资源比如EC2实例，都需要通过这个共享服务账号的Route 53解析DNS请求，这要如何实现呢？

首先，其他的AWS账号下的VPC需要访问共享服务账号的VPC做DNS解析，那么就需要为这些账号下的每一个VPC与共享服务账号的VPC分别都建立VPC对等连接；

然后第二步，也是最关键的一步，必须使用CLI 或开发工具包等编程方式，将这些VPC与共享服务账号中的私有托管区域关联，这一步非常重要，您一定要了解，目前是无法通过控制台关联，只能通过CLI或开发工具包等编程方式来做关联。

然后 您需要为每个账号的VPC都要和共享账号中的私有托管区域做一次关联。比如一共4个VPC，就要分别和共享账号中的私有托管区域做4次关联。

如果您想要了解具体详细的命令，请访问PPT中的URL。

以上我们讨论了将私有托管区域与多个AWS账号下的VPC关联 的架构，这也是作为解决方案架构师需要熟悉的。

好的，这节课我们讨论了Route53相关的内容，也希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。