亚马逊AWS官方博客

使用 AWS Route 53 构建高可用 DNS 解析服务：从多主多备到智能健康检测的最佳实践

摘要：介绍 DNS 服务在健康监测/多主多备/zone 备份的最佳实践

一、背景与挑战

1.1 DNS 服务的战略重要性

在当今数字化转型的浪潮中，DNS（Domain Name System）作为互联网的基础设施，承担着将人类可读的域名转换为机器可识别的 IP 地址的关键职责。对于企业而言，DNS 服务不仅仅是一个简单的域名解析工具，更是保障业务连续性、优化用户体验、实现全球流量调度的核心组件。

根据行业研究数据，超过 90% 的网络故障排查都涉及 DNS 问题。一次 DNS 解析失败可能导致用户无法访问任何在线服务，即使后端应用服务器运行完全正常。因此，构建高可用、高可靠的 DNS 解析架构，已经成为企业 IT 基础设施建设的重中之重。

1.2 传统 DNS 架构面临的挑战

随着业务规模的不断扩展和用户对服务质量要求的持续提升，传统的 DNS 架构面临着越来越多的挑战：

挑战一：单点故障风险

许多企业在早期部署 DNS 服务时，往往采用简单的主备架构。当主要解析节点出现故障时，缺乏有效的自动切换机制，导致服务中断。更为严重的是，一些企业虽然部署了多个解析节点，但在主节点故障时仍需人工干预才能完成切换。根据实际运维经验，人工切换的平均响应时间通常在 15-30 分钟，对于要求高可用性的业务场景来说，这种故障恢复时间是完全不可接受的。

挑战二：健康检测的复杂性

随着微服务架构和多云部署的普及，企业需要监控的终端节点数量急剧增加。传统基于单一 IP 的健康检测方式存在以下问题：

  • 需要为每个终端节点单独配置检测规则，运维成本高
  • 配置变更频繁，容易出现配置遗漏或错误
  • 缺乏统一的监控视图，问题定位困难
  • 健康检测与 DNS 记录之间的关联关系复杂，维护成本高

如何简化健康检测配置，同时保证检测的准确性和及时性，成为运维团队面临的重要课题。

挑战三：多层 GTM 架构的协调问题

在全球流量管理（Global Traffic Management，GTM）场景中，企业通常会部署多层 DNS 解析架构。例如，第一层负责全球区域调度，第二层负责区域内的负载均衡，第三层负责具体服务的健康检测和故障切换。在这种复杂架构下，如何确保各层之间的健康检测结果相互独立又能有效协同，如何避免级联故障的发生，都是需要深入考虑的技术难点。

挑战四：配置管理与灾备

DNS 配置是企业的关键基础设施资产，包含了大量的域名记录、路由策略、健康检测规则等信息。一旦这些配置丢失或损坏，将导致严重的业务影响：

  • 域名解析完全失效，所有依赖该域名的服务不可用
  • 复杂的路由策略和健康检测规则难以快速重建
  • 配置恢复过程中可能引入新的错误
  • 缺乏配置版本管理，无法追溯历史变更

如何实现 DNS Zone 配置的自动化备份与快速恢复，是保障业务连续性的重要环节。

挑战五：跨区域一致性

对于全球化运营的企业，DNS 配置需要在多个区域保持一致性。手动同步配置不仅效率低下，还容易出现配置不一致的问题，导致不同区域的用户获得不同的解析结果，影响服务质量和用户体验。

1.3 为什么选择 AWS Route 53

AWS Route 53 是一款高度可用且可扩展的云域名系统（DNS）Web 服务，专为开发人员和企业设计，旨在以极为可靠且经济高效的方式将最终用户路由到 Internet 应用程序。Route 53 的名称来源于 DNS 服务所使用的 TCP/UDP 端口号 53。

选择 AWS Route 53 的核心优势包括：

  • 100% 可用性 SLA：AWS 承诺 Route 53 的服务可用性达到 100%
  • 全球分布式基础设施：依托 AWS 全球边缘节点，提供低延迟的 DNS 解析
  • 丰富的路由策略：支持简单路由、加权路由、延迟路由、地理位置路由、故障转移路由等多种策略
  • 原生健康检测：内置健康检测功能，可自动发现故障节点并进行流量切换
  • 与 AWS 生态深度集成：可无缝对接 ELB、CloudFront、S3 等 AWS 服务
  • 按使用付费：基于查询次数和托管区域数量计费，成本可控

