AWS 专题学习 P2 (EIP、EBS、EFS、ELB、SSL、ASG)

1. EC2 – Associate

1.1 私有 vs 公网 IP (IPv4)

网络 IP 有两种： IPv4 和 IPv6。 在本课程中，我们将只使用IPv4。 IPv4：[0-255].[0-255].[0-255].[0-255]。
参考： https://blog.csdn.net/ithomer/article/details/51247567

公网 IP：

• 公共 IP 表示机器可以在互联网上被识别 (万维网)
• 在整个网络中必须是唯一的（两台机器不能有相同的公共IP）
• 可以轻松定位

私有 IP：

• 私有 IP 表示机器只能在私有网络上被识别
• IP 在整个专用网络中必须是唯一的
• 但是两个不同的局域网可以有相同的 IP
• 机器使用 NAT + 互联网网关（代理）连接到万维网
• 只能指定范围内的 IP 作为私网 IP

1.2 Elastic IPs （弹性 IP）

当停止后重启 EC2 实例时，可以更改实例公共 IP。如果实例需要有一个固定的公共 IP，则需要一个弹性 IP。弹性 IP 是您拥有的公共 IPv4 IP。一个实例对应一个 IP。
使用弹性 IP 地址，您可以通过将地址快速重新映射到您账户中的另一个实例来掩盖实例或软件的故障。

• 一个账户中默认最多只能有 5 个弹性 IP（可以要求 AWS 增加）。
• 尽量避免使用弹性 IP：
  • 这通常反映了不佳的架构决策
  • 推荐使用随机公共 IP 并向其注册 DNS 名称
  • 或者使用负载均衡器代替公共 IP

1.3 Placement Groups（置放群组）

在启动新的 EC2 实例时，您可以使用置放群组决定如何放置一组相互依赖的实例，从以便将所有实例分布在基础硬件上以最大限度减少相关故障。根据工作负载类型，您可以使用以下置放策略之一创建置放群组：

• 集群 – 将一个可用区中靠近的实例打包在一起。通过使用该策略，工作负载可以实现所需的低延迟网络性能，以满足高性能计算（HPC）应用程序通常使用的紧密耦合的节点到节点通信的要求。
• 分区 – 将实例分布在不同的逻辑分区上，以便一个分区中的实例组不会与不同分区中的实例组使用相同的基础硬件。该策略通常为大型分布式和重复的工作负载所使用，例如，Hadoop、Cassandra 和 Kafka。
• 分布（Spread） – 将一小组实例严格放置在不同的基础硬件上以减少相关的故障。

创建置放群组无需支付费用。

集群策略

• 优点：出色的网络（启用增强联网的实例之间的带宽为 10 Gbps - 推荐）
• 缺点：如果机架发生故障，所有实例将同时发生故障
• 使用场景：
  • 需要快速完成的大数据作业
  • 需要极低延迟和高网络吞吐量的应用程序

分布策略

• 优点：可以跨越可用区 (AZ)，降低同时发生故障的风险，EC2 实例位于不同的物理硬件上
• 缺点：每个置放群组每个 AZ 限制为 7 个实例
• 使用场景：
  • 需要最大化高可用性的应用程序
  • 关键应用的每个实例必须相互隔离故障

分区策略

• 每个 AZ 最多 7 个分区，可以跨越同一 region 的多个可用区，同时多达 100 个 EC2 实例
• 一个分区中的实例不与其他分区中的实例共享机架
• 分区故障会同时影响许多 EC2 实例，但不会影响其他分区
• EC2 实例可以访问分区信息作为元数据
• 用例：HDFS、HBase、Cassandra、Kafka

1.4 Elastic Network Interfaces (ENI - 弹性网络接口)

• VPC 中代表虚拟网卡的逻辑组件
• ENI 可以具有以下属性：
  • 主要私有 IPv4，一个或多个辅助 IPv4
  • 每个私有 IPv4 对应的一个弹性 IP
  • 一个公共 IPv4
  • 一个或多个安全组
  • MAC 地址
