AWS CloudFront Deep Dive

1. CloudFront 基础与架构 (CloudFront Basics & Architecture)

Amazon CloudFront 是 AWS 的全球内容分发网络 (CDN)，旨在通过全球边缘节点网络加速静态、动态和流媒体 Web 内容的分发。

1.1 核心组件

• Edge Locations (边缘节点)：分布在全球的站点，最接近最终用户。CloudFront 在这里缓存内容以降低延迟。
• Regional Edge Caches (区域边缘缓存)：位于边缘节点和源站之间。当边缘节点没有缓存数据时，会向区域缓存请求，而不是直接回源站，进一步减少源站负载。
• Distribution (分配)：配置 CloudFront 的单位，定义了源站、缓存行为等。

1.2 支持的源站 (Origins)

• S3 Bucket：用于分发静态文件。
• MediaPackage / MediaStore：用于视频流媒体。
• ELB (Application Load Balancer)：用于动态内容。
• EC2 实例：直接作为 HTTP 服务器。
• 自定义 HTTP 后端：任何非 AWS 的本地服务器。

2. 缓存行为与性能 (Caching & Performance)

控制 CloudFront 如何缓存和分发内容是考试重点。

2.1 缓存控制

• TTL (Time to Live)：
  • 默认缓存时间为 24 小时。
  • 通过配置 Cache Behaviors 或源站发送的 Cache-Control 标头来修改对象的 TTL。
• 缓存失效 (Invalidation)：
  • 如果在 TTL 到期前需要更新内容（如紧急修复），可以提交 Invalidation 请求。
  • 注意：失效操作可能产生费用，且不如使用带版本号的文件名（Versioning）高效。
• 压缩：支持对支持的文件类型自动进行 Gzip 压缩，减少传输数据量。

2.2 缓存键 (Cache Key)

• Query Strings & Headers：默认情况下，CloudFront 可能忽略查询字符串。你可以配置 CloudFront 根据特定的 Query String、Headers 或 Cookies 来缓存不同版本的对象（例如，根据 Language header 缓存不同语言的页面）。

2.3 高可用性 (Origin Groups)

• 源站故障转移 (Origin Failover)：
  • 创建 Origin Groups，包含一个主源站和一个辅助源站。
  • 如果主源站返回特定错误代码（如 500, 502, 503, 504），CloudFront 会自动将请求路由到辅助源站。

3. 安全性 (Security)

CloudFront 是保护 Web 应用的第一道防线。

3.1 HTTPS 与 SSL/TLS

• Viewer Protocol Policy (查看器协议策略)：控制客户端到 CloudFront 的连接。
  • HTTP and HTTPS：允许两者。
  • Redirect HTTP to HTTPS：强制重定向（推荐）。
  • HTTPS Only：只允许加密连接。
• Origin Protocol Policy (源站协议策略)：控制 CloudFront 到源站的连接。
  • HTTP Only。
  • HTTPS Only。
  • Match Viewer：如果客户端用 HTTPS，CloudFront 回源也用 HTTPS。
• 自定义 SSL：支持上传自定义证书（ACM 或 IAM）以支持自定义域名（如 www.example.com）。
  • SNI (Server Name Indication)：允许在同一个 IP 上通过主机名区分多个 SSL 证书，是现代浏览器的标准，且免费。
  • Dedicated IP：为支持不支持 SNI 的旧客户端，需要支付高额费用（每 IP 每月 $600）。

3.2 访问控制

• OAC (Origin Access Control) / OAI (Origin Access Identity)：
  • 场景：限制用户只能通过 CloudFront 访问 S3，而不能直接访问 S3 URL。
  • 机制：创建一个特殊的 CloudFront 身份，修改 S3 Bucket Policy 仅允许该身份访问。OAC 是新一代推荐标准，支持更高级的安全特性（如 SSE-KMS）；OAI 是旧标准。
• Signed URLs vs Signed Cookies：
  • 用于分发付费或私有内容。
  • Signed URLs：适用于单个文件（如安装包下载）。
  • Signed Cookies：适用于多个文件（如访问整个会员网站区域、流媒体 HLS 分片）。
• Geo-restriction (地理限制)：
  • 基于白名单（Allowlist）或黑名单（Blocklist）限制特定国家的访问。

3.3 防护集成

• AWS WAF：直接集成在 CloudFront 上，防御应用层攻击（如 SQL 注入、XSS）。
• AWS Shield Standard：默认开启，防御 DDoS 攻击。

4. 边缘计算 (Edge Compute)

在离用户更近的地方运行代码，无需管理服务器。

5. 高级功能与报告 (Advanced Features & Reports)

5.1 价格等级 (Price Class)

为了节省成本，可以选择不使用全球所有节点。

• Price Class All：使用全球所有节点（性能最好，成本最高）。
• Price Class 200：排除最昂贵的区域（如南美、澳大利亚）。
• Price Class 100：仅使用美国、加拿大、欧洲节点（成本最低）。

5.2 监控与日志

• Standard Access Logs：记录详细请求信息，延迟存入 S3。
• Real-time Logs：通过 Kinesis Data Streams 实时获取日志。
• Reports：控制台提供缓存统计、热门对象、查看器数据等报告。

6. 最佳实践总结 (Exam Tips)

Note - 私有内容分发：

• 如果题目要求通过 CloudFront 安全地分发 S3 中的文件，答案通常是：配置 OAC/OAI 限制 S3 访问 + 使用 Signed URLs/Cookies 控制用户权限。

Note - 性能优化：