二、解决方案与技术细节

2.1 利用 Weighted 路由策略实现多主多备架构

2.1.1 设计原理

Route53 中，单纯的 Failover 路由只能做到“一主一备“，切换粒度粗。通过引入 Weighted 路由作为中间层，可以优雅地实现多主多备：多个 Primary IP 各自挂载独立健康检查，以 Weighted 记录并行对外服务；Failover Alias 层指向这组 Weighted 记录，并开启 EvaluateTargetHealth。

这样带来两个层次的容灾能力：当某个 Primary IP 不健康时，Route53 自动将其从返回列表剔除，其余 Primary 继续承载流量；当所有 Primary 均不健康时，Failover 机制触发，流量整体切换至 Secondary 组，Secondary 组同样支持多 IP 的 Weighted 分发。

2.1.2 详细配置步骤

步骤一：创建Failover层

1.主从节点都设置为A记录，同时使用Alias,用于使用route53来直接解析weight-*.junxyang.site域名，避免客户端二次解析。
2.EvaluateTargetHealth设置为True，Route53 会评估 Alias 指向的那组记录的健康状况。
   2.1 Failover Alias（PRIMARY）指向 weighted-primary.junxyang.site
   2.2 那组 Weighted 记录里每个 IP 都有独立健康检查
   2.3 当所有 Weighted 记录都不健康时，Route53 认为这个 Alias 记录本身也不健康，Failover 机制触发，流量切到 SECONDARY
   2.4 如果设为 false，Alias 记录永远被视为健康，即使背后所有 Primary IP 都挂了，Failover 也不会切换

步骤二：创建Weight层

Set ID：每条 Weighted 记录都需要一个唯一的 Set ID，用于区分不同的记录
Health Check：每条记录都应关联独立的健康检测，确保能够准确判断各节点的健康状态
Weight=0 的语义 Weight 设为 0 不等于"删除"，而是"保留记录但永不返回"。这可以用来临时下线某个 IP 而不删记录，但容易和健康检查的行为混淆——健康检查失败是动态剔除，Weight=0 是静态屏蔽。

2.1.3 故障切换流程详解

  1. 正常运行状态：在正常情况下，主记录的2个IP的权重设置为50，它们会同时来承接流量，如果一个设置为100，一个设置0，则100的主IP会来承接，除非100的挂掉后，权重=0的IP才会接管。
  2. 故障检测阶段：假设当88节点出现故障时，Route 53 的健康检测机制会按照预设的检测间隔持续探测88节点。当连续失败次数达到配置的阈值时（默认为 3 次），Route 53 将该记录标记为“不健康“（Unhealthy）状态。
  3. 自动切换阶段：一旦88记录被标记为不健康，Route 53 会自动将其从可用记录池中移除。此时，226记录可用。Route 53 开始向 DNS 查询返回备份节点的 IP 地址。如果存在多个健康的备份记录，流量将在这些备份节点之间均匀分配。
  4. 故障恢复阶段：当88节点恢复正常运行后，健康检测会检测到主节点重新可用，并将其标记为“健康“（Healthy）状态。由于88记录的权重（50）和226记录（50）一样，Route 53 会自动将流量粉给2个记录，整个过程无需任何人工干预。

2.1.4 注意事项与最佳实践

  • 健康检测间隔：建议将健康检测间隔设置为 10-30 秒，以平衡检测及时性和成本。更短的间隔意味着更快的故障发现，但也会产生更多的检测费用
  • 故障切换时间计算：从主节点故障到完成切换的总时间约为：健康检测间隔 × 失败阈值 + DNS TTL + 客户端缓存时间
  • 备份节点数量：建议至少配置 2 个备份节点，以提高系统的容错能力。如果只有一个备份节点，当主节点和备份节点同时故障时，服务将完全不可用
  • 跨可用区部署：主节点和备份节点应部署在不同的可用区（Availability Zone），避免单一可用区故障影响所有节点
  • 跨区域部署：对于关键业务，建议将备份节点部署在不同的 AWS 区域（Region），以应对区域级别的故障

参考文档：Active-passive failover with weighted records

2.2 健康检测机制深度解析