• 可以独立创建 ENI 并将它们动态附加（移动）到 EC2 实例上以进行故障转移
• 需要绑定到特定可用区 (AZ)

1.5 EC2 Hibernate（休眠）

Introduce

• 实例的停止、终止
  • 停止——磁盘上的数据（EBS）在下次启动时保持不变
  • 终止——所有设置为销毁的 EBS 卷（根）都将丢失
• 实例启动时，会发生以下情况：
  • 首次启动：操作系统启动并运行 EC2 用户数据脚本
  • 后续启动：操作系统启动
  • 然后您的应用程序启动，缓存预热

与 启动/终止 操作不同，EC2 实例的休眠有以下特性：

• 保留内存 (RAM) 状态
• 实例启动速度更快（操作系统未停止/重新启动）
• 在幕后：RAM 状态被写入根 EBS 卷中的文件
• 根 EBS 卷必须加密
• 使用场景：
  • 长时间运行的任务
  • 需要保存RAM状态
  • 需要时间来初始化的服务

Good to Know

• 支持的实例系列——C3、C4、C5、I3、M3、M4、R3、R4、T2、T3……
• 实例 RAM 大小– 必须小于150 GB。
• 实例大小——裸机实例不支持。
• AMI – Amazon Linux 2、Linux AMI、Ubuntu、RHEL、CentOS 和 Windows…
• 根卷 – 必须是 EBS，加密的，不是实例存储，并且很大
• 适用于按需实例、预留实例和 Spot 实例
• 实例休眠时间不得超过 60 天

2. EC2 实例存储

2.1 EBS 卷 (Elastic Block Store - 弹性块存储)

• EBS 卷是一个网络驱动器，可以在实例运行时附加到实例上
• 它允许您的实例持久保存数据，即便实例终止
• 一个 EBS 卷一次只能安装到一个实例（在 CCP 级别）
• 被锁定到特定的 AZ，EBS 卷不能跨 AZ 附加到其他 AZ 的实例
• 跨卷移动需要先为其创建快照
• 免费套餐：每月 30 GB 通用型 (SSD) 或磁性类型的免费 EBS 存储空间

2.2 EBS – “Delete on Termination” 属性

• 控制 EC2 实例终止时的行为
  • 默认情况下，删除根 EBS 卷（启用属性）
  • 默认情况下，不会删除任何其他附加的 EBS 卷（禁用属性）
• 可以通过 AWS 控制台/AWS CLI 控制
• 使用场景：实例终止时保留根卷

2.3 EBS Snapshots 快照

• 在某个时间点对指定 EBS 卷进行备份（快照）
• 不需要分离卷来做快照，但推荐
• 可以跨 AZ 或 Region 复制快照

Features

• 快照存档
  • 将快照移动到便宜 75% 的“归档层”
  • 恢复存档需要 24 到 72 小时
• 快照回收站
  • 设置规则以保留已删除的快照，以便您可以在意外删除后恢复它们
  • 指定保留期（从 1 天到 1 年）
• 快速快照还原 (FSR)
  • 快照的强制全量初始化在第一次使用时没有延迟（$$$）

2.4 AMI

概述

• AMI —— Amazon Machine Image，是 EC2 的自定义实例
  • 您添加自己的软件、配置、操作系统、监控…
  • 更快的启动/配置时间，因为您的所有软件都是预先打包的
• AMI 是为特定区域构建的（并且可以跨区域复制）
• 可以从以下位置启动 EC2 实例：
  • 公共 AMI：AWS 提供
  • 用户自己的 AMI：自行制作和维护它们
  • AWS Marketplace AMI：其他人制作（并可能出售）的 AMI

AMI Process（from EC2 实例）

• 启动 EC2 实例并对其进行自定义
• 停止实例（为了数据完整性）
• 构建一个 AMI——这也将创建 EBS 快照
• 从其他 AMI 启动实例

2.5 EC2 Instance Store：高性能硬盘

