AmazonRoute 53是一项高可用性及高可扩展性域名服务（简称DNS），其中还包括一项强大的运行状况检查服务。如今，我们利用域名注册与管理以及基于地理位置的DNS支持能力对Route
53进行了深度扩展。我们还对Route 53查询价格进行了下调！现在就让我们近距离一探这些项目的价值所在。
域名注册与管理
早在1995年，我就注册了自己的第一个域名！在那个时候，域管理与注册的方方面面在处理上都极为困难、成本高昂而且需要全部以手动方式完成。在想到一个好名称之后，大家需要说服一到两位懂技术的朋友帮自己托管DNS记录、利用基于邮箱的格式注册该名称、而后让自己的站点正式上线。随着基于网络的注册机制以及多种注册途径的不断涌现，更为顺畅与经济的执行方式终于成为了现实。
直到现在，大家仍然需要通过外部注册服务器注册自己的域名、在Route 53当中创建托管区、而后在注册服务器上配置该域的入口以指向Route53名称服务器。随着Route 53域名注册机制的出炉，大家现在已经可以在AWS管理控制台内部完成整个流程了（当然，API接入也是完全可行的）。大家可以从广泛的通用可选列表以及特定国家的顶级域（简称TLD）中购买、管理并（双向）传输域。作为注册流程的组成部分，我们将为大家自动创建并配置一套Route
53托管区。大家只需要为其想一个好名字、进行注册、将静态（利用Amazon Simple Storage Service，简称S3）或者动态内容（利用Amazon Elastic ComputeCloud，简称EC2;AWS Elastic Beanstalk或者AWSOpsWorks）提交上线即可，整个过程仅耗时数分钟。
如果与大多数其他AWS客户一样，大家拥有数百甚至几千个域名，那么将一定知道原先需要花费多少精力来查看域名的到期时间并及时对其加以更新。而在将自己的域传输到Route53之后，我们能够利用自己的可配置到期通知与可选自动更新机制轻松打理以上工作。这样一来，大家就不会犯下尴尬（有时候甚至是代价高昂）的错误，且能够将注意力集中在应用程序本身而非域名体系之上。大家甚至可以将所有用户名与密码保存在这里，从而进一步释放自己的大脑细胞。
下面我们将分步了解如何利用AWS管理控制台与Route 53 API寻找并注册域名。
Route 53仪表板为我们提供一幅宏观视图，其内容包括托管区、运行状况检查以及域：
作为注册流程的第一步，我首先输入自己想好的名称并从菜单中选择一条TLD：
这套控制台可在选定域以及其它部分高人气域当中检查其可用性。我可以将自己想要的名称添加到其中（在本示例中为.com以及.info）：
接下来，我输入自己的联络资料：
我可以选择为自己的域启用隐私保护机制。该选项会隐藏我自己的大部分个人信息，公共Whois数据库将无法获取这部分内容、我也将因此免受信息窃取与垃圾邮件的骚扰。
当一切准备就绪后，我只需同意各条款，自己的域就会被注册完成：
我可以在控制台中查看自己的全部域：
我还可以查看单一域中的详细信息：
我当然也能将域传输至或传输出Route 53：
正如我之前所提到，我可以通过Route 53 API查看、购买并管理域。假设大家想以自己刚出生的家庭成员为名，并希望确保自己能够买到与之相匹配的域名（在大多数情况下，与其他人进行商议同样很有必要），请使用以下代码——它能自动完成整个流程！我使用的是AWSSDK for PHP。
第一步是设置想要的成员姓氏与性别，并获取可接受的TLD列表：
$LastName = ‘Barr‘;
$Gender = ‘F‘;
$TLDs = array(‘.com‘,‘.org‘);
接下来，我将AWS SDK与PHP Simple HTMLDOM纳入其中并创建Route 53客户端对象：
require‘aws.phar‘;
require‘simple_html_dom.php‘;
// Connectto Route 53
$Client =\Aws\Route53Domains\Route53DomainsClient::factory(array(‘region‘ =>‘us-east-1‘));
现在我需要一份常见婴儿取名结果清单，并将该清单解析为HTML以创建一套PHP数组：
$HTML = file_get_html("http://www.babycenter.com/top-baby-names-2013");
$FirstNames= array();
$Lists =$HTML->find(‘table tr ol‘);
$Items =$Lists[($Gender == ‘F‘) ? 0 : 1];
foreach($Items->find(‘li‘) as $Item)
{
$FirstNames[ ] = $Item->find(‘a‘,0)->innertext;
}
有了想要的姓氏与常见取名清单在手中（当然，保存在内存里更为精确），我就可以利用二者构建起有趣的组合并调用Route53的checkDomainAvailability函数来查看其是否可用：
foreach($FirstNames as $FirstName)
{
foreach($TLDs as $TLD)
{
$DomainName = $FirstName . ‘-‘ . $LastName. $TLD;
$Result = $Client->checkDomainAvailability(array(
‘DomainName‘ => $DomainName,
‘IdnLangCode‘ => ‘eng‘));
}
echo "{$DomainName}:{$Result[‘Availability‘]}\n";
}
我还可以选择直接注册第一个可用名称（再次强调，建议大家商量妥当之后才采取这种机制）。我会将联系信息打包整理起来，因为接下来会多次用到：
$ContactInfo= array(
‘ContactType‘ => ‘PERSON‘,
‘FirstName‘ => ‘Jeff‘,
‘LastName‘ => ‘Barr‘,
‘OrganizationName‘ => ‘Amazon WebServices‘,
‘AddressLine1‘ => ‘XXXX Xth Avenue‘,
‘City‘ => ‘Seattle‘,
‘State‘ => ‘WA‘,
‘CountryCode‘ => ‘US‘,
‘ZipCode‘ => ‘98101‘,
‘PhoneNumber‘ => ‘+1.206XXXXXXX‘,
‘Email‘ => ‘[email protected]‘);
而后，我使用registerDomain函数来注册该域：
if($Result[‘Availability‘] === ‘AVAILABLE‘)
{
echo "Registering{$DomainName}\n");
$Result = $Client->registerDomain(array(
‘DomainName‘ => $DomainName,
‘IdnLangCode‘ => ‘eng‘,
‘AutoRenew‘ => true,
‘DurationInYears‘ => 1,
‘BillingContact‘ => $ContactInfo,
‘RegistrantContact‘ => $ContactInfo,
‘TechContact‘ => $ContactInfo,
‘AdminContact‘ => $ContactInfo,
‘OwnerPrivacyProtected‘ => true,
‘AdminPrivacyProtected‘ => true,
‘TechPrivacyProtected‘ => true,
‘BillingPrivacyProtected‘ => true));
}
基于地理位置的路由
Route 53的全新基于地理位置的路由功能允许大家选择最合适的AWS资源作为交付内容，依据自然是其与DNS请求发出地之间的实际距离了。大家现在可以让自己的应用程序提供更具效率的用户请求响应效果，因为所有响应都将依靠距离用户最近的资源实现。每一个位置（包括大陆、国家或者州/省）都能够独立与静态或者动态AWS资源实现映射。某些位置可以接收来自S3的静态资源，其它位置则可以接收由运行在EC2或者ElasticBeanstalk上的应用程序所发送的动态资源。
大家可以通过多种方式对这项功能善加利用。下面为各位列举几种比较理想的使用途径：
· 全球化应用程序——指向Amazon Elastic Compute Cloud（简称EC2）实例的路由请求与实例托管所在AWS区域必须位于同一块大陆之内。大家可以通过这种方式最大程度提升性能表现或者满足法律法规的相关要求。
· 内容管理——地用户访问的内容进行优化、定制、授权或者批准，以保证其接入与所在地理位置最近的基础设施。举例来说，大家可以为美国的红区与蓝区分别选择不同的内容与资源。或者在符合法律规定的区域之内组织竞赛或者促销活动，使用这项功能可以初步实现条件过滤。
· 端点一致性——将某些位置映射至某些端点，以确保特定位置总是映射至同一端点。如果大家运行的是一套网络游戏，那么基于地理位置的路由机制能够显著提高性能、降低延迟、带来更准确的以时间为基准的规模调整控制，并且增加具备同样生活背景与文化习惯的用户们参与同一游戏环境的可能性。
要使用这项功能，大家只需创建几套Route 53记录集，为地理位置提供路由策略即可。可以认为每一套记录集都是源自某DNS入口（例如www.jeff-barr.com）的映射体系，指向特定AWS资源——例如S3存储桶、EC2实例或者ElasticLoad Balancer。在启动之后，每一套具备地理位置策略的记录集都仅仅作用于那些来自特定大陆、国家或者州/省范围（根据IP检测实现地理定位）内DNS入口的输入请求。这些记录集能够以明确的方式实现层次划分，并识别出哪条策略使用频率最高。大家也可以创建一套默认入口，从而为那些无匹配入口的请求提供服务。
大家可以通过AWS管理控制台、Route 53API或者AWS命令行界面（简称CLI）设置这项功能。根据具体应用程序的不同，大家可能希望根据信息来源数据库的不同类型生成记录集并加以实施。
这里我假设自己希望为大多数www.jeff-barr.com网站访客提供静态内容，并单独为来自亚洲的访客提供动态内容。下面来看具体实现方法。首先，我为这个指向自己S3存储桶的“www”网站创建一套默认记录集：
接下来，我创建另一个“www”网站，并将其地理位置选择为亚洲。此站点指向ElasticLoad Balancer：
价格下调
最后但同样重要的是，我很高兴地向大家宣布，我们将标准与LBR（即基于延迟的路由机制）查询价格下调了20%。以下价格方案已经从2014年8月1日起正式实施：
1. 标准查询——每月前十亿次查询中，每百万次查询0.40美元，超出部分每百万次查询0.20美元。
2. LBR查询——每月前十亿次查询中，每百万次查询0.60美元，超出部分每百万次查询0.30美元。
3. 基于地理位置的DNS查询——每月前十亿次查询中，每百万次查询0.70美元，超出部分每百万次查询0.35美元。
现已可用
这些功能目前都已正式可用，而且价格下调也已经生效。
-- Jeff;
备注——感谢AP42网站的Steve Nelson发现并提供的互联网域注册模板！
原文链接：
http://aws.amazon.com/cn/blogs/aws/route-53-domain-reg-geo-route-price-drop/
核子可乐译