Route 53 的健康检测功能是实现高可用 DNS 架构的核心组件。深入理解健康检测的各种模式和配置选项，对于构建可靠的 DNS 服务至关重要。

2.2.1 健康检测类型概述

Route 53 支持三种类型的健康检测：

类型一：终端节点健康检测（Endpoint Health Check）

直接检测指定 IP 地址或域名的健康状态，支持以下协议：

  • HTTP：向指定端口发送 HTTP GET 请求，检查返回状态码是否为 2xx 或 3xx
  • HTTPS：与 HTTP 类似，但使用 SSL/TLS 加密连接
  • TCP：尝试建立 TCP 连接，验证端口连通性
  • HTTP/HTTPS with String Matching：除了检查状态码，还验证响应内容是否包含指定字符串

类型二：计算型健康检测（Calculated Health Check）

基于其他健康检测的状态进行计算，可设置阈值判断整体健康状态。例如，当 5 个子健康检测中至少有 3 个处于健康状态时，计算型健康检测才报告为健康。

类型三：CloudWatch 告警健康检测

基于 Amazon CloudWatch 告警状态判断健康状态，适用于需要基于自定义指标（如 CPU 使用率、内存使用率、自定义业务指标等）进行健康判断的场景。

2.2.2 域名模式健康检测

Route 53 支持基于域名的健康检测模式，相比传统的 IP 模式，可以在某些场景下简化配置管理。我们仍旧以2.1的case为例，因为使用Alias的前提条件是Alias的指向的域名是同一个Host zone的其他route53记录。Alias 不能指向的目标：1.外部域名（比如直接指向 example.com，那应该用 CNAME），2.不在同一 Hosted Zone 内的 Route53 记录，所以当指向是外部域名的时候，

配置方法：

Health Check Type: Endpoint
Specify endpoint by: Domain name
Domain name: backend.example.com
Port: 80
Protocol: HTTP
Path: /health

工作原理：

  1. Route 53 首先对指定的域名进行 DNS 解析，获取 IP 地址列表
  2. 从返回的 IP 地址中随机选择其中一个进行健康检测
  3. 基于该 IP 的检测结果判断整体健康状态

适用场景：

  • 后端服务 IP 会动态变化（如使用弹性伸缩），但域名保持不变
  • 希望简化健康检测配置，减少配置维护工作量
  • 后端服务已有统一的域名入口，不希望维护 IP 列表

重要局限性：

  • 仅检测单一 IP：域名模式仅检测域名解析返回的其中一条 IP 地址的健康状况，无法检测所有 IP
  • 随机性问题：如果域名对应多个 IP，每次检测可能选择不同的 IP，导致检测结果不稳定
  • 无法精确摘除故障节点：如果域名对应的多个 IP 中有一个故障，域名模式可能无法准确检测到

最佳实践建议：

对于关键业务场景，强烈建议使用 IP 模式的健康检测，为每个终端节点创建独立的健康检测，确保能够准确检测到每个节点的健康状态。域名模式更适用于非关键场景、开发测试环境，或作为辅助检测手段。

2.2.3 健康检测失败的保底机制

一个常见的担忧是：如果所有记录的健康检测都失败了，Route 53 会返回什么结果？会不会返回空记录导致服务完全不可用？

Route 53 的保底行为：

当所有记录的健康检测都失败时，Route 53 不会返回空记录。相反，它会按照配置的路由策略返回其中一条记录（即使该记录的健康检测已失败），作为“最后的保底“。

设计理念：

这一设计的核心理念是：返回一个可能存在问题的地址，总比返回空记录导致完全无法访问要好。具体原因包括：

  1. 健康检测可能误报：网络抖动、检测点故障等原因可能导致健康检测误报，实际服务可能仍然可用
  2. 给用户重试机会：用户至少有机会尝试连接，可能在重试后成功
  3. 争取修复时间：运维团队能够争取到问题排查和修复的时间窗口
  4. 避免配置错误导致的全局故障：防止因健康检测配置错误导致服务完全中断

参考文档：How Route 53 chooses records when health checking is configured

2.2.4 计算型健康检测的应用

对于需要综合判断多个节点状态的场景，Route 53 提供了计算型（Calculated）健康检测功能。

应用场景一：判断服务整体可用性

假设您有一个服务部署了 3 个实例，业务要求只要有 2 个实例可用就认为服务整体可用：