• 更好的 I/O 性能
• EC2 实例存储在停止时会丢失存储空间（临时）
• 适用于缓冲区/缓存/暂存数据/临时内容
• 如果硬件出现故障，数据丢失的风险
• 需要自行设置备份和复制

2.6 EBS 卷类型 & 使用场景

• EBS 卷有 6 种类型
  • gp2 / gp3 (SSD)：通用 SSD 卷，可平衡各种工作负载的价格和性能
  • io1 / io2 (SSD)：用于关键任务低延迟或高吞吐量工作负载的最高性能 SSD 卷
  • st1 (HDD)：专为频繁访问、吞吐量密集型工作负载设计的低成本 HDD 卷
  • sc1 (HDD)：成本最低的 HDD 卷，专为访问频率较低的工作负载而设计
• EBS 卷的特点是大小 | 吞吐量 | IOPS（每秒 I/O 操作数）
• 只有 gp2/gp3 和 io1/io2 可以用作引导卷

通用 SSD

• 具有成本效益的存储、低延迟
• 系统引导卷、虚拟桌面、开发和测试环境
• 1 GiB - 16 TiB
• GP3：
  • 3,000 IOPS 的基准和 125 MiB/s 的吞吐量
  • 可以独立地将 IOPS 提高到 16,000，将吞吐量提高到 1000 MiB/s
• GP2：
  • 小型 gp2 卷可以将 IOPS 突增至 3,000
  • 卷的大小和 IOPS 相关联，最大 IOPS 为 16,000
  • 每 GB 3 IOPS，表示在 5,334 GB 时我们处于最大 IOPS

预置 Provisioned IOPS (PIOPS) SSD

• 要求持续 IOPS 性能的关键业务应用程序
• 或需要超过 16,000 IOPS 的应用程序
• 非常适合数据库工作负载（对存储性能和一致性敏感）
• io1/io2 (4 GiB - 16 TiB)：
  • 最大 PIOPS：Nitro EC2 实例为 64,000，其他实例为 32,000
  • 可以独立于存储大小增加 PIOPS
  • io2 具有更高的耐用性和更高的每 GiB IOPS（与 io1 的价格相同）
• io2 Block Express (4 GiB – 64 TiB)：
  • 亚毫秒延迟
  • 最大 PIOPS：256,000，IOPS:GiB 比率为 1,000:1
• 支持 EBS 多重连接

硬盘驱动器 (HDD)

• 不能作为引导卷
• 125 GiB 到 16TiB
• 吞吐量优化硬盘 (Throughput Optimized HDD：st1)
  • 大数据、数据仓库、日志处理
  • 最大吞吐量 500 MiB/s – 最大 IOPS 500
• 冷硬盘 (Cold HDD：sc1)：
  • 对于不经常访问的数据
  • 最低成本很重要的场景
  • 最大吞吐量 250 MiB/s – 最大 IOPS 250

2.7 EBS 多重挂载 – io1/io2 系列

• 将同一个 EBS 卷附加到同一个 AZ 中的多个 EC2 实例
• 每个实例对高性能卷具有完整的读写权限
• 使用案例：
  • 在集群 Linux 应用程序中实现更高的应用程序可用性（例如：Teradata）
  • 应用程序必须管理并发写入操作
• 一次最多 16 个 EC2 实例
• 必须使用集群感知的文件系统（不是 XFS、EX4 等…）

2.8 EBS Encryption 加密

• 当创建加密的 EBS 卷时，会得到以下信息：
  • 卷内的静态数据会被加密
  • 在实例和卷之间移动的所有传输中的数据都会被加密
  • 所有快照都会被加密
  • 所有从快照创建的卷也会被加密
• 加密和解密是透明处理的
• 加密导致的延迟非常小
• EBS 加密利用来自 KMS (AES-256) 的密钥
• 复制未加密的快照允许加密
• 加密卷的快照被加密

Encryption：加密 EBS 卷

• 创建卷的 EBS 快照
• 加密 EBS 快照（使用副本）
• 从快照创建新的 EBS 卷（该卷也将被加密）
• 可以将加密卷附加到原始实例