• 如果需要上传大文件，不要只想到 S3 Transfer Acceleration，CloudFront 也支持上传（PUT/POST）。
• 静态内容 + 动态内容混合：使用 Cache Behaviors（缓存行为）。根据路径模式（如 *.jpg 去 S3，/api/* 去 ELB）将请求路由到不同的源站。

Note - 证书管理：

• 如果在 CloudFront 上使用自定义域名，SSL 证书必须请求/导入到 US East (N. Virginia) us-east-1 区域的 ACM 中，否则 CloudFront 无法识别。

Note - SNI vs Dedicated IP：

• 题目若提到“支持旧版浏览器/不支持 SNI 的客户端”，才选 Dedicated IP（贵）。否则默认选 SNI。

Note - HTTP 错误处理：

• 可以配置 Custom Error Pages，将源站返回的 4xx/5xx 错误替换为自定义的 HTML 页面（如将 S3 的 403 Access Denied 替换为友好的“请注册”页面），并返回 200 状态码。

AWS VPC Deep Dive

1. VPC 基础与架构 (VPC Basics & Architecture)

Amazon VPC 允许你在 AWS 云中预置一个逻辑隔离的部分，在这个部分中，你可以启动定义的虚拟网络中的 AWS 资源。

1.1 核心概念

• Region (区域) 级别：VPC 是跨越整个区域（Region）的，覆盖该区域内所有的可用区（AZ）。
• CIDR 块 (Classless Inter-Domain Routing)：
  • 创建 VPC 时必须指定 IPv4 CIDR 块（例如 10.0.0.0/16）。
  • 主要 CIDR 不可修改，但可以添加辅助 IPv4 CIDR 块。
  • 支持双栈模式（同时使用 IPv4 和 IPv6）。
• Subnet (子网)：
  • AZ 级别：子网必须位于单个可用区内，不可跨越 AZ。
  • 保留地址：每个子网有 5 个 IP 地址 被 AWS 保留，不可使用（例如：.0 网络地址, .1 路由器, .2 DNS, .3 预留, .255 广播地址）。
• 子网类型：
  • 公有子网 (Public Subnet)：路由表中包含指向 Internet Gateway (IGW) 的路由。
  • 私有子网 (Private Subnet)：没有直接指向 IGW 的路由。
  • VPN-only 子网：流量路由到 Virtual Private Gateway (VGW)。

1.2 默认 VPC vs 非默认 VPC

• 默认 VPC：每个 Region 自带，自动配置了 IGW，实例启动时自动分配公有 IP。
• 非默认 VPC：完全隔离，需要手动配置 IGW、路由表等。

2. 路由与互联网连接 (Routing & Connectivity)

如何让 VPC 内部的资源访问互联网或被互联网访问，取决于网关配置。

2.1 Internet Gateway (IGW)

• 作用：实现 VPC 与互联网之间的双向通信（IPv4/IPv6）。
• 特性：水平扩展、高可用、无带宽限制。
• 配置：一个 VPC 只能附加一个 IGW。必须在路由表中配置 0.0.0.0/0 指向 IGW。

2.2 NAT 设备 (仅 IPv4)

用于允许私有子网中的实例访问互联网（如下载补丁），但阻止互联网主动发起连接。

• NAT Gateway (推荐)：
  • 托管服务：AWS 负责高可用和扩展性。
  • 位置：必须部署在 公有子网 中。
  • IP 要求：必须绑定一个 Elastic IP (EIP)。
  • 可用性：虽然 NAT Gateway 是区域级服务，但它是在特定 AZ 中创建的。为了实现多 AZ 高可用，应在每个 AZ 创建一个 NAT Gateway。
  • 限制：不支持安全组（Security Groups），使用 NACL 控制流量。
• NAT Instance (旧版)：
  • 使用 EC2 实例配置。需手动管理修补和扩容。
  • 关键配置：必须在 EC2 实例设置中 禁用源/目标检查 (Disable Source/Destination Check)。

2.3 Egress-Only Internet Gateway (仅 IPv6)

• 作用：IPv6 版本的 NAT。允许 VPC 内的 IPv6 实例出站通信，拒绝入站通信。
• 特性：有状态（Stateful），即出站请求的返回流量是被允许的。

3. 安全性 (Security)

SAA 考试核心考点：必须清晰区分安全组和网络 ACL。

• 临时端口 (Ephemeral Ports)：配置 NACL 时，记得允许 1024-65535 端口的返回流量，否则 NAT Gateway 或 Lambda 可能无法工作。
• VPC Block Public Access (BPA)：新功能，可在 VPC 或子网级别声明性地阻止互联网访问。

4. 网络组件与服务 (Network Components & Services)

4.1 Route Tables (路由表)

• 规则：
  • 每个子网必须关联一个路由表（未显式关联则使用主路由表）。
  • 最长前缀匹配 (Longest Prefix Match)：路由优先级由最具体的路由决定（CIDR 范围越小优先级越高）。
  • Local 路由：每个路由表自带一条 Local 路由，用于 VPC 内部通信，不可删除。

4.2 IP 地址

• Elastic IP (EIP)：静态公有 IPv4 地址。如果分配了 EIP 但未附加到运行中的实例，AWS 会收取闲置费。
• DHCP Option Sets：配置域名服务器和域名。创建后不可修改，只能新建并关联。

4.3 DNS 支持

• 要使 VPC 内的实例拥有公有 DNS 主机名，必须将 VPC 属性 enableDnsHostnames 和 enableDnsSupport 都设置为 true。

5. VPC 连接选项 (Peering & Endpoints)

5.1 VPC Peering (对等连接)

• 作用：连接两个 VPC（同账号或跨账号、同区域或跨区域），流量走 AWS 骨干网。
• 限制：
  • CIDR 块不能重叠。
  • 不可传递 (Non-transitive)：A 连接 B，B 连接 C，A 不能直接访问 C（除非再建立 A-C 连接）。

5.2 VPC Endpoints (终端节点)

无需通过公网（IGW/NAT）即可私有访问 AWS 服务（如 S3, DynamoDB）。

• Gateway Endpoints (网关终端节点)：
  • 支持服务：仅支持 S3 和 DynamoDB。
  • 原理：在路由表中添加一条路由，目标是 AWS 服务的 Prefix List。
  • 成本：免费。
• Interface Endpoints (接口终端节点 / PrivateLink)：
  • 支持服务：大多数其他 AWS 服务（如 SQS, SNS, Kinesis 等）。
  • 原理：在子网中创建一个带有私有 IP 的弹性网络接口 (ENI)。
  • 成本：按小时和流量收费。

5.3 VPN & Direct Connect

• AWS Managed VPN：通过 Internet 建立 IPSec 隧道。
  • VGW (Virtual Private Gateway)：AWS 端的 VPN 集中器。
  • CGW (Customer Gateway)：客户本地数据中心的物理或软件设备。
• Direct Connect (DX)：专用物理专线，不经过公网，提供更稳定和高带宽的连接。

6. 监控与高级功能 (Monitoring & Advanced Features)

6.1 VPC Flow Logs (流日志)

• 作用：捕获进出 VPC 网络接口的 IP 流量元数据（源 IP、目标 IP、端口、协议、接受/拒绝状态）。
• 存储：可发布到 CloudWatch Logs 或 S3。
• 限制：不是实时包捕获（Packet Capture），不包含数据包内容，仅包含元数据。
• 用途：故障排查（如查看为何 SSH 被拒绝）、安全审计。

6.2 VPC Traffic Mirroring (流量镜像)

• 作用：复制实际的网络流量（Payload）并发送到安全设备或监控设备进行深度包检测。

6.3 IPAM (IP Address Manager)

• 作用：集中规划、跟踪和监控整个 AWS 组织中的 IP 地址使用情况，防止 IP 重叠。

7. 最佳实践总结 (Exam Tips)

Note - S3 访问问题：如果私有子网中的实例访问 S3 超时，检查是否配置了 Gateway Endpoint。如果是跨区域访问 S3，Gateway Endpoint 不支持，需使用 Interface Endpoint 或 NAT Gateway。

Note - Bastion Host (堡垒机)：应部署在公有子网，安全组仅允许来自管理员 IP 的 SSH/RDP 访问。

Note - 排查连接性问题：

• 如果由 Security Group 引起：出站通常是通的，检查入站规则。
• 如果由 NACL 引起：检查出站和入站规则（因为它是无状态的）。
• 检查路由表是否正确指向了 IGW 或 NAT。

Note - IPv4 耗尽：如果子网 IP 不够用，无法扩展现有 CIDR，但可以向 VPC 添加辅助 CIDR 块（Secondary CIDR），然后在新 CIDR 中创建新子网。或者使用 IPv6 子网。

Note - High Availability (HA)：始终在至少两个可用区（AZ）中设计架构。NAT Gateway 和 Bastion Host 都应是多 AZ 部署。

AWS SQS Deep Dive

1. SQS 基础与架构 (SQS Basics & Architecture)

Amazon SQS 是一种完全托管的消息队列服务，用于解耦（Decouple）和集成微服务、分布式系统及无服务器应用程序。

1.1 核心机制

• Pull Based (基于拉取)：SQS 不会将消息推送给消费者。消费者必须主动轮询（Poll）队列以检查新消息。
• 解耦：生产者（Producer）和消费者（Consumer）不需要同时在线。消息会存储在队列中，直到被处理或过期。
• 持久性：消息存储在多个服务器上以确保持久性。
• 消息大小限制：
  • 单个消息最大 256 KB。
  • 若需传输更大的数据，需配合 Amazon S3 使用（通常称为 SQS Extended Client Library 模式，将数据存 S3，消息存 S3 的引用）。
• 消息保留期 (Retention Period)：
  • 默认：4 天。
  • 范围：1 分钟 到 14 天。

2. 队列类型 (Queue Types)

这是考试中极高频的考点，必须清晰区分两种队列的适用场景。

2.1 标准队列 (Standard Queues)

• 适用场景：吞吐量要求高，对顺序要求不严格的场景。
• 吞吐量：几乎无限 (Unlimited Throughput)。
• 排序：Best-Effort Ordering（尽力而为的排序）。消息可能不会按照发送顺序被接收。
• 交付保证：At-Least-Once Delivery（至少一次交付）。极少数情况下，同一条消息可能会被传递多次（消费者必须设计为幂等性 Idempotent，即处理多次和处理一次结果相同）。

2.2 FIFO 队列 (先进先出)

• 适用场景：必须严格保证顺序，且不能有重复消息的场景（如银行交易、库存扣减）。
• 命名规则：名称必须以 .fifo 结尾。
• 吞吐量：
  • 默认：最高 300 TPS (发送/接收/删除)。
  • 启用批处理 (Batching)：最高 3,000 TPS。
• 排序：First-In-First-Out（严格保序）。
• 交付保证：Exactly-Once Processing（精确一次处理）。通过去重机制防止重复消息。
• 去重机制：
  • Message Deduplication ID：用于识别重复消息。
  • Message Group ID：用于在同一队列中对消息进行分组，组内有序，不同组并行处理。

3. 轮询与可见性超时 (Polling & Visibility)

3.1 短轮询 vs 长轮询 (Short Polling vs Long Polling)

• 短轮询 (Short Polling)：
  • 行为：立即返回响应，即使队列为空。只查询部分服务器，可能无法返回所有可用消息。
  • 缺点：如果队列经常为空，会导致大量的空请求，增加 API 调用成本。
  • 设置：ReceiveMessageWaitTimeSeconds = 0。
• 长轮询 (Long Polling)：
  • 行为：如果队列为空，SQS 会等待一段时间（最长 20 秒），直到有消息到达才返回。
  • 优势：降低成本（减少空响应的 API 调用），消除假空响应。
  • 设置：ReceiveMessageWaitTimeSeconds > 0（通常设为 20秒）。

Note: 长轮询是考试中的推荐/考点。

3.2 可见性超时 (Visibility Timeout)

• 机制：当消费者接收到消息后，该消息不会立即从队列删除，而是在一段时间内对其他消费者“不可见”。这防止了多个消费者处理同一条消息。
• 时间设置：
  • 默认：30 秒。
  • 范围：0 秒 到 12 小时。
• 处理逻辑：
  • 处理成功：消费者必须在超时前显式调用 DeleteMessage 删除消息。
  • 处理失败/超时：如果超时时间内未删除，消息会重新变回“可见”状态，其他消费者可以再次接收并处理（重试机制）。
  • 延长超时：如果处理时间长于预期，消费者需调用 ChangeMessageVisibility API 延长超时时间。

4. 高级功能与架构模式

4.1 死信队列 (Dead-Letter Queue, DLQ)

• 作用：用于隔离无法被成功处理的消息（Poison Pill），方便后续排查分析。
• 触发条件：当消息的接收次数（MaximumReceives）超过设定阈值时，SQS 自动将消息移动到 DLQ。
• 限制：
  • 标准队列的 DLQ 必须是标准队列。
  • FIFO 队列的 DLQ 必须是 FIFO 队列。
• Redrive Policy：定义将消息移动到 DLQ 的规则。

4.2 延迟队列 (Delay Queues)

• 作用：让新发送到队列的消息在特定时间内（DelaySeconds）对消费者不可见。
• 范围：0 秒 到 15 分钟。
• 区别：
  • Delay Queue：作用于队列级别，所有新消息都延迟。
  • Message Timer：作用于单条消息级别，仅特定消息延迟。

4.3 扇出模式 (Fan-Out Pattern)

• 架构：SNS Topic + SQS Queues。
• 流程：消息发送到 SNS Topic，然后 SNS 将消息推送到订阅了该 Topic 的多个 SQS 队列。
• 优势：实现并行异步处理。例如，一个订单消息发送到 SNS，被推送到“库存队列”和“邮件通知队列”，两个系统互不影响。

5. 安全性与监控

5.1 访问控制

• IAM Policies：控制谁可以访问 SQS API（用户、角色）。
• SQS Queue Access Policy（基于资源的策略）：
  • 类似于 S3 Bucket Policy。
  • 跨账号访问：允许其他 AWS 账号访问你的队列。
  • 服务集成：允许其他 AWS 服务（如 S3 Event Notifications, SNS）向队列发送消息。

5.2 网络安全

• VPC Endpoints (Interface Endpoint)：
  • 通过 AWS PrivateLink 在 VPC 内部访问 SQS，无需经过公网，无需配置 Internet Gateway 或 NAT。
  • 可以配置 VPC Endpoint Policy 限制访问。

5.3 加密

• SSE (Server-Side Encryption)：
  • 使用 SSE-SQS（默认）或 SSE-KMS（可自定义密钥权限）。
  • 加密静态数据（消息正文），但不加密队列元数据（如队列名称、属性）。

6. 计费与限制

1. 计费：按请求数量计费（每 100 万次请求）。
   • 批量操作（Batch Send/Delete, 10条消息或256KB以内）视为 1 次请求，有助于降低成本。
   • 数据传输费用（出站流量收费，同一区域 EC2 传入免费）。
2. 限制：
   • Inflight Messages (传输中消息)：
     • 标准队列：约 120,000 条。
     • FIFO 队列：20,000 条。
     • 定义：已被消费者接收但尚未删除或未过期的消息。

7. 最佳实践总结 (Exam Tips)

Note - 成本优化：如果发现空响应很多，或者 API 调用费用过高，务必启用长轮询 (Long Polling)。

Note - 应用解耦：当题目提到“EC2 实例处理速度跟不上请求速度”或“需要缓冲流量峰值”时，首选 SQS。

Note - 顺序性与性能：

• 如果只需高性能，不介意极少数重复或乱序 -> Standard Queue。
• 如果必须保证顺序（如银行流水）-> FIFO Queue。

Note - 超时处理：如果任务处理时间不确定，建议在代码中不断“心跳”并调用 ChangeMessageVisibility 延长超时，而不是一开始设置巨大的超时时间。

Note - Lambda 集成：SQS 可以作为 Lambda 的事件源（Event Source），Lambda 会自动轮询队列。如果是 FIFO 队列触发 Lambda，Lambda 会按顺序处理每组消息，失败会阻塞后续同组消息的处理。

AWS S3 Deep Dive

1. S3 基础与架构 (S3 Basics & Architecture)

Amazon S3 是一种对象存储服务，提供无限的存储容量，数据以对象（Object）的形式存储在存储桶（Bucket）中。

1.1 基本概念

• Bucket (存储桶)：存储对象的容器。
  • 命名规则：必须是全局唯一的 DNS 兼容名称（全 AWS 唯一）。创建后不能更改名称或区域。
  • 限制：默认每个账号 10,000 个存储桶（可申请提升至 100 万个）。
  • 目录存储桶 (Directory Buckets)：专用于 S3 Express One Zone 的新类型，旨在实现个位数毫秒级延迟。
• Object (对象)：由文件数据和元数据组成。每个对象通过 Key (唯一标识符) 在桶内进行索引。
  • 大小限制：单个对象最大支持 5 TB。超过 5 GB 的对象必须使用分段上传 (Multipart Upload) API。
• 区域性：虽然 Bucket 名称是全局的，但数据物理存储在创建时选择的区域（Region）中，除非配置复制，否则数据不会离开该区域。

1.2 数据一致性模型 (Data Consistency Model)

• 强一致性 (Strong Consistency)：对于所有 S3 操作（包括 PUT 新对象、覆盖或删除现有对象），S3 现在提供“写入后读取”的强一致性。写入成功后，任何后续的读取请求都会立即收到最新版本。
• 最终一致性 (例外情况)：仅适用于 Bucket 级别的配置更改（如启用版本控制）或 Bucket 的删除列表。

2. 存储类型 (Storage Classes)

选择正确的存储类型是 SAA 考试的重点，主要基于访问频率和持久性需求。

2.1 频繁访问层 (Frequently Accessed)

• S3 Standard：
  • 适用场景：通用型存储，适用于频繁访问的数据。
  • 可用性：99.99% 可用性，数据存储在 >=3 个可用区 (AZ)。
• S3 Express One Zone：
  • 适用场景：高性能、延迟敏感型应用。
  • 性能：提供个位数毫秒级延迟（比 Standard 快 10 倍），成本降低 50%。
  • 架构：数据仅存储在 1 个 AZ (Directory Bucket)，持久性较低。

2.2 不频繁访问层 (Infrequently Accessed)

适用于长期存储但偶尔需要立即访问的数据。对象最小计费容量为 128 KB，最短存储期限为 30 天。

• S3 Standard-IA (Infrequent Access)：
  • 架构：数据存储在 >=3 个 AZ。适用于需要高持久性但访问较少的数据。
• S3 One Zone-IA：
  • 架构：数据仅存储在 1 个 AZ。
  • 风险：成本比 Standard-IA 低 20%，但如果是物理 AZ 损毁，数据将丢失。适用于可重建的数据或辅助备份。

2.3 智能分层 (Intelligent-Tiering)

• 机制：监控访问模式并在不同层级间自动移动对象，无检索费用，无管理开销。
• 层级流转：
  • 频繁层 -> (30天无访问) -> 不频繁访问层。
  • -> (90天无访问) -> 归档即时访问层 (Archive Instant Access)。
  • 可选异步归档：可配置在 90 天或 180 天后移动到 Deep Archive。
• 自动恢复：如果对象被访问，它会自动移回频繁访问层。

2.4 归档层 (Glacier)

用于长期归档，成本极低，但检索需要时间（除 Instant Retrieval 外）。

• S3 Glacier Instant Retrieval：
  • 特点：毫秒级检索，适用于每季度访问一次的数据。节省存储成本但检索费用高于 Standard-IA。
• S3 Glacier Flexible Retrieval：
  • 检索模式：
    • Expedited (加急): 1-5 分钟。
    • Standard (标准): 3-5 小时（默认）。
    • Bulk (批量): 5-12 小时（最便宜/免费检索）。
  • 最短存储期：90 天。
• S3 Glacier Deep Archive：
  • 特点：最低成本存储（替代磁带库）。
  • 检索时间：12 小时 (Standard) 或 48 小时 (Bulk)。
  • 最短存储期：180 天。

3. 存储桶管理与高级功能

3.1 版本控制 (Versioning)

• 作用：防止意外覆盖和删除。启用后，所有版本都会保留（包括删除标记 Delete Marker）。
• 删除逻辑：
  • 如果不指定版本 ID 进行 DELETE，S3 仅插入一个“删除标记”，对象看起来已删除（404错误），但可恢复。
  • 只有指定版本 ID 才能永久删除对象。
• MFA Delete：要求在更改版本状态或永久删除对象版本时提供 MFA 令牌，增加安全性。

3.2 生命周期管理 (Lifecycle Management)

通过规则自动管理对象生命周期。

• 转换操作 (Transition)：将对象移动到更便宜的存储类（例如：Standard -> IA -> Glacier）。
  • 限制：转入 S3-IA 或 One Zone-IA 前必须在当前层存储至少 30 天。
• 过期操作 (Expiration)：定义对象何时过期并由 S3 自动删除。

3.3 对象锁定 (Object Lock)

• WORM 模型：Write Once, Read Many。防止对象在固定时间内被删除或覆盖。
• 模式：
  • Retention Period：在保留期内锁定。
  • Legal Hold：无限期锁定，直到手动移除。
• 注意：仅适用于启用了版本控制的存储桶。

3.4 性能优化功能

• S3 Transfer Acceleration：利用 CloudFront 的全球边缘节点加速远距离上传/下载。启用后会获得专用端点 bucket.s3-accelerate.amazonaws.com。
• Multipart Upload：对于 >5 GB 的文件必须使用，建议 >100 MB 时使用，以提高上传稳定性和速度。
• S3 Select：使用 SQL 语句仅检索对象（CSV/JSON/Parquet）中的部分数据，减少传输流量并提高性能。

4. 安全性与访问控制

4.1 访问控制策略

S3 提供多层访问控制，默认情况下所有资源都是私有的。

• Bucket Policies (存储桶策略)：
  • 基于资源的策略，控制整个存储桶的访问。
  • 可基于 IP、VPC 端点、MFA 等条件允许或拒绝访问。
  • 强制 SSL：通过策略拒绝 aws:SecureTransport: false 的请求来强制使用 HTTPS。
• ACLs (访问控制列表)：
  • 旧版功能，默认禁用（Bucket Owner Enforced）。建议使用 Bucket Policy 替代。
• IAM Policies：基于身份的策略，授予用户或角色访问 S3 的权限。

4.2 加密 (Encryption)

支持静态和传输中加密。

• 服务端加密 (Server-Side Encryption)：
  • SSE-S3：使用 S3 托管密钥，现为所有桶的默认加密方式。
  • SSE-KMS：使用 AWS KMS 密钥，提供审计跟踪（CloudTrail 记录）和更细粒度的权限控制。
  • SSE-C：客户提供密钥，AWS 进行加密/解密操作，AWS 不存储密钥。
• 客户端加密：数据在上传前由客户端加密。

4.3 阻止公有访问 (Block Public Access)

AWS 建议在账号或存储桶级别启用此功能，防止意外的数据泄露。

5. 复制与数据保护

5.1 跨区域复制 (CRR) & 同区域复制 (SRR)

• 前提条件：源桶和目标桶都必须 开启版本控制。
• 复制内容：配置后创建的新对象、元数据、对象标签、SSE-S3 和 SSE-KMS 加密的对象（需额外配置）。
• 不复制内容：配置前的存量对象、SSE-C 加密对象、源桶中本身也是复制品的副本（不通过链式复制）。
• 删除行为：如果不指定版本 ID 的删除（即添加删除标记），删除标记会被复制；但指定版本的永久删除 不会 被复制，以防恶意删除。
• RTC (Replication Time Control)：提供 SLA，保证 15 分钟内完成复制。

5.2 数据完整性

• Checksums：S3 在上传和检索时使用 CRC 校验和验证数据完整性，自动修复损坏数据。

6. S3 新特性与特殊功能

6.1 S3 Tables

• 用途：基于 Apache Iceberg 格式存储表格数据，专为分析工作负载设计。
• 优势：相比通用 S3 桶，提供更高的查询吞吐量和自动维护（压缩、快照管理）。
• 集成：可直接与 Athena, Redshift, QuickSight 集成。

6.2 静态网站托管 (Static Website Hosting)

• 端点区别：
  • REST API 端点：支持 SSL，支持私有内容。
  • 网站端点：不支持 SSL（需配合 CloudFront 实现 HTTPS），仅支持公开可读内容，支持重定向和索引文档。
• 权限：必须配置 Bucket Policy 允许 s3:GetObject 权限给所有人。

6.3 S3 Storage Lens

• 功能：全组织级别的可见性工具，用于分析存储使用情况、活动趋势，并提供成本优化建议。

7. 计费与定价模型

S3 遵循“按使用量付费”原则，主要收费点如下：

1. 存储费：按对象大小、存储时长和存储类型（Storage Class）收费。
2. 请求费：GET, PUT, LIST 等 API 调用次数。
3. 检索费：针对 Standard-IA, One Zone-IA 和 Glacier 类别的读取收费。
4. 数据传输费：
   • 传入数据（Inbound）：免费。
   • 传出数据（Outbound）：收费（传至同一区域的 EC2 或 CloudFront 免费）。
5. 管理费：如清单（Inventory）、分析、对象标签等。

• Requester Pays (请求者付费)：
  • 配置后，请求数据的人支付请求费和数据传输费，桶主仅支付存储费。
  • 请求者必须在请求头中包含 x-amz-request-payer。

8. 最佳实践总结 (Exam Tips)

Note - 性能优化：对于高吞吐量需求，S3 请求支持并行化。使用 Multipart Upload 加速大文件上传；使用 Range GET 并行下载文件部分。

Note - 安全性排查：若无法通过 HTTPS 访问，检查 Bucket Policy 是否包含 aws:SecureTransport 条件。

Note - 合规性：若要求数据保留特定时长且不可删除，务必使用 Object Lock (Compliance Mode)。

Note - 成本优化：对于访问模式不可预测的数据，首选 Intelligent-Tiering。

Note - 跨账号访问：可以通过 Bucket Policy（资源策略）直接授予另一个 AWS 账号权限，或者使用 IAM Role 进行跨账号访问。

Amazon RDS (关系型数据库服务)

第一章：RDS 基础与架构

Amazon RDS 是一种托管的关系型数据库服务，负责备份、软件补丁、自动错误检测和恢复。

• DB 实例限制：每个账号默认最多可拥有 40 个 RDS 实例。
• 基本单位：DB Instance 是云中隔离的数据库环境。
• DB 引擎支持：Aurora, MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server。
• 自动迁移：支持通过控制台利用 AWS DMS 将 EC2 上的自建数据库自动迁移至 RDS。

第二章：数据库引擎细节与限制

1. MySQL / MariaDB

• 存储引擎：推荐使用 InnoDB（它是唯一支持崩溃恢复的引擎，是 RDS 的强制要求）。
• 表数量限制：对于 MySQL，若使用 PIOPS 或通用存储且容量 >= 200 GiB，限制为 10,000 张表；若容量 < 200 GiB，限制为 1,000 张表。
• 安全特性：支持 validate_password 插件强制执行密码策略。

2. Microsoft SQL Server

• 许可模式：支持“包含许可 (License Included)”和“自带许可 (BYOL)”。
• 数据库限制：单个实例支持的数据库数量取决于实例类和可用模式（如 Single-AZ, Multi-AZ DBM/AG），范围从 30 到 100 个不等。

3. Oracle

• 架构支持：支持多租户架构（CDB/PDB）。
• 标识符：使用 ORACLE_SID 进行连接。
• 安全集成：支持通过 AWS Secrets Manager 管理主用户密码。

第三章：存储与自动扩展

1. 存储类型

• 通用型 SSD (gp2/gp3)：适用于大多数数据库工作负载。
• 预置 IOPS SSD (io1)：专为 OLTP 业务设计。MySQL/MariaDB/Postgres/Oracle 支持最高 80,000 IOPS，SQL Server 支持最高 64,000 IOPS。
• 磁性存储 (Magnetic)：传统类型，不支持弹性卷，最大 3 TiB 且限 1,000 IOPS。

2. 存储自动扩展 (Storage Auto Scaling)

• 机制：在无停机的情况下，根据工作负载增长自动增加存储容量。
• 限制：SQL Server 在使用磁性存储时不支持此功能。

第四章：高可用性 (Multi-AZ) 深度解析

Multi-AZ 是 RDS 的灾难恢复（DR）解决方案。

• 同步复制：主实例数据实时同步到不同 AZ 的备用实例（Standby）。
• 故障转移触发条件：
  1. 可用区 (AZ) 停机。
  2. 主实例发生故障。
  3. 更改了实例规格（Instance Class）。
  4. 操作系统进行软件补丁维护。
  5. 用户手动启动重启（带故障转移选项）。
• 故障转移机制 (Failover Mechanism)：
  RDS 的故障转移是自动处理的，无需人工干预。当主实例发生故障时，Amazon RDS 会自动将实例的 规范名称记录 (CNAME) 指向备用实例，随后备用实例被提升为新的主实例。这种机制允许应用程序在尽量短的时间内恢复数据库操作。
• 性能注意：备份操作会在备用实例上运行，以消除主实例的 I/O 停顿。

第五章：只读副本 (Read Replicas)

只读副本用于扩展读取性能。

• 异步复制：从主实例异步同步数据。
• 扩展能力：最多支持 5 个只读副本。
• 跨区域能力：支持跨区域只读副本，用于降低全球延迟。
• 备份要求：创建只读副本前，主实例必须开启自动备份（保留期 > 0）。
• 引擎差异：PostgreSQL 使用物理复制；MySQL 和 MariaDB 使用逻辑复制。
• 提升功能：可以将只读副本提升为独立的单实例数据库。

第六章：备份与恢复

• 自动备份 (Automated Backups)：
  • 捕获整个实例的快照和事务日志。
  • 保留期：0（关闭）到 35 天。
  • 删除实例时，自动备份会被一并删除，除非手动选择保留。
• 手动快照 (DB Snapshots)：
  • 由用户触发，存储在 S3。
  • 即使删除 DB 实例，手动快照也会永久保留。
• 恢复逻辑：恢复操作总是创建一个带有新终端节点（Endpoint）的新 DB 实例。

第七章：安全性与连接

• IAM 数据库身份验证：适用于 MySQL 和 PostgreSQL，使用 IAM 角色/用户生成的临时令牌登录，无需在应用中存储密码。
• 加密：使用 AWS KMS 密钥。无法在现有的未加密实例上直接开启加密，必须通过“快照 -> 拷贝并加密快照 -> 还原”来转换。
• SSL/TLS：支持加密客户端与数据库之间的传输数据。
• RDS Proxy：
  • 建立连接池以减少 CPU/内存开销。
  • 将故障转移时间缩短约 66%。
  • 增加安全性（支持 Secrets Manager 集成）。

第八章：高级部署与集成

• Blue/Green 部署：创建一个绿色（Staging）环境镜像生产环境，用于安全地测试变更（如引擎升级）。支持存储初始化以缓解“懒加载”导致的性能抖动。
• Zero-ETL 集成：支持将数据从 RDS (PostgreSQL/Oracle) 自动同步到 Amazon Redshift 进行分析，无需构建复杂的 ETL 流。
• 增强监控 (Enhanced Monitoring)：
  • CloudWatch：从 Hypervisor 层获取指标（如 CPU）。
  • 增强监控：通过实例上的 Agent 获取 OS 层的指标（如各进程的 IOPS、延迟、队列深度）。

第九章：最佳实践总结

• DNS TTL：如果应用缓存了 DNS，务必将 TTL 设置为少于 30 秒，否则故障转移后应用可能仍尝试连接旧 IP。
• 性能排查：使用 Performance Insights 可视化分析 SQL 查询导致的等待时间。
• 实例维护：数据库状态显示为 maintenance 时，表示正在应用计划内的系统更新。
• 存储预警：务必设置 CloudWatch 报警监控存储空间，避免进入 storage-full 这一关键状态。

AWS Auto Scaling Deep Dive

AWS Auto Scaling 允许你根据定义的条件自动增加或减少资源容量，确保在需求高峰时保持性能，在需求低谷时降低成本。它不仅限于 EC2，而是能够横跨多种 AWS 服务进行资源管理。

第一章：基础概念与架构

1.1 核心价值

• 提高可用性 (Availability)：自动替换不健康实例，确保高峰期有足够资源。
• 降低成本 (Cost Optimization)：低谷期自动减量，避免为闲置资源付费。
• 自动化管理：消除人工干预，实现系统自愈。

1.2 Auto Scaling Group (ASG)

ASG 是管理 EC2 实例集合的逻辑单元：

• 容量设置：
  • Minimum (最小容量)：ASG 必须保持的最少实例数。
  • Maximum (最大容量)：允许扩展到的最大实例数，防止成本失控。
  • Desired Capacity (期望容量)：当前应运行的数量。ASG 会不断监控以确保实际数量等于期望值。
• 跨可用区平衡 (AZ Rebalancing)：ASG 会尝试在多个可用区 (AZ) 之间均匀分布实例。如果某个 AZ 的实例过多，它在缩容时会先在该 AZ 终止实例。

第二章：启动配置 (Launch Configuration) vs 启动模板 (Launch Template)

定义“扩展时启动什么样机器”的基础配置。

第三章：扩展策略 (Scaling Policies)

3.1 动态扩展 (Dynamic Scaling)

• 目标跟踪 (Target Tracking)：最推荐。设置目标值（如“保持 CPU 50%”），ASG 自动创建警报并自动伸缩。
• 步进扩展 (Step Scaling)：根据警报严重程度分阶段操作。如 CPU > 50% (+1)，> 80% (+3)。
• 简单扩展 (Simple Scaling)：基于单一警报执行单一操作，强依赖于冷却时间 (Cooldown) 以防止抖动。

3.2 预测性扩展 (Predictive Scaling)

• 机制：使用机器学习分析历史流量模式，提前预置容量。
• 优势：消除了响应式扩展的延迟，使实例在流量到达前就绪。目前仅适用于 EC2 Auto Scaling。

3.3 计划扩展 (Scheduled Scaling)

• 机制：基于已知的时间表（如 Cron 表达式）进行扩展。比如每周五下午 5 点或每月第一天。

第四章：健康检查与生命周期

4.1 健康检查 (Health Checks)

• EC2 Status Checks (默认)：仅监控基础设施或系统层。Web 应用挂了但 OS 没挂时，检查可能仍显示健康。
• ELB Health Checks (推荐)：关联负载均衡器。如果 ELB 发现应用层（如 HTTP 200）响应失败，ASG 会自动终止并替换该实例。
• Standby 状态：将实例设为 Standby 可暂时将其移出服务进行排错，此时不会触发健康检查。

4.2 冷却时间与预热

• Cooldown (冷却时间)：在扩展完成后暂停后续操作（默认 300s），主要用于简单扩展。
• Warmup (实例预热)：用于步进/目标跟踪策略，让新实例在产生有效指标前不计入聚合计算。

4.3 生命周期挂钩 (Lifecycle Hooks)

在实例启动 (Pending:Wait) 或终止 (Terminating:Wait) 时暂停流程，以便执行自定义脚本（如下载代码、上传日志、清理缓存）。默认等待 1 小时。

第五章：终止策略 (Termination Policies)

当 ASG 需要缩容 (Scale In) 时，决定先删除哪台实例：

1. 默认策略 (Default)：
   • 优先选实例最多的可用区 (AZ Rebalancing)。
   • 选择使用最旧启动模板/配置的实例。
   • 选择最接近下一个计费小时的实例。
2. 自定义策略：
   • OldestInstance：删除最旧实例（用于升级整个组）。
   • NewestInstance：删除最新实例（用于测试）。
   • Scale-In Protection：受保护的实例不会因缩容而被终止。

第六章：高级运维功能

• 实例刷新 (Instance Refresh)：滚动更新 ASG 中的实例（如更新 AMI）。支持检查点 (Checkpoints) 和回滚。
• 热池 (Warm Pools)：维护一组预初始化（已启动并停止）的实例，显著缩短扩展时的启动时间。
• 根卷替换 (Root Volume Replacement)：在不替换整个实例的情况下刷新根 EBS 卷。

第七章：Application Auto Scaling

Auto Scaling 是一项通用服务，除 EC2 外还支持：

• Amazon ECS：调整任务 (Task) 数量。
• Amazon DynamoDB：调整预置读写容量 (RCU/WCU)。
• Amazon Aurora：动态调整读取副本的数量。
• AWS Lambda：调整预置并发量。

第八章：安全性与定价

• 安全性 (IAM)：使用 Service-Linked Role (AWSServiceRoleForAutoScaling) 赋予 ASG 调用 EC2、ELB 等服务的权限。
• 定价：Auto Scaling 服务本身免费。仅对所创建的 EC2、CloudWatch 警报或相关底层资源按正常费率收费。

第九章：最佳实践总结 (Exam Tips)

• 高可用性 (HA)：始终跨至少两个 AZ 部署，设置 Min 值 > 0。
• 健康检查配置：如果使用了负载均衡器，务必启用 ELB Health Checks。
• 扩容与缩容不平衡：通常扩容要敏捷，缩容要平缓，以确保用户体验优先。
• 故障排查：如果实例启动后立即终止，检查 Grace Period（宽限期）是否过短，或 User Data 脚本是否报错。
• 成本优化：结合 混合实例策略，利用 Spot 实例节省高达 90% 的成本。

第十章：认证考试高频场景实战

Question 1

一家公司正在其 VPC 中构建两层 Web 应用程序。数据层使用 OLTP 数据库，Web 层需要具备弹性和可扩展性。应使用哪些服务构建 Web 层？

1. Elastic Load Balancing, Amazon EC2, and Auto Scaling
2. Elastic Load Balancing, Amazon RDS with Multi-AZ, and Amazon S3
3. Amazon RDS with Multi-AZ and Auto Scaling
4. Amazon EC2, Amazon DynamoDB, and Amazon S3
   正确答案：1。Web 层的扩展与弹性核心组件即为 ELB + ASG + EC2。

Question 2

某 CRM 应用在上午 9 点到下午 5 点被广泛使用，用户抱怨早晨启动时性能慢。哪种策略最有效？

1. 基于 CPU 的动态扩展。
2. 基于内存的动态扩展。
3. 基于已知时间表的计划扩展 (Scheduled Scaling)。
4. 预测性扩展。
   正确答案：3。既然高峰时间完全可预测，使用计划扩展在办公开始前预置容量是操作上最有效的。

AWS Lambda

第一章：核心定义与本质

AWS Lambda 是一种无服务器（Serverless）、事件驱动的计算服务。它让你无需预置或管理服务器即可运行代码，只需为使用的计算时间付费。

• 服务本质：你只需上传代码，Lambda 会自动处理运行代码所需的一切，包括服务器管理、操作系统维护、容量缩放和代码监控。
• 计费模式：按请求次数和执行时长（以毫秒为单位）计费。如果没有代码运行，则无需付费。
• 弹性缩放：Lambda 会根据传入事件的数量自动水平缩放。它可以从零增加到数千个并发实例。
• 无状态性：函数是无状态的，不与任何底层基础设施建立持久连接。

第二章：核心组件与配置

1. 函数 (Function)

• 代码：你上传的用于处理事件的可执行程序。
• 运行时 (Runtime)：Lambda 支持多种语言，包括 Node.js、Python、Java、Go、C#、Ruby，也支持自定义运行时（Custom Runtime）。
• 处理程序 (Handler)：代码中的入口点，Lambda 在开始执行时会调用该方法。

2. 触发器 (Trigger)

• 触发器是集成到 Lambda 函数中的 AWS 服务或资源，用于启动函数执行。例如 S3 对象创建、API Gateway 请求或状态更改。

3. 环境与资源控制

• 内存 (Memory)：可配置范围为 128 MB 到 10,240 MB。CPU 功率与内存大小成正比。
• 超时 (Timeout)：单次执行的最长时间上限为 15 分钟。
• 临时存储 (/tmp)：每个函数提供 512 MB 到 10 GB 的非持久性磁盘空间。
• 环境变量：用于将配置设置传递给函数代码，而无需修改代码本身。

第三章：调用类型 (Invocation Types)

理解调用方式是架构设计的关键考点：

1. 同步调用 (Synchronous)

• 逻辑：客户端等待函数处理完成并返回响应。
• 典型场景：API Gateway、Elastic Load Balancing (ALB)、Cognito。
• 错误处理：由客户端负责重试。

2. 异步调用 (Asynchronous)

• 逻辑：Lambda 将事件放入队列中并立即向客户端返回成功响应，随后在后台处理。
• 典型场景：S3、SNS、CloudWatch Logs。
• 错误处理：Lambda 默认会自动重试两次。
• 目的地 (Destinations)：执行成功或失败后，可以将记录发送到 SQS、SNS、Lambda 或 EventBridge。

3. 事件源映射 (Event Source Mapping)

• 逻辑：Lambda 读取流或队列并调用函数（轮询模式）。
• 典型场景：Kinesis、DynamoDB Streams、SQS。
• 错误处理：通常基于批处理。如果一批数据失败，Lambda 会反复重试直到数据过期。

第四章：并发管理 (Concurrency)

• 预留并发 (Reserved Concurrency)：

• 为特定函数预留一部分账户总并发配额。

• 作用：确保关键函数始终有容量可用，同时可作为“终止开关”限制某个函数的最大并发量，防止过度消耗资源或影响后端数据库。

• 预置并发 (Provisioned Concurrency)：

• 提前初始化一定数量的函数实例，使其处于“热”状态。

• 作用：消除冷启动（Cold Start）延迟，确保函数能够立即响应突发流量。

第五章：网络与安全性

1. VPC 网络

• 默认情况：Lambda 运行在 AWS 管理的安全网络中，可以直接访问互联网和公共 AWS 服务 API。
• 访问私有资源：若需访问 VPC 内的资源（如 RDS、私有子网中的 EC2），必须配置 Lambda 关联特定的 子网 (Subnets) 和 安全组 (Security Groups)。
• 注意：一旦关联 VPC，Lambda 默认失去互联网访问权限。若需上网，必须通过私有子网中的 NAT Gateway。

2. 权限管理 (IAM)

• 执行角色 (Execution Role)：这是一个 IAM 角色，授予函数访问其他 AWS 服务（如写日志到 CloudWatch、读取 S3 桶）的权限。
• 基于资源的策略 (Resource-based Policy)：定义哪些服务或账号有权调用（Invoke）该函数。

第六章：高级特性

• 版本 (Versions)：你可以发布函数的一个或多个版本，每个版本拥有唯一的 ARN 且不可更改。
• 别名 (Aliases)：指向特定版本的指针（如 PROD 指向版本 1）。支持流量切换，例如 10% 流量发往 BETA 别名，实现金丝雀发布。
• 层 (Layers)：将公共库、依赖项或自定义运行时打包在一起。多个函数可以共享同一个层，减少部署包的大小。
• Lambda@Edge：在 CloudFront 边缘节点运行代码，为全球用户提供极低延迟的处理。

第七章：架构师自考与最佳实践

AWS Elastic Load Balancing (ELB)

第一章：ELB 核心概念

Elastic Load Balancing (ELB) 是一种高度可用且可扩展的服务，它能自动将传入的应用程序或网络流量分发到多个目标（如 EC2 实例、容器 ECS、Lambda 函数和 IP 地址）。

1. 核心运行逻辑

• 多可用区部署：创建负载均衡器时，必须从至少两个可用区（AZ）中各指定一个公共子网。这确保了当某个 AZ 发生故障时，流量可以自动导向其他健康的 AZ。
• 健康检查：ELB 持续监控注册目标的健康状况，并仅将请求路由到健康的实例。
• 删除保护：建议开启此功能，防止负载均衡器被意外删除。
• SSL 卸载 (SSL Offloading)：ELB 可以终止来自客户端的 SSL 连接，并以非加密形式将请求发送到后端，从而减轻后端服务器的计算压力。

第二章：三种核心负载均衡器类型对比

1. Application Load Balancer (ALB) —— 应用层 (L7)

ALB 工作在 OSI 模型的第七层，专门处理 HTTP 和 HTTPS 流量。

• 智能路由规则：
  • 基于路径的路由：例如将 /api 发往一组服务器，将 /images 发往另一组。
  • 基于主机名的路由：例如根据域名 example.com 或 test.com 进行分发。
  • 基于查询字符串/HTTP 标头/HTTP 方法的路由。
• 高级功能：
  • 支持重定向：可将 HTTP 请求自动重定向到 HTTPS。
  • 自定义响应：可以直接返回固定的 HTTP 响应（如 404 或 200）。
  • Lambda 集成：可以将 Lambda 函数作为目标组。
  • gRPC 支持：适用于高性能微服务通信。
  • 身份验证：支持 OIDC 兼容的身份提供商和 Amazon Cognito。
  • 双栈支持：支持 IPv4 和 IPv6 目标。

2. Network Load Balancer (NLB) —— 传输层 (L4)

NLB 工作在第四层，专门处理 TCP、UDP 和 TLS 流量，适合对性能要求极高的场景。

• 极致性能：能够处理每秒数百万次的突发请求，延迟极低。
• 静态 IP 地址：每个启用的可用区都会获得一个静态 IP，并且可以关联弹性 IP (EIP)。这是需要防火墙白名单场景的首选。
• 源 IP 保留：对于实例类型目标，NLB 可以直接透传客户端的原始 IP 到后端。
• ALB 作为目标：NLB 可以直接将流量转发到 ALB（仅限 TCP 监听器）。
• QUIC 协议支持：适用于超低延迟的流媒体和通信。

3. Gateway Load Balancer (GWLB) —— 网络层 (L3)

GWLB 用于在 VPC 前端部署、扩展和管理第三方虚拟防火墙、入侵检测系统 (IDS/IPS) 等设备。

• 透明代理：在网络层运行，流量透明地传递给注册的安全设备，不执行 SSL 卸载等操作。
• GWLB 终端节点：通过终端节点创建安全、低延迟的连接。

第三章：关键高级特性深度解析

1. 跨可用区负载均衡 (Cross-Zone Load Balancing)

• 开启后：负载均衡器会将其流量均匀分发到所有已启用的 AZ 中的所有注册目标。
• 默认状态：ALB 默认启用（不收跨区流量费）；NLB 默认禁用。

2. 会话保持 (Sticky Sessions)

• 功能：将同一用户的多次请求始终导向同一个后端目标。
• ALB 实现：通过负载均衡器生成的 Cookie 或应用程序自定义的 Cookie 来实现。

3. 慢启动模式 (Slow Start)

• 功能：给新加入的目标组的实例一段时间进行“预热”，在这段时间内，发送给它的请求量会逐渐增加。

4. 注销延迟 (Deregistration Delay / Connection Draining)

• 功能：当某个实例被注销或健康检查失败时，ELB 会停止发送新请求，但允许现有的在途请求在超时时间内完成处理。

第四章：健康检查状态全解析

目标在负载均衡器中会有以下几种状态：

• Initial：正在注册目标或健康检查正在进行中。
• Healthy：目标健康，可以接收流量。
• Unhealthy：目标未响应健康检查或检查失败。
• Unused：目标未注册到目标组，或者目标组未关联到监听器规则。
• Draining：目标正在注销，正在进行连接排空处理。

第五章：安全与合规

• TLS 1.3 支持：ALB 和 NLB 均支持最新的 TLS 1.3 协议。
• WAF 集成：支持“一键式”关联 AWS WAF 网页应用防火墙（仅 ALB）。
• 身份验证：ALB 支持 JWT (JSON Web Token) 验证和相互 TLS (mTLS) 身份验证。
• 安全组：可以直接将安全组关联到 ALB 和 NLB，以过滤进出负载均衡器的流量。

第六章：架构师对比与决策速查

第七章：监控与日志

• CloudWatch 指标：实时获取请求计数、延迟、错误率等数据。
• 访问日志 (Access Logs)：详细记录发往负载均衡器的每一个请求，存储在 S3 桶中。
• VPC Flow Logs：监控进入 NLB 的网络流数据。
• CloudTrail：审计所有对 ELB API 的调用。

第八章：计费逻辑

• ALB/NLB：按小时计费，并按使用的 LCU（负载均衡器容量单位）计费。
• GWLB：按小时计费，并按使用的 GLCU 计费。
• CLB：按小时计费，并按数据传输量（GB）计费。

Amazon DynamoDB

第一章：核心定义与本质

Amazon DynamoDB 是一种完全托管的 NoSQL 数据库服务，提供快速、可预测的性能和无缝的扩展性。

• 无服务器 (Serverless)： 你无需管理服务器、安装补丁或维护底层基础设施。
• 高可用性： 数据自动在区域内的多个可用区（AZ）之间进行同步复制。
• 性能： 无论数据规模如何，都能提供稳定、个位数毫秒级的响应延迟。
• 安全性： 提供默认的静态加密（Encryption at Rest），并与 IAM 集成进行细粒度的访问控制。

第二章：数据模型与核心组件

1. 基础结构

• 表 (Tables)： 数据的集合。DynamoDB 的表是无模式（Schema-less）的，除了主键外，不需要预先定义属性。
• 项目 (Items)： 表中的单条记录（类似于行）。每个项目的大小上限为 400 KB。
• 属性 (Attributes)： 项目中的基本数据元素（类似于列）。支持标量、集合及嵌套的文档类型（List 和 Map），嵌套深度可达 32 层。

2. 主键 (Primary Key)

主键必须在创建表时定义，且必须是标量类型（String, Number, Binary）。

• 分区键 (Partition Key/Hash Key)： 决定数据存储在哪个物理分区。
• 排序键 (Sort Key/Range Key)： 可选。与分区键结合形成“复合主键”，允许在相同分区键下进行范围查询和排序。

第三章：二级索引 (Secondary Indexes)

当主键无法满足查询需求时，使用二级索引来提供查询灵活性。

第四章：读一致性与容量单位

1. 读一致性模型

• 最终一致性 (Eventually Consistent)： 默认模式，性能最高。响应可能包含过时数据，但通常在 1 秒内达到一致。
• 强一致性 (Strongly Consistent)： 返回最准确的数据。但在网络延迟或故障时可用性略低，且不支持跨区域读取。

2. 吞吐量单位计算

• 写入 (WCU)： 1 个 WCU = 每秒 1 次写入（项大小不超过 1 KB）。
• 读取 (RCU)： 1 个 RCU = 每秒 1 次强一致性读取，或每秒 2 次最终一致性读取（项大小不超过 4 KB）。

第五章：容量管理模式

• 预置模式 (Provisioned)： 你指定固定的 RCU 和 WCU。适合流量平稳、可预测的场景。

• Auto Scaling： 开启后，DynamoDB 会根据实际流量自动调整预置的容量，防止因请求超限导致的 Throttling（节流）。

• 按需模式 (On-Demand)： 按请求付费，无需容量规划。适合流量不可预测或有突发尖峰的负载。

第六章：查询操作 (Query vs Scan)

• Query (查询)： 基于主键值定位。必须指定分区键的等值条件。性能极高且消耗吞吐量低。

• Scan (扫描)： 读取表或索引中的所有项目，然后进行过滤。

• 注意： 对于大表，Scan 非常慢且非常昂贵，因为它会消耗大量的 RCU。

• 优化： 尽可能使用 Query；如必须 Scan，可尝试“并行扫描 (Parallel Scan)”。

• 数据限制： 单次 Query 或 Scan 操作返回的数据上限为 1 MB。

第七章：高级特性与集成

1. DynamoDB Streams

捕获表的增删改操作。

• 记录保留 24 小时。
• 常用于触发 AWS Lambda，实现数据同步、实时分析或跨区域复制。

2. DAX (DynamoDB Accelerator)

专为 DynamoDB 设计的内存中缓存集群。

• 提供微秒级的响应速度。
• 主要针对频繁读取、重复读取的场景，但不适合需要强一致性读的应用。

3. 全球表 (Global Tables)

提供全托管、多区域、多活跃（Multi-active）的复制方案。

• 允许在多个 AWS 区域提供极低延迟的读写。
• 依赖 DynamoDB Streams 实现。

4. 其他核心特性

• TTL (生存时间)： 自动删除过期项目。系统自动执行，不消耗吞吐量。
• Transactions (事务)： 提供原子性、一致性、隔离性和持久性（ACID）。单次事务最多处理 25 个项目（4 MB）。

第八章：架构设计最佳实践 (解决热点问题)

1. 热点分区 (Hot Partitions)

• 原因： 如果大量请求集中在同一个分区键（例如热门产品 ID），会导致该物理分区达到 RCU/WCU 上限，产生节流错误。
• 对策：
• 高基数键： 选择具有大量唯一值的分区键（如 UserID 而非 Gender）。
• 写入分片 (Write Sharding)： 在分区键末尾添加随机后缀，将压力分散到多个分区。
• 利用缓存： 使用 DAX 处理读取热点。

2. 节流处理 (Throttling)

• 当请求被节流时，客户端会收到 HTTP 400 (ProvisionedThroughputExceededException) 错误。
• 解决方案： 增加预置容量、开启 Auto Scaling 或切换到按需模式。

第九章：架构师对比 (什么时候选 DynamoDB？)

Amazon EFS (弹性文件系统)

第一章：核心定义与核心价值

Amazon EFS 是一种完全托管、无服务器（Serverless）、弹性且“设定后即忘”的网络文件存储服务。

• 服务本质： 它使在 AWS 云中设置和扩展文件存储变得简单，自动管理所有底层基础设施，避免了部署、补丁和维护的复杂性。
• 协议支持： 支持网络文件系统第 4 版（NFSv4.1 和 NFSv4.0）协议。
• 平台兼容性： 可以挂载到运行 Linux 或 MacOS（Big Sur 及更新版本）的 EC2 实例上。注意：不支持 Windows。
• 多资源共享： 除了 EC2，还支持挂载到 ECS 任务、EKS Pod 和 Lambda 函数。
• 并发访问： 成千上万个 EC2 实例可以同时访问同一个 EFS 文件系统，为多实例运行的工作负载提供通用数据源。

第二章：存储类与生命周期管理

EFS 提供多种存储类，以根据访问频率优化成本。

1. 存储类划分

• Amazon EFS Standard： 用于跨多个可用区（AZ）存储频繁访问的文件。
• Amazon EFS Infrequent Access (EFS IA)： 为访问频率较低的文件提供成本优化。
• Amazon EFS Archive： 针对每年访问几次或更少的长生命周期数据进行优化，成本比 IA 低高达 50%。
• Amazon EFS One Zone： 将频繁访问的数据存储在单个 AZ 中，成本更低，但可用性也较低。
• Amazon EFS One Zone-IA： 在单个 AZ 中存储低频访问的数据。

2. 生命周期管理 (Lifecycle Management)

• 自动迁移： EFS 会自动将设定周期内（如 7、14、30、60 或 90 天）未被访问的文件从 Standard 迁移到 IA，或从 IA 迁移到 Archive。

第三章：性能与吞吐量模式

1. 性能模式 (Performance Modes)

• 通用模式 (General Purpose - 默认)： 理想的延迟敏感型用例选择。
• 最大 I/O 模式 (Max I/O)： 可以扩展到更高水平的总吞吐量和每秒操作数，但文件操作延迟略高。适用于大数据分析、媒体处理和基因分析。

2. 吞吐量模式 (Throughput Modes)

• 弹性模式 (Elastic - 推荐)： 吞吐量随工作负载活动自动扩展，只需为使用的量付费，无需提前配置。适合波峰明显或不可预测的工作负载。
• 预置模式 (Provisioned)： 允许你指定文件系统的吞吐量，与其存储的数据量无关。
• 突发模式 (Bursting)： 吞吐量随文件系统大小而增长。

第四章：架构组件与连接性

• 挂载目标 (Mount Targets)： 要在 VPC 中访问 EFS，需在每个可用区创建一个挂载目标，它为 NFSv4 终端节点提供 IP 地址。
• DNS 挂载： 使用 DNS 名称挂载文件系统，它会自动解析为对应挂载目标的 IP 地址。
• 访问点 (Access Points)： 简化应用程序对共享数据集的访问。它们与 IAM 配合工作，可以为通过访问点发出的每个请求强制执行特定的操作系统用户、组和目录。
• 混合云访问： 本地服务器（必须是 Linux）可以通过 AWS Direct Connect 或 VPN 连接到 VPC 来挂载 EFS。

第五章：安全性与监控

• 访问控制： 必须拥有有效凭证和相应权限才能创建或访问资源。

• 安全组： 必须为 EC2 实例和 EFS 挂载目标指定相应的安全组。

• 权限管理： 默认仅根用户（UID 0）拥有读写执行权限。可利用 IAM 策略和角色管理特定客户端的 NFS 访问权限。

• 加密： 支持静态加密（At Rest）和传输中加密（In Transit）。

• 数据保护： * 通过控制台创建的文件系统默认开启 AWS Backup 每日自动备份（保留 35 天）。

• AWS DataSync 可用于在不同区域或账号的 EFS 之间安全复制文件。

• 监控： 利用 CloudWatch 指标（如 PercentIOLimit）监控 IOPS 利用率。

第六章：计费与计量细节

• 按需计费： 你只需为文件系统使用的存储量付费。

• 计量规则：

• 普通文件： 逻辑大小向上舍入到下一个 4-KiB 增量进行计量。

• 稀疏文件 (Sparse Files)： 如果实际存储使用量小于逻辑大小，EFS 按实际使用的存储报告计量大小。

• 目录与链接： 目录按实际存储使用的结构大小计算；符号链接和特殊文件固定计量为 4 KiB。

• 注意： 删除文件系统是破坏性操作且不可撤销，建议在删除前先卸载。

第七章：架构师对比表 (EFS vs EBS vs S3)