步骤 1：为 3 个实例分别创建独立的健康检测
- Health Check A: 检测实例 1 (10.0.1.1:80)
- Health Check B: 检测实例 2 (10.0.2.1:80)
- Health Check C: 检测实例 3 (10.0.3.1:80)

步骤 2：创建计算型健康检测
- Health Check Name: service-overall-health
- Type: Calculated
- Child health checks: Health Check A, B, C
- Health threshold: 2 (至少 2 个子检测健康才认为整体健康)

应用场景二：多条件组合判断

您可以创建更复杂的健康检测逻辑，例如：

# 数据库集群健康检测
- DB Health Check 1: 主数据库
- DB Health Check 2: 从数据库 1
- DB Health Check 3: 从数据库 2
- DB Cluster Health: Calculated，阈值 = 2

# 应用服务器健康检测
- App Health Check 1: 应用服务器 1
- App Health Check 2: 应用服务器 2
- App Cluster Health: Calculated，阈值 = 1

# 整体服务健康检测
- Service Health: Calculated，包含 DB Cluster Health 和 App Cluster Health，阈值 = 2

重要局限性：

计算型健康检测适用于判断服务整体可用性，但无法自动摘除单个故障 IP。例如，如果 3 个实例中有 1 个故障，计算型健康检测仍然报告健康（因为有 2 个实例可用），但 DNS 可能仍然返回故障实例的 IP。

如果需要精确控制故障节点的自动摘除，仍需为每条 DNS 记录独立关联健康检测，而不是使用计算型健康检测。

2.2.5 多层 GTM 架构中的健康检测联动

在多层 DNS 架构中，EvaluateTargetHealth 参数起着关键作用。这个参数决定了 Alias 记录是否评估其目标记录的健康状态。

场景示例：

层级 1 (Failover Policy):
- Primary: ctslb-05-best.xxxx.net (Alias -> 层级 2)
- Secondary: ctslb-05-backup.xxxx.net

层级 2 (Weighted Policy):
- ctslb-05-cn.xxxx.net, Weight=50, Health Check=HC1
- ctslb-05-us.xxxx.net, Weight=50, Health Check=HC2

当 EvaluateTargetHealth = false：

  • 层级 1 的 Primary 记录不会评估层级 2 目标的健康状态
  • 即使层级 2 的所有 Weighted 记录都不可用，层级 1 仍然返回 Primary 记录
  • 这可能导致用户被解析到一个完全不可用的地址

当 EvaluateTargetHealth = true：

  • 层级 1 的 Primary 记录会评估层级 2 目标的健康状态
  • 如果层级 2 的所有 Weighted 记录都不可用，层级 1 认为 Primary 不健康，触发故障转移
  • Route 53 将返回层级 1 的 Secondary 记录
  • 如果层级 2 存在可用的 Weighted 记录，则正常返回该记录

最佳实践：

对于生产环境的多层 DNS 架构，强烈建议启用 EvaluateTargetHealth = true，确保健康检测结果能够在各层之间正确传递，实现端到端的故障检测和自动切换。

2.3 Alias 记录类型的正确使用

在使用 Route 53 的 Alias 功能时，记录类型的选择至关重要，错误的配置可能导致解析失败。

2.3.1 Alias 的核心概念

Alias 记录是 Route 53 特有的一种记录类型，它允许您将 DNS 查询重定向到 AWS 资源（如 ELB、CloudFront、S3）或同一托管区域中的其他记录。与传统的 CNAME 记录不同，Alias 记录：

  • 可以在区域顶点（Zone Apex，如 example.com）使用
  • 对 Alias 查询不收取额外费用
  • 解析时直接返回目标的 IP 地址，减少解析层级

2.3.2 记录类型匹配规则

核心规则：开启 Alias 后，当前记录的类型必须与其指向目标的记录类型保持一致。

正确配置示例：

# 假设目标记录
ctslb-05-cn.xxxx.net -> A 记录 (返回 IPv4 地址)

# Alias 记录配置（正确）
Record Name: ctslb-05-best.xxxx.net
Type: A  ✓ (与目标类型一致)
Alias: Yes
Alias Target: ctslb-05-cn.xxx.net

错误配置示例：

# 假设目标记录
ctslb-05-cn.xxxx.net -> A 记录 (返回 IPv4 地址)