2.9 Amazon EFS – 弹性文件系统

概述

• 托管的 NFS（网络文件系统），可以安装在许多 EC2 上
• EFS 与多可用区中的 EC2 实例一起工作
• 高度可用、可扩展、昂贵(3x gp2)、按使用付费。

• 用例：内容管理、网络服务、数据共享、Wordpress
• 使用 NFS v4.1 协议
• 使用安全组控制对 EFS 的访问
• 兼容基于 Linux 的 AMI（非 Windows）
• 使用 KMS 进行静态加密
• 具有标准文件 API 的 POSIX 文件系统 (~Linux)
• 文件系统自动扩展，按使用付费，无容量规划

EFS – 性能和存储类别

• EFS 规模
  • 1000 个并发 NFS 客户端，10 GB+/s 吞吐量
  • 自动增长到 PB 级网络文件系统
• 性能模式（在 EFS 创建时设置）
  • 通用（默认） – 对延迟敏感的用例（网络服务器、CMS 等）
  • 最大 I/O – 更高的延迟、吞吐量、高度并行（大数据、媒体处理）
• 吞吐量模式
  • 突发 – 1TB = 50MiB/s + 高达 100MiB/s 的突发
  • 预配置 – 设置吞吐量而不考虑存储大小，例如：1 TB 存储 + 1 GiB/s
  • 弹性 – 根据工作负载自动增加或减少吞吐量
    • 读取速度高达 3GiB/s，写入速度高达 1GiB/s
    • 用于不可预测的工作负载

EFS 一 存储类别

• 存储层级（生命周期管理功能 – N 天后移动文件）
  • 标准：用于经常访问的文件
  • 低频访问（EFS-IA）：检索文件成本低，存储成本低。 需要使用生命周期策略启用（IA：Infrequent Access）
• 可用性和耐久性
  • 标准：多可用区，适合生产
  • One Zone-IA：单可用区，适合开发，默认启用备份，兼容 IA
• 节省超过 90% 的成本

EBS vs EFS – 弹性块存储

• EBS 卷
  • 一个实例（多连接的 io1/io2 除外）
  • 锁定在可用区 (AZ) 级别
  • gp2：如果磁盘大小增加，IO 也会增加
  • io1：可以独立增加 IO
• 跨可用区迁移 EBS 卷
  • 生成快照
  • 将快照恢复到另一个可用区
  • EBS 备份需要使用 IO，不应在应用程序处理大量流量时运行备份
• 如果EC2 实例终止，实例的根EBS 卷默认终止。 （可以禁用此功能）

总结

• 跨可用区安装数百个实例
• EFS 共享网站文件 (WordPress)
• 仅适用于 Linux 实例 (POSIX)
• EFS 的价格高于 EBS
• 可以利用 EFS-IA 来节省成本
• Remember：EFS vs EBS vs实例存储

3. 可扩展性和高可用性

• 可扩展性意味着应用程序/系统可以通过适应来处理更大的负载。
• 有两种可扩展性：
  • 纵向可扩展性
  • 横向可扩展性（= 弹性）
• 可扩展性与高可用性相关但不同，高可用性通常与水平扩展密切相关

3.1 EC2 的高可用性和可扩展性

• 垂直扩展：增加实例大小（= 放大/缩小）—— RDS、ElastiCache
  • From：t2.nano (0.5G RAM，1 vCPU)
  • To：u-12tb1.metal (12.3 TB RAM，448 vCPUs)
• 水平扩展：增加实例数量（= 向外扩展/向内扩展）—— 分布式系统
  • Auto Scaling 组
  • 负载平衡器
• 高可用性：跨多个可用区为同一应用程序运行实例 —— 多可用区（多数据中心）
  • Auto Scaling 组多可用区
  • 负载均衡器多可用区

3.2 负载均衡

负载平衡是将流量转发到多个下游服务器（例如 EC2 实例）的服务器

为什么要使用负载均衡器

