1. AWS 基础
1.1 使用场景
获取 access_key_id
- 登录 AWS 管理控制台
- 点击右上角的账户名称,选择 “Security credentials” (安全凭证)
- 在安全凭证页面,找到 “Access keys” (访问密钥) 部分
- 点击 “Create New Access Key” (创建新的访问密钥)
常用命令
1 | # 查看数据库 |
1.2 Region 和 VPC
Region - “物理城市”
Region 是 AWS 在全球范围内的物理地理位置。你可以把它想象成你的公司决定要进入的城市。
- 一个 Region 就是一个独立的地理区域,比如美国东部(弗吉尼亚北部)、欧洲(法兰克福)、亚太地区(东京)等。
- 每个 Region 都是由多个隔离的、物理上独立的可用区 (Availability Zone, AZ) 组成的。一个可用区可以看作是城市里的一个独立的、拥有自己供电和网络系统的数据中心园区。
为什么需要选择 Region?
- 降低延迟 (Latency):选择离你的最终用户最近的 Region,可以让他们访问你的应用或服务时速度更快。就像把分公司开在客户集中的城市一样。
- 数据主权和合规性 (Data Sovereignty):某些国家或地区的法律规定,数据必须存储在本国境内。选择对应的 Region 可以满足这些合规要求。
- 灾难恢复 (Disaster Recovery):你可以在一个 Region 部署主要业务,在另一个非常遥远的 Region 部署备份。如果一个地区发生自然灾害(如地震、海啸),另一个地区的服务完全不受影响。
- 成本和可用服务差异:不同 Region 的服务定价可能会有所不同,并且不是所有 AWS 服务在每个 Region 都可用。
一句话总结 Region: 你在全球地图上选择的、用于部署云资源的物理位置(城市)。
查看 Ec2 的 Region 和 AZ
- EC2 实例是区域性资源,所以你必须先切换到你的实例所在的 Region 才能看到它。如果你不确定,可以挨个切换 Region 查看。
- 这个选定的区域本身就是你的 EC2 实例的 Region
在实例列表中找到你的目标实例。可用区 (Availability Zone) 这一列会直接显示实例所在的 AZ,例如 us-east-1a
或 ap-northeast-1c
。从 AZ 名称中也可以看出 Region。例如 us-east-1a
的 Region 就是 us-east-1
。
可用区 AZ
想象一下你把所有服务器都放在了城市A的一个数据中心机房里。如果这个机房因为断电、火灾或者网络故障而整体瘫痪了,你的整个业务就下线了。这就是“单点故障”。
可用区 (AZ) 就是为了解决这个问题而设计的。一个 Region 内的多个 AZ 是:
- 物理上隔离的:它们有独立的供电、散热和网络连接。一个 AZ 的物理故障不会影响另一个 AZ。
- 通过低延迟网络互联的:它们之间的网络延迟非常低(通常在 2 毫秒以内),使得数据可以快速同步。
使用多个 AZ 并非完全没有代价,但这些代价通常远小于它带来的好处。
数据传输成本 (Cross-AZ Data Transfer Cost)
- 这是最主要的成本因素。
- 在同一个 AZ 内的 EC2 实例之间传输数据是免费的。
- 跨不同 AZ 传输数据是收费的。费率通常是每 GB 约 0.01 美元(双向收费)。
微小的网络延迟 (Inter-AZ Latency)
- 虽然 AZ 之间的网络很快,但毕竟存在物理距离,光纤传输需要时间。这个延迟通常是
1-2ms
。 - 对于绝大多数 Web 应用、API 服务、企业应用来说,这个延迟完全可以忽略不计。
- 虽然 AZ 之间的网络很快,但毕竟存在物理距离,光纤传输需要时间。这个延迟通常是
架构复杂性增加
- 你需要正确地规划子网,确保资源在不同 AZ 间的均衡分布,子网(Subnet)属于单个 AZ。
- 你的应用程序需要设计成无状态的,或者能够处理跨 AZ 的状态同步。
一个典型的多 AZ 网络分布架构示例:
- Region: us-east-1
- VPC: my-vpc (10.0.0.0/16)
- AZ-A (us-east-1a):
public-subnet-a
(10.0.1.0/24) -> 放置 ELB 节点、NAT Gatewayprivate-subnet-a
(10.0.2.0/24) -> 放置 EC2 Web服务器、RDS 主数据库
- AZ-B (us-east-1b):
public-subnet-b
(10.0.3.0/24) -> 放置 ELB 节点private-subnet-b
(10.0.4.0/24) -> 放置 EC2 Web服务器、RDS 备用数据库
通过这样的布局,即使整个 us-east-1a
可用区都发生故障,你的 ELB 依然可以在 us-east-1b
接收流量,RDS 会自动切换到 us-east-1b
的备用数据库,us-east-1b
的 EC2 服务器会接管所有业务,从而保证了服务的连续性。
VPC - “私有办公园区”
VPC (Virtual Private Cloud) 是你在 AWS云中创建的一个逻辑上隔离的、私有的虚拟网络空间。你可以把它想象成你在选定的城市(Region)里,为自己公司圈起了一块地,盖了一个专属的、有围墙和门禁的办公园区。
- 它是一个虚拟网络,完全由你掌控。你可以自定义它的 IP 地址范围、创建子网、配置路由表和网络网关等。
- 这个“办公园区”是完全隔离的,默认情况下,一个 VPC 里的资源无法和其他 VPC 里的资源通信,也无法访问互联网。你需要明确地配置规则来允许这些通信。
为什么需要 VPC?
1. 安全和隔离 (Security & Isolation):这是 VPC 最核心的价值。你可以把数据库等核心资产放在无法被外界直接访问的私有子网(没有门禁卡进不去的楼层),把 Web 服务器等需要对外提供服务的资源放在公共子网(像大堂一样可以接待访客的楼层)。
2. 自定义网络架构 (Custom Network):你可以像搭建传统数据中心一样,自由地规划网络结构,完全控制进出“园区”的流量。
VPC 和 Region 关系
VPC 是区域性的,不能跨 Region,可以跨越 Region 内的多个可用区 (AZ)
你可以在一个 AZ 的子网里放一台服务器,在另一个 AZ 的子网里放另一台服务器作为备份。这样,即使一个 AZ(数据中心园区)因为断电等故障整体瘫痪,另一个 AZ 里的服务仍然可以继续运行,从而实现高可用性。
1.3 ELB 和 NAT Gateway
ELB 和 NAT Gateway 没有直接的父子或依赖关系,但它们是构建安全、可扩展的现代云架构中相辅相成的两个关键组件。
ELB (Elastic Load Balancer):是流量的入口,负责接收来自互联网的、访问你应用的请求,并将其分发给后端的多个服务器。它的方向是 “外到内” (Inbound)。
NAT Gateway (网络地址转换网关):是流量的出口,让你私有网络内的服务器可以主动访问互联网(如下载更新、调用外部 API),但互联网无法主动访问这些私有服务器。它的方向是 “内到外” (Outbound)。
想象一下你的 AWS VPC(虚拟私有云)是一个安保严密的公司大楼。
ELB (负载均衡器) = 大楼前台
前台接待所有来访者,然后根据来访者的需求(如访问
your-app.com/users
),将他们引导到具体负责这个业务的、并且当前有空的员工(健康的EC2服务器)那里去。如果某个员工请假了(服务器挂了),前台就不会再把访客引荐给他。
NAT Gateway (NAT 网关) = 公司的统一外线电话
所有需要向外通信的员工都通过公司的总机外线打出去。外界看来,所有电话都是从“XX公司总机”打来的(NAT网关的固定公网IP),而不知道具体是哪个员工。外界也无法通过这个外线电话直接找到内部的某个员工(EC2服务器)。
必须部署在公有子网中,并分配一个弹性IP(Elastic IP),但它服务的对象是私有子网 (Private Subnet) 中的实例。
单向访问:只允许出,不允许进。
1.4 ELB 和 Target Group
Target Group(目标组)是 ELB 进行流量转发的最终目的地集合。ELB 本身不直接连接到你的 EC2 实例或服务器,而是连接到一个或多个 Target Group,再由 Target Group 来管理和检查后端的具体服务器(即 Targets)。
三层关系:ELB -> Target Group -> Targets
ELB (负载均衡器) = 餐厅的领位员
- 他站在餐厅门口,是所有顾客的唯一入口。
- 他负责接待顾客(接收请求),并根据顾客的需求(例如,是想吃日料还是铁板烧)来决定把他们带到哪个区域。
Target Group (目标组) = 餐厅的不同功能区(例如,“日料区”、“铁板烧区”)
- 每个区域有自己的厨师团队和服务员(Targets)。
- “日料区”有专门的日料师傅,他们有自己的工作标准和流程(Target Group 的配置,如端口、健康检查路径)。
- “铁板烧区”有专门的铁板烧师傅,他们有另一套标准。
Targets (目标) = 每个区的具体厨师和服务员(EC2实例、IP地址、Lambda函数)
- 他们是真正为顾客做菜和提供服务的人。
- 顾客(用户请求)来到餐厅,找到领位员 (ELB)。
- 顾客说:“我想吃日料。”(请求的 URL 是 your-app.com/sushi)。
- 领位员 (ELB) 查看他的引导手册(ELB 的监听器规则),发现路径 /sushi 应该去 “日料区” (Sushi Target Group)。
- 领位员随后将顾客引导至“日料区”。
- “日料区”的经理(Target Group 的逻辑)会查看当前哪位厨师 (Target/EC2) 不忙并且状态良好(通过了健康检查),然后将这位顾客的菜单交给他。
你可以用一个 ALB 来支撑整个复杂的微服务应用,每个微服务对应一个独立的 Target Group。
另外ALB 被放置在公有子网中,我们的EC2实例(目标)将被放置在私有子网中以保证安全(这是最佳实践)。
Target group
创建目标组 (Create target group)
Choose a target type: 选择 “实例 (Instances)”。这意味着你的目标是 EC2 实例。
Protocol : Port: 设置为
HTTP
和80
。这表示 ALB 将会通过 HTTP 协议将流量转发到目标实例的 80 端口上。**Health checks (健康检查)**:这是关键部分!ALB 用它来判断你的实例是否能正常工作。
1
2
3
4
5"target type": "IP addresses"
"name"
"port": http:80
"vpc":
"health": "/readiness"Register targets
- 在 “可用实例 (Available instances)” 列表中,你会看到你在该 VPC 中创建的 EC2 实例。
- 勾选你想要添加到这个目标组的实例。
Target Group可以配置不同的负载均衡算法,以决定如何将流量分配到不同的目标。
轮询(Round Robin):按顺序将请求分配给每个目标。
最少连接数(Least Connections):将请求分配给当前连接数最少的目标。
IP哈希(IP Hash):根据请求源IP地址的哈希值将请求分配给目标。
Application Load Balancers
- 创建 ALB
- Scheme (方案): 选择 “Internet-facing (面向互联网)”。这意味着它将拥有一个公共 DNS 名称,可以从互联网访问。
- IP address type: 选择
IPv4
。 - Network mapping (网络映射):Mappings: 这是非常重要的一步!你必须为你的 ALB 选择子网。请选择至少两个位于不同可用区的公有子网 (Public Subnets)。这能保证 ALB 的高可用性。
- Security groups: 入站规则 (Inbound rules): 允许来自任何地方 (
0.0.0.0/0
) 的HTTP
(端口 80) 流量。如果你打算使用 HTTPS,也要允许HTTPS
(端口 443)。 - Listeners and routing (侦听器和路由):这是关联 Target Group 的核心步骤!
1 | "Load balancer IP address type": "IPv4" |
- 收紧 EC2 的安全组 (最佳实践)
- 现在 ALB 已经可以和 EC2 通信了。为了提高安全性,我们不应该让任何人都能直接访问 EC2。
- 修改EC2 实例的安全组,允许来自你 VPC 的 HTTP (端口 80) 规则的源 (Source),修改为 ALB 所使用的那个安全组。
- 只有来自你的 ALB 的流量才能访问 EC2 的 80 端口,其他所有直接访问都会被拒绝,非常安全。
1.5 证书问题
HTTPS (SSL/TLS 加密) 是在 Application Load Balancer (ALB) 层面进行配置和终止的。
这意味着:客户端到 ALB 的流量 是加密的 (HTTPS)。ALB 到 Target Group (EC2 实例) 的流量 可以是未加密的 (HTTP)。
1 | 用户 (浏览器) <- [加密的 HTTPS 流量] -> ALB <- [未加密的 HTTP 流量] -> Target Group (EC2) |
好处是:
- 集中管理证书:你只需要在 ALB 上管理一个证书,而不是在每一台后端 EC2 上都安装和续订证书。
- 降低后端服务器负载:EC2 实例不需要消耗 CPU 资源去处理加密和解密,只需处理标准的 HTTP 请求。
- 简化后端配置:你的 EC2 实例上只需要一个普通的 Web 服务器(如 Nginx/Apache 监听 80 端口),无需任何复杂的 SSL 配置。
- VPC 内部安全:ALB 和 EC2 之间的流量是在你受信任的私有网络 (VPC) 内部传输的,通常认为这个环境是安全的。
实现步骤
申请证书
在 ACM 中申请免费证书,注意ACM 证书是区域性的。
DNS 验证 (强烈推荐):这是最简单且支持自动续订的方法。ACM 会给你一个 CNAME 记录,你需要在你的域名提供商(如 GoDaddy, Namecheap, 或者 AWS Route 53)的 DNS 配置中添加这个记录来证明你拥有该域名。
在 ALB 上配置 HTTPS 监听器
- 点击 “添加侦听器 (Add listener)”。选择
HTTPS
,端口会自动填充为443
。 - Default action (默认操作)“转发到 (Forward to…)”在下方的下拉框中,选择你之前创建的 Target Group。
- Secure listener settings (安全侦听器设置):Default SSL/TLS certificate,选择
From ACM
(默认)在下拉菜单中,选择你刚刚创建并已签发的证书。
- 点击 “添加侦听器 (Add listener)”。选择
2. EC2
2.1 修改磁盘大小
- 去终端修改大小: EC2 -> Elastic Block Store -> Volumes ( 左侧 ) -> 修改AWS 磁盘大小 (在 ec2 的 storage 里看到 volume ID)
- 使用命令调整
1 | #检查扩容状态,首先,确保你已经在 AWS Console 中增加了 EBS 卷的大小。 |
3. S3
3.1 S3 加速模式
1 | obj, err := s.preSignClient.PresignPutObject(ctx, &s3.PutObjectInput{ |
先开启S3 网页加速功能,再上线代码。
先下线代码,后下线 S3 网页加速功能。
3.2 S3 私有桶配置 cloudfront 访问
S3 block all 权限
- 返回到S3控制台,选择您的Bucket。
- 点击“权限”选项卡。
- 在“Bucket策略”部分,添加以下策略以允许CloudFront的OAC访问您的Bucket:(E20SXT84JIMV9 是 CloudFront 的 ID)
1 | { |
3.3 下载和上传文件
1 | # 1. 下载 |
aws s3 cp 和 aws s3 sync 的区别
aws s3 cp
- 复制所有文件:无论目标位置是否已经存在相同的文件,
cp
都会无条件地复制文件。例如,如果目标文件已存在,cp
会直接覆盖它而不会检查文件的内容或时间戳。(learnaws.org) - 不支持删除:
cp
不会删除目标位置中多余的文件,即使这些文件在源位置中已经被删除。(learnaws.org)
- 复制所有文件:无论目标位置是否已经存在相同的文件,
aws s3 sync
- 只复制新增和更新的文件:
sync
命令会检查源和目标文件的时间戳或大小差异,只有那些在源位置中新增或更新的文件才会被复制到目标位置。(learnaws.org) - 支持删除多余文件:使用
--delete
选项时,sync
会删除目标位置中那些在源位置不存在的文件,从而确保目标和源的一致性。
- 只复制新增和更新的文件:
4. CloudFront
https://mp.weixin.qq.com/s/e-pCAT65zeLu4qxpKOiNWg
https://mp.weixin.qq.com/s/eiem8vkXLPN9RM-RgQhPAA
4.1 域名绑定 CloudFront
- 去 us-east-1(N. Virginia)区域
- 申请 cdn.aipi.com 证书
- cloudfront 在“设置”中,找到“SSL/TLS 设置”,选择刚才证书
- cloudfront 在“设置”中,增加 Alternate domain name (CNAME)
- Route S3: 创建一个CNAME cdn.aipi.com -> d8i356.cloudfront.net
4.2 让cloudfront 缓存失效
在 CloudFront 控制台中,找到并选择与您的 S3 存储桶关联的分配。
- 创建失效请求
- 在分配的详细信息页面中,选择“Invalidations”(失效)。
- 点击“Create Invalidation”(创建失效)。
- 在“Object Paths”(对象路径)字段中,输入要失效的对象路径。例如,如果您想失效整个分配,可以使用
/*
。如果只想失效特定对象,可以输入对象的具体路径,例如/path/to/your/object.jpg
。 - 点击“Invalidate”(使失效)。