# Alias 记录配置（错误）
Record Name: ctslb-05-best.xxxx.net
Type: CNAME  ✗ (Route 53 会提示配置失败)
Type: AAAA   ✗ (Route 53 会提示配置失败)

2.3.3 Alias vs CNAME 的选择

特性 Alias CNAME
1 Zone Apex 支持 ✓ 支持 ✗ 不支持
2 查询费用 免费 按查询计费
3 解析效率 直接返回 IP 需要额外解析
4 目标类型 AWS 资源或同 Zone 记录 任意域名
5 健康检测集成 原生支持 EvaluateTargetHealth 需要单独配置

最佳实践建议：

  • 指向 AWS 资源时，优先使用 Alias
  • 在 Zone Apex 创建记录时，必须使用 Alias（CNAME 不支持）
  • 需要减少解析延迟时，优先使用 Alias
  • 指向外部域名时，只能使用 CNAME

参考文档：Choosing between alias and non-alias records

2.4 Zone 配置的备份与恢复

为了保障业务连续性，定期备份 Route 53 的配置信息是必不可少的运维实践。以下介绍使用 AWS CLI 实现自动化备份的完整方案。

2.4.1 导出 Hosted Zone 记录

导出单个 Hosted Zone：

# 获取 Hosted Zone ID
aws route53 list-hosted-zones --query 'HostedZones[*].[Id,Name]' --output table

# 导出指定 Zone 的所有记录
aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --output json > zone-backup-$(date +%Y%m%d).json

批量导出所有 Hosted Zones：

#!/bin/bash
# backup-all-zones.sh

BACKUP_DIR="./route53-backup-$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR

# 遍历所有 Hosted Zones
for zone_id in $(aws route53 list-hosted-zones --query 'HostedZones[*].Id' --output text); do
  # 获取 Zone 名称（去除末尾的点）
  zone_name=$(aws route53 get-hosted-zone --id $zone_id --query 'HostedZone.Name' --output text | sed 's/\.$//')

  echo "Backing up zone: $zone_name ($zone_id)"

  # 导出记录集
  aws route53 list-resource-record-sets \
    --hosted-zone-id $zone_id \
    --output json > "$BACKUP_DIR/${zone_name}.json"
done

echo "Backup completed. Files saved to $BACKUP_DIR"

2.4.2 导出健康检测配置

#!/bin/bash
# backup-health-checks.sh

BACKUP_DIR="./route53-healthchecks-$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR

# 导出所有 Health Checks 列表
aws route53 list-health-checks --output json > "$BACKUP_DIR/health-checks-list.json"

# 导出每个 Health Check 的详细配置
for hc_id in $(aws route53 list-health-checks --query 'HealthChecks[*].Id' --output text); do
  echo "Backing up health check: $hc_id"
  aws route53 get-health-check \
    --health-check-id $hc_id \
    --output json > "$BACKUP_DIR/health-check-${hc_id}.json"
done

echo "Health check backup completed. Files saved to $BACKUP_DIR"

2.4.3 自动化备份最佳实践

使用 AWS Lambda 实现定时备份：

import boto3
import json
from datetime import datetime

def lambda_handler(event, context):
    route53 = boto3.client('route53')
    s3 = boto3.client('s3')
  
    backup_bucket = 'your-backup-bucket'
    timestamp = datetime.now().strftime('%Y%m%d-%H%M%S')
  
    # 备份所有 Hosted Zones
    zones = route53.list_hosted_zones()
    for zone in zones['HostedZones']:
        zone_id = zone['Id'].split('/')[-1]
        zone_name = zone['Name'].rstrip('.')
      
        # 获取所有记录
        records = route53.list_resource_record_sets(HostedZoneId=zone_id)
      
        # 上传到 S3
        s3.put_object(
            Bucket=backup_bucket,
            Key=f'route53-backup/{timestamp}/zones/{zone_name}.json',
            Body=json.dumps(records, indent=2, default=str)
        )
  
    # 备份所有 Health Checks
    health_checks = route53.list_health_checks()
    s3.put_object(
        Bucket=backup_bucket,
        Key=f'route53-backup/{timestamp}/health-checks.json',
        Body=json.dumps(health_checks, indent=2, default=str)
    )
  
    return {
        'statusCode': 200,
        'body': f'Backup completed: {timestamp}'
    }