• 将负载分散到多个下游实例
• 为应用程序提供单一访问点 (DNS)
• 无缝处理下游实例故障
• 对实例定期健康检查
• 为网站提供 SSL 终端 (HTTPS)
• 使用 cookie 增强粘性
• 跨区域的高可用性
• 将公共流量与私有流量分开

为什么要使用弹性负载均衡器

• 弹性负载均衡器是托管负载均衡器
  • AWS 保证它会正常工作
  • AWS 负责升级、维护、高可用性
  • AWS 仅提供几个配置旋钮
• 设置您自己的负载平衡器成本较低，但您需要付出更多努力
• 它能与许多 AWS 产品/服务集成
  • EC2、EC2 Auto Scaling 组、Amazon ECS
  • AWS 证书管理器 (ACM)、CloudWatch
  • Route 53、AWS WAF、AWS Global Accelerator

健康检查

• 健康检查对负载均衡器至关重要，能够知道负载平衡器转发的实例是否可用
• 健康检查在端口和路由上完成（通常是 /health）
• 如果响应不是 200 (OK)，则实例运行状况不佳

负载均衡器类型

• Classic Load Balancer（v1 - 老一代） – 2009 – CLB
  • HTTP、HTTPS、TCP、SSL（安全 TCP）
• 应用程序负载均衡器（v2 - 新一代） – 2016 – ALB
  • HTTP、HTTPS、WebSocket
• 网络负载均衡器（v2 - 新一代）– 2017 – NLB
  • TCP、TLS(secureTCP)、UDP
• 网关负载平衡器 – 2020 – GWLB
  • 在第 3 层（网络层）运行 – IP 协议

总体而言，建议使用新一代负载平衡器，因为它们提供更多功能
一些负载均衡器可以设置为内部（私有）或外部（公共）ELB

负载均衡器安全组

经典负载均衡器 (v1) — Classic Load Balancer

• 支持 TCP（第 4 层）、HTTP 和 HTTPS（第 7 层）
• 健康检查基于 TCP 或 HTTP
• 固定主机名 XXX.region.elb.amazonaws.com

应用程序负载均衡器 (v2) — Application Load Balancer

概述

• 应用程序负载平衡器是第 7 层 (HTTP)

• 跨机器（目标组）对多个 HTTP 应用程序进行负载均衡

• 负载均衡到同一台机器上的多个应用程序（例如：容器）

• 支持 HTTP/2 和 WebSocket

• 支持重定向（例如从 HTTP 到 HTTPS）

• 到不同目标组的路由表：

  • 基于 URL 中路径的路由 (example.com/users & example.com/posts)
  • 基于 URL 中主机名的路由（one.example.com 和 other.example.com）
  • 基于查询字符串、标头的路由 (example.com/users?id=123&order=false)

• ALB 非常适合微服务和基于容器的应用程序（例如：Docker 和 Amazon ECS）

• 具有端口映射功能，可重定向到 ECS 中的动态端口

• 相比之下，每个应用程序需要多个 Classic Load Balancer

HTTP Based Traffic（基于 HTTP 的流量）

Target Groups

• EC2 实例（可由 Auto Scaling Group 管理）- HTTP
• ECS 任务（由 ECS 本身管理）- HTTP
• Lambda 函数——HTTP 请求被转换为 JSON 事件
• IP 地址 – 必须是私有 IP
• ALB 可以路由到多个目标组
• 健康检查在目标群体层面进行

Query Strings / Parameters Routing

Good To Know

• 固定主机名 (XXX.region.elb.amazonaws.com)
• 应用服务器不直接看到客户端的 IP
  • 客户端的真实 IP 插入到标题 X-Forwarded-For 中
  • 可以获取端口（X-Forwarded-Port）和原型（X-Forwarded-Proto）

网络负载均衡器 (v2) — Network Load Balancer

概述

• 网络负载平衡器（第 4 层）允许：
• 将 TCP 和 UDP 流量转发到您的实例
• 每秒处理数百万个请求
• 延迟更短，约为 100 毫秒（对比 ALB 为 400 毫秒）
• NLB 每个 AZ 有一个静态 IP，并支持分配弹性 IP（有助于将特定 IP 列入白名单）
• NLB 用于极端性能、TCP 或 UDP 流量
• 不包含在 AWS 免费套餐中

TCP Based Traffic（第 4 层）

Target Groups

• EC2 实例
• IP 地址 – 必须是私有 IP
• 应用程序负载均衡器
• 健康检查支持 TCP、HTTP 和 HTTPS 协议

网关负载均衡器 — Gateway Load Balancer

概述

• 在 AWS 中部署、扩展和管理一组第 3 方网络虚拟设备
• 示例：防火墙、入侵检测和预防系统、深度数据包检测系统、有效载荷操纵……
• 在第 3 层（网络层）运行 – IP 数据包
• 结合了以下功能：
• 透明网络网关——所有流量的单一入口/出口
• 负载平衡器——将流量分配给您的虚拟设备
• 在端口 6081 上使用 GENEVE 协议

Target Groups

• EC2 实例
• IP 地址 – 必须是私有 IP

Sticky Session（Session Affinity）

概述

• 可以实现粘性，使同一个客户端始终被重定向到负载均衡器后面的同一个实例
• 这适用于 Classic Load Balancer 和 Application Load Balancer
• 用于粘性的“cookie”有一个您可以控制的有效期
• 用例：确保用户不会丢失他的会话数据
• 启用粘性可能会导致后端 EC2 实例的负载不平衡

Cookie Names

• 基于应用程序的 Cookie
  • 自定义 cookie
    • 由目标生成
    • 可以包含应用程序所需的任何自定义属性
    • 必须为每个目标组单独指定 Cookie 名称
    • 不要使用 AWSALB、AWSALBAPP 或 AWSALBTG（保留供 ELB 使用）
  • 应用程序 cookie
    • 由负载平衡器生成
    • Cookie 名称是 AWSALBAPP
• 基于持续时间的 Cookie
  • 负载平衡器生成的 Cookie
  • Cookie 名称对于 ALB 是 AWSALB，对于 CLB 是 AWSELB

Cross-Zone Load Balancing

使用跨区域负载均衡： 没有跨区域负载均衡：
每个负载均衡器实例均匀分布在所有 AZ 中的所有注册实例中 请求分布在弹性负载均衡器节点的实例中

• 应用程序负载均衡器
  • 默认启用（可在目标组级别禁用）
  • 可用区间数据免费
• 网络负载均衡器和网关负载均衡器
  • 默认禁用
  • 如果启用，您需要为可用区间数据支付费用（$）
• 经典负载均衡器
  • 默认禁用
  • 如果启用，可用区间数据不收费

3.3 SSL/TLS

基础知识

• SSL 证书允许您的客户端和负载均衡器之间的流量在传输过程中加密（传输中加密）
• SSL 是指安全套接字层，用于加密连接
• TLS 是指传输层安全协议，是较新的版本
• 现在主要使用TLS证书，但人们仍称其为SSL
• 公共 SSL 证书由证书颁发机构 (CA) 颁发
• Comodo、Symantec、GoDaddy、GlobalSign、Digicert、Letsencrypt 等…
• SSL 证书有到期日期（您设置）并且必须更新

负载均衡器 — SSL 证书

• 负载平衡器使用 X.509 证书（SSL/TLS 服务器证书）
• 可以使用 ACM (AWS Certificate Manager) 管理证书
• 可以选择上传自己的证书
• HTTPS Listener:
  • 必须指定默认证书
  • 可以添加可选的证书列表以支持多个域
  • 客户端可以使用 SNI 来指定他们到达的主机名
  • 能够指定安全策略以支持旧版本的 SSL/TLS（旧版客户端）

SSL — Server Name Indication（SNI）

• SNI 解决了将多个 SSL 证书加载到一个 Web 服务器上的问题（以服务于多个网站）
• 这是一个“较新”的协议，要求客户端在初始 SSL 握手中指明目标服务器的主机名
• 然后服务器会找到正确的证书，或者返回默认证书