备份存储建议：

  • 将备份文件存储到 S3，并启用版本控制（Versioning）
  • 配置 S3 生命周期规则，自动清理过期备份
  • 启用跨区域复制（Cross-Region Replication），确保备份的高可用性
  • 对备份文件启用 S3 服务器端加密（SSE）

定期恢复演练：

备份的价值在于能够成功恢复。建议：

  • 每季度进行一次恢复演练
  • 在测试环境验证备份文件的完整性和可用性
  • 记录恢复步骤和所需时间，纳入灾难恢复计划

2.4.4 配置恢复方法

当需要恢复配置时，可以使用 change-resource-record-sets API：

# 从备份文件恢复记录
# 注意：需要根据备份文件格式构造 ChangeBatch

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://restore-changes.json
恢复文件格式示例（restore-changes.json）：
{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "service.example.com",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [
          {"Value": "10.0.1.1"}
        ]
      }
    }
  ]
}

三、总结

3.1 核心要点回顾

本文深入探讨了使用 AWS Route 53 构建高可用 DNS 解析服务的最佳实践，主要涵盖以下核心内容：

一主多备架构的实现：通过巧妙配置 Weighted 路由策略，将主记录权重设置为 100，备份记录权重设置为 0，结合健康检测功能，可以实现完全自动化的故障切换。当主节点故障时，流量自动切换到备份节点；当主节点恢复时，流量自动切回，全程无需人工干预。

健康检测的深度应用：Route 53 提供了丰富的健康检测选项，包括终端节点检测、计算型检测和 CloudWatch 告警检测。域名模式可以简化配置，但仅检测单一 IP；计算型检测适合判断服务整体可用性；而 Route 53 内置的保底机制确保即使所有检测失败，仍能返回结果而非空记录。

多层架构的协调：在复杂的多层 GTM 架构中，EvaluateTargetHealth 参数是确保健康检测结果正确传递的关键。启用此参数后，上层记录能够感知下层目标的健康状态，实现端到端的故障检测。

Alias 记录的正确使用：Alias 记录类型必须与目标记录类型一致，这是一个常见的配置陷阱。正确使用 Alias 可以减少解析层级、降低查询成本，并支持在 Zone Apex 创建指向 AWS 资源的记录。

配置备份与恢复：通过 AWS CLI 或 SDK，可以轻松实现 Route 53 配置的自动化备份。结合 S3 存储和 Lambda 定时任务，可以构建完整的备份解决方案，为灾难恢复提供保障。

3.2 实施建议

在实际应用这些最佳实践时，建议遵循以下原则：

1. 充分测试：所有配置变更都应在测试环境充分验证后再应用到生产环境

2. 渐进式部署：对于复杂的架构变更，采用渐进式部署策略，逐步切换流量

3. 监控告警：配置完善的监控和告警机制，及时发现和响应异常情况

4. 文档记录：详细记录 DNS 架构设计和配置细节，便于团队协作和知识传承

5. 定期演练：定期进行故障切换和恢复演练，确保机制的有效性

3.3 展望

AWS Route 53 作为一款成熟的企业级 DNS 服务，持续在功能和性能方面进行优化。未来，我们可以期待更多的智能化特性，如基于机器学习的流量预测和自动优化、更细粒度的流量控制策略、与更多 AWS 服务的深度集成等。

通过合理利用 Route 53 的各项特性，企业可以构建出高可用、高性能、易维护的 DNS 基础设施，为业务的稳定运行和持续发展提供坚实保障。希望本文的分享能够帮助读者更好地理解和应用 AWS Route 53，在 DNS 服务的建设实践中少走弯路。

相关资源链接：

➡️ 下一步行动：

相关产品：

  • Amazon Route 53 — 能够以低延迟路由用户流量的全球域名系统（DNS）
  • Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
  • Amazon CLI — 用于管理 AWS 服务的统一工具
  • Amazon CloudWatch — 用于在 AWS、多云和混合环境中收集指标、日志和事件的可观测性工具
  • AWS Lambda — 无需考虑服务器或集群即可运行代码的服务

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

杨俊

亚马逊云科技资深解决方案架构师。加入亚马逊云科技之前，主要从事电商和零售相关的系统开发工作，具备丰富的零售行业经验和企业上云实践经验。

李莹贺

亚马逊云科技技术客户经理，主要支持互联网行业客户的架构优化、成本管理、技术咨询，提供企业级技术支持服务。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用