注意：

• 仅适用于 ALB 和 NLB（新一代）、CloudFront
• 不适用于 CLB（上一代）

弹性负载均衡器 — SSL 证书

• 经典负载均衡器 (v1)
  • 仅支持一个 SSL 证书
  • 必须对具有多个 SSL 证书的多个主机名使用多个 CLB
• 应用程序负载均衡器 (v2)
  • 支持具有多个 SSL 证书的多个 Listener
  • 使用服务器名称指示 (SNI) 使其工作
• 网络负载平衡器 (v2)
  • 支持具有多个 SSL 证书的多个 Listener
  • 使用服务器名称指示 (SNI) 使其工作

Connection Draining （连接耗尽 属性）

• 特征命名
  • 连接排空——用于 CLB
  • 注销延迟——适用于 ALB 和 NLB
• 定义: 在实例取消注册或不健康时完成“运行中请求”的时间
• 停止向正在注销的 EC2 实例发送新请求
• 介于 1 到 3600 秒之间（默认值：300 秒）
• 可以禁用（将值设置为 0）
• 如果请求的耗时较短，最好设置为较低的值

3.4 Auto Scaling Group

什么是 Auto Scaling Group

• 在现实生活中，网站和应用程序的负载可能会发生变化
• 在云中，您可以非常快速地创建和删除服务器
• Auto Scaling Group (ASG) 的目标是：
  • 横向扩展（添加 EC2 实例）以匹配增加的负载
  • 缩减（删除 EC2 实例）以匹配减少的负载
  • 确保我们有最小和最大数量的 EC2 实例在运行
  • 自动将新实例注册到负载平衡器
  • 重新创建一个 EC2 实例以防前一个实例（意外）终止
• ASG 是免费的（只需为底层的 EC2 实例付费）

AWS 中的 Auto Scaling Group

在使用负载均衡器的 AWS 中的 Auto Scaling Group

Auto Scaling Group 的属性

• Launch Template（旧的“Launch Configurations”已弃用）
  • AMI + 实例类型
  • EC2 用户数据
  • EBS 卷
  • 安全组
  • SSH 密钥对
  • EC2 实例的 IAM 角色
  • 网络 + 子网信息
  • 负载平衡器信息
• 最小/最大/初始容量
• 扩展策略

Auto Scaling - CloudWatch Alarms & Scaling

• 可以根据 CloudWatch 警报扩展 ASG
• 警报监控指标（例如平均 CPU 或自定义指标）
• 为整个 ASG 实例计算平均 CPU 等指标
• 基于警报：
  • 可以创建横向扩展策略（增加实例数量）
  • 可以创建缩减策略（减少实例数量）

ASG – Dynamic Scaling Policies

• 目标跟踪缩放
  • 最简单易设置
  • 举例：我希望平均 ASG CPU 保持在 40% 左右
• 简单/步进缩放
  • 当触发 CloudWatch 警报时（例如 CPU > 70%），则添加 2 个单元
  • 当触发 CloudWatch 警报时（例如 CPU < 30%），然后删除 1
• 预定操作
  • 预期基于已知使用模式的扩展
  • 示例：在周五下午 5 点将最小容量增加到 10

ASG – Predictive Scaling

• 预测性扩展：持续预测负载并提前安排扩展

可扩展的良好指标

• CPUUtilization：实例的平均 CPU 使用率
• RequestCountPerTarget：确保每个 EC2 实例的请求数量稳定
• Average Network I/O（如果应用程序受网络限制）
• Any custom metric（使用 CloudWatch 所推送的）

ASG - Scaling CoolDowns

• 缩放活动发生后，您处于冷却时间（默认 300 秒）
• 在冷却期间，ASG 不会启动或终止额外的实例（以允许指标稳定）
• 建议：使用现成的 AMI 来减少配置时间，以便更快地处理请求并缩短冷却时间
•