1. 从“云”到“AWS”为什么我们需要重新理解基础设施如果你和我一样是从传统的IDC机房、物理服务器时代一路走过来的那么第一次接触“AWS”或者“云计算”这个概念时内心多少会有些复杂。一方面它听起来像是能解决所有运维痛点的“银弹”——弹性伸缩、按需付费、全球部署另一方面它又像是一个全新的、充满未知术语的黑箱让人感觉过去的经验似乎一夜之间贬值了。我最初就是带着这种既兴奋又忐忑的心情开始AWS之旅的。今天这篇内容我不想把它写成一本枯燥的说明书而是想从一个“过来人”的视角和你聊聊当我们说“学习AWS云技术基础”时我们到底在学什么以及如何绕过那些我踩过的坑真正把云用起来。很多人会把“上云”简单理解为把服务器从自家机房搬到亚马逊的数据中心。这个理解对但不全对。AWS提供的远不止是“托管服务器”。它本质上提供的是一套完整的、通过API可编程的“基础设施即服务”IaaS和“平台即服务”PaaS的集合。这意味着你过去需要采购硬件、安装系统、配置网络、搭建数据库的整个流程现在都可以通过点击控制台或者运行一行命令行代码来完成。学习的核心就是从“操作物理设备”的思维转变到“消费和管理云服务”的思维。这个思维转变是AWS云技术基础中最关键也最容易被忽视的一环。2. AWS全球基础设施你的应用可以部署在何处当我们启动一个EC2弹性计算云实例时我们首先需要选择一个区域Region。这个看似简单的选择背后是AWS庞大全球基础设施的缩影也直接关系到你应用的性能、成本、合规性和可用性。理解这套基础设施的层次是后续所有操作的基础。2.1 区域Region、可用区AZ与边缘站点Edge LocationsAWS的全球基础设施是一个三层架构理解每一层的职责和关联至关重要。区域Region是地理上完全隔离的独立部署单位。每个Region由多个离散的、物理上分离的可用区Availability Zone AZ组成。例如us-east-1美国东部-弗吉尼亚北部是一个Region它内部包含了6个独立的AZ如us-east-1a,us-east-1b等。Region之间通常相隔数百甚至数千公里通过AWS专用的高速骨干网连接但网络延迟依然可观几十到上百毫秒。选择Region的首要原则是靠近你的用户以减少延迟。其次要考虑数据合规要求某些数据必须存储在特定国家或地区以及该Region提供的服务种类较新的Region可能不支持某些较老或特定的服务。可用区AZ是Region内的一个或多个离散的数据中心它们拥有独立的供电、冷却和物理安全设施并通过低延迟、高带宽的私有光纤网络互联。AZ是AWS实现高可用性High Availability, HA架构的核心。一个经典的高可用设计是将应用服务器部署在同一个Region的两个不同AZ中这样即使一个AZ因自然灾害或重大故障完全宕机另一个AZ的应用依然可以提供服务。这里有一个重要的认知AZ的编号如a,b,c在不同AWS账户中可能映射到不同的物理位置。这是AWS为了平衡各AZ资源负载所做的设计对你而言只需知道它们是不同的、隔离的故障域即可。边缘站点Edge Locations和区域边缘缓存Regional Edge Caches构成了AWS的最后一层。它们不属于任何Region而是遍布全球主要城市和人口密集区的站点主要用于内容分发网络CDN服务CloudFront和DDoS防护服务Shield。当用户请求一个通过CloudFront加速的图片或视频时请求会被路由到离用户最近的边缘站点如果该站点有缓存则直接返回极大提升访问速度。注意服务可用性因Region而异。在规划架构时务必通过AWS官方文档的“区域服务列表”确认你所需的核心服务如某些机器学习服务或金融专用服务在你目标Region是否可用。我曾遇到过在某个Region设计了一套依赖Aurora Serverless的架构结果部署时才发现该Region不支持导致方案推倒重来。2.2 核心资源与服务的全局、区域与AZ级属性并非所有AWS资源都遵循相同的范围规则这直接影响了你的架构设计全局级资源IAM身份与访问管理的用户、组、角色、策略Route 53域名服务的托管区域CloudFront的分配。这些资源不隶属于特定Region在全球生效。区域级资源大多数服务的“控制平面”属于Region级别。例如你创建了一个EC2实例这个实例的元数据类型、标签、关联的安全组存在于Region级别。但实例本身运行在某个具体的AZ内。S3存储桶的名称也是全球唯一的但桶的数据物理存储在你创建时指定的Region。AZ级资源EC2实例、EBS弹性块存储卷、RDS数据库实例的实际运行位置是具体的AZ。这意味着一个在us-east-1a创建的EBS卷只能直接挂载到同在us-east-1a的EC2实例上。理解这一点就能明白为什么做跨AZ的高可用需要一些额外设计例如为了实现跨AZ的自动故障转移你需要使用像Application Load BalancerALB区域级服务将流量分发到不同AZ的EC2实例组或者为RDS配置多AZ部署模式。3. 核心服务初探计算、存储、网络与数据库AWS有超过200项服务但入门时无需面面俱到。牢牢掌握最核心的几类服务就能构建出绝大多数常见应用。我们可以将其类比为搭建一栋房子。3.1 计算服务EC2, Lambda, ECS房子的工人与自动化流水线EC2Elastic Compute Cloud是最基础、最像传统虚拟机的服务。你可以把它理解为你租用的一台“虚拟电脑”你需要自己选择CPU、内存、存储和操作系统Amazon Machine Image, AMI然后进行登录、部署应用、配置环境等操作。它提供了最大的灵活性和控制权但也意味着你需要承担更多的运维责任打补丁、监控、备份。对于需要长期运行、有特定系统依赖或复杂自定义需求的应用EC2是首选。Lambda则代表了“无服务器Serverless”计算范式。你不再需要管理服务器只需上传你的代码函数并配置触发条件例如一个文件上传到S3一条消息发送到SNS一个HTTP请求通过API Gateway。AWS会在事件发生时自动运行你的代码按毫秒级执行时间和调用次数收费执行完毕后资源立即释放。这就像雇佣了一个按需出现的“临时工团队”只在有活干的时候才付费完美应对突发流量或定时任务。它的挑战在于需要将应用拆解为细粒度的函数并适应其短暂的运行环境和冷启动延迟。ECSElastic Container Service和EKSElastic Kubernetes Service是容器编排服务。如果你已经使用Docker将应用容器化那么ECS/EKS就是帮你管理和调度这些容器在集群中运行的服务。ECS更贴近AWS原生集成配置相对简单EKS则是完全托管的Kubernetes服务适合已有K8s生态或需要跨云部署的团队。它们介于EC2和Lambda之间提供了比EC2更轻量的部署单元和比Lambda更灵活的运行环境。3.2 存储服务S3, EBS, EFS房子的仓库与文件柜S3Simple Storage Service是对象存储服务用于存储海量、非结构化的数据如图片、视频、日志文件、备份归档。它的设计目标是极高的持久性99.999999999%11个9和可扩展性。你可以把它想象成一个无限大的、有版本控制功能的“云端网盘”。数据通过唯一的键Key来访问并支持设置生命周期策略自动将不常访问的数据转移到更便宜的存储层级如S3 Glacier用于归档。S3是静态网站托管、大数据分析湖的基石。EBSElastic Block Store是块存储服务专为需要像物理硬盘一样被挂载和格式化的场景设计主要配合EC2使用。每个EBS卷只能挂载到同一AZ的一个EC2实例上最新技术已支持跨AZ提供低延迟的磁盘读写能力。你可以选择不同的卷类型如通用型SSD gp3、预配置IOPS SSD io2来平衡性能与成本。对数据库、文件系统这类需要持久化块设备的应用EBS是标配。EFSElastic File System是托管式的网络文件系统NFS可以被同一个Region内多个AZ的数百甚至上千个EC2实例同时挂载访问实现文件共享。这对于内容管理系统、共享代码库、用户家目录等需要多服务器访问同一套文件的场景非常有用。它按实际使用的存储量计费并自动扩展。3.3 网络服务VPC, Subnet, Security Group房子的地基、房间与门锁VPCVirtual Private Cloud是你在AWS云中逻辑隔离的专属网络空间是你所有资源EC2、RDS等运行的家园。创建AWS账户时每个Region会有一个默认VPC但对于生产环境我强烈建议自定义VPC。这让你能完全掌控IP地址范围CIDR块如10.0.0.0/16、子网划分、路由表和网关。子网Subnet是VPC内的一段IP地址范围。你必须将子网关联到一个AZ。子网分为公有子网和私有子网关键区别在于路由表公有子网其路由表包含一条指向互联网网关Internet Gateway, IGW的路由使得该子网内的资源如一台面向公众的Web服务器可以直接与互联网通信。私有子网其路由表没有指向IGW的路由因此其中的资源如数据库服务器无法直接访问互联网。如果它们需要访问外网以下载更新或访问其他AWS服务则需要通过部署在公有子网的NAT网关NAT Gateway。安全组Security Group和网络访问控制列表Network ACL是防火墙。安全组作用于实例级别比如一台EC2是“有状态”的如果你允许了入站的HTTP请求其对应的出站响应会自动被允许无需额外规则。它通常用于设置精细的访问规则如“只允许来自负载均衡器的80端口流量访问我的Web服务器”。网络ACL作用于子网级别是“无状态”的需要分别配置入站和出站规则通常作为安全组的补充用于设置子网级别的粗粒度访问控制。3.4 数据库服务RDS, DynamoDB房子的专用资料库RDSRelational Database Service是托管的关系型数据库服务支持MySQL、PostgreSQL、Oracle、SQL Server等常见引擎。AWS负责底层的硬件配置、数据库软件安装、补丁更新、备份和故障恢复。你只需关注数据库本身的设计、连接和性能优化。对于需要复杂事务、SQL查询和已有成熟关系型架构的应用RDS是省心之选。其中Aurora是AWS自研的MySQL/PostgreSQL兼容数据库在性能和可用性上做了极大增强宣称性能是标准MySQL的5倍并提供了全球数据库、无服务器等高级功能。DynamoDB是全托管的NoSQL键值对和文档数据库。它的核心优势是近乎无限的扩展性和个位数的毫秒级延迟无论数据量多大、请求多高。它通过主键分区键或分区键排序键来快速定位数据非常适合需要快速读写、数据模型相对简单、吞吐量极高的场景如游戏玩家状态、购物车、物联网设备遥测。它的计费模式基于预置的读写容量单位或按需模式需要根据访问模式仔细设计表结构特别是分区键的选择否则容易引发“热分区”问题导致性能瓶颈。4. 身份、访问管理与计费安全与成本控制的基石在云上安全性和成本控制不是事后考虑的问题而是必须从第一天就融入设计的基础。IAM和成本管理工具就是为此而生。4.1 IAMIdentity and Access Management谁可以做什么IAM是AWS安全的核心。它的核心原则是最小权限原则只授予身份用户、角色完成其任务所必需的最低权限。用户Users代表长期需要访问AWS的人或程序。对于人类用户强烈建议启用多因素认证MFA。组Groups用户的集合用于批量分配权限策略。一个用户可以属于多个组。角色Roles一种可以被实体AWS服务、EC2实例、Lambda函数、其他AWS账户的用户临时“代入”的身份。角色是在云上实现安全访问的最佳实践。例如你不应该在EC2实例上存储访问S3的访问密钥Access Key而是应该创建一个拥有S3访问权限的IAM角色然后将这个角色附加到EC2实例上。实例启动后会自动获取临时安全凭证来访问S3既安全又无需管理密钥。策略Policies定义权限的JSON文档。策略分为身份策略附加到用户、组或角色定义它们能做什么。资源策略附加到资源如S3存储桶、SNS主题定义谁可以访问这个资源以及如何访问。一个常见的踩坑点是策略过于宽松。初期为了方便可能会给管理员用户附加AdministratorAccess这种全权限策略或者给EC2角色一个AmazonS3FullAccess。在生产环境中这非常危险。应该根据具体的操作如s3:GetObject,s3:PutObject和资源如arn:aws:s3:::my-bucket/*来编写精细的策略。4.2 计费模型与成本优化入门AWS采用按需付费Pay-As-You-Go模式这带来了灵活性也带来了成本不可预测的风险。理解核心计费维度是控制成本的第一步计算对于EC2主要看实例类型、运行时长和购买选项按需、预留实例、Spot实例。对于Lambda看请求次数和执行时间GB-秒。存储对于S3/EBS/EFS看存储的数据量、存储类型和请求次数。数据传输数据传出到互联网是主要成本来源。Region之间、AZ之间、服务之间的数据传输也可能产生费用。设计架构时应尽量减少不必要的数据移动并利用CloudFront等CDN服务缓存内容以减少回源流量。成本优化核心手段使用成本计算器在架构设计阶段就用AWS Pricing Calculator进行粗略估算。启用成本异常检测与预算警报在AWS Cost Management控制台设置月度预算并配置当预测费用或实际费用超过阈值时发送警报邮件、SNS避免“账单惊吓”。利用预留容量对于有稳定长期需求一年或三年的EC2实例、RDS数据库购买预留实例RI或Savings Plans可以享受大幅折扣通常40%-70%。使用Spot实例对于可中断的、无状态的工作负载如批处理、CI/CD构建代理、某些类型的Web服务器集群可以使用Spot实例其价格远低于按需实例折扣可达90%但AWS可能在需要时回收这些实例提前两分钟通知。这需要对应用进行容错设计。定期审查和清理资源养成习惯定期检查并删除不再使用的EC2实例、EBS卷、旧的EBS快照、未关联的弹性IP等。一个闲置的m5.large实例一个月也会产生几十美元的费用。5. 实操入门从零创建一个高可用的Web应用原型理论说得再多不如动手一试。下面我们通过一个经典场景——部署一个高可用的Web应用来串联起前面提到的核心服务。我们将创建一个架构用户通过互联网访问流量经过Application Load Balancer分发到位于两个不同AZ的EC2实例运行一个简单的Web服务器这些实例从同一个S3桶中读取静态资源。5.1 第一步规划与创建VPC网络环境我们不使用默认VPC而是从头创建一个自定义VPC以理解整个网络结构。登录AWS管理控制台进入VPC服务。创建VPCVPC名称my-ha-web-vpcIPv4 CIDR块10.0.0.0/16这将提供65536个私有IP地址其他保持默认点击创建。创建子网我们需要至少两个公有子网用于负载均衡器和可能的堡垒机和两个私有子网用于Web服务器。在VPC内创建子网选择刚创建的VPCmy-ha-web-vpc。创建第一个公有子网子网名称public-subnet-1a可用区选择你的Region下的第一个AZ如us-east-1aIPv4 CIDR块10.0.1.0/24创建第二个公有子网子网名称public-subnet-1b可用区选择另一个AZ如us-east-1bIPv4 CIDR块10.0.2.0/24同理创建两个私有子网private-subnet-1a(10.0.10.0/24) 和private-subnet-1b(10.0.20.0/24)分别对应两个AZ。创建并配置互联网网关IGW在VPC服务中创建互联网网关命名为my-igw。创建后在操作菜单中选择“附加到VPC”选择我们的my-ha-web-vpc。配置路由表系统会为VPC自动创建一个主路由表。我们将其改名为main-rt并将其关联到两个私有子网private-subnet-1a/1b。这个路由表默认只有一条指向VPC内部的本地路由因此关联它的子网就是私有子网。新建一个路由表命名为public-rt关联到VPCmy-ha-web-vpc。编辑public-rt的路由添加一条新路由目标0.0.0.0/0目标选择“互联网网关”然后选择my-igw。将public-rt显式关联到两个公有子网public-subnet-1a/1b。现在公有子网内的资源就有了通往互联网的路由。至此一个基础的双AZ网络环境搭建完毕。5.2 第二步准备应用服务器与安全配置我们将创建启动模板用于自动创建EC2实例。创建S3存储桶存放静态资源进入S3控制台创建桶名称全局唯一如my-web-static-assets-你的账户ID。上传一个测试图片logo.png。为了允许EC2实例读取需要修改桶策略。在桶的“权限”标签页编辑“存储桶策略”添加如下策略将bucket-name和your-account-id替换为实际值{ Version: 2012-10-17, Statement: [ { Effect: Allow, Principal: { AWS: arn:aws:iam::your-account-id:root }, Action: s3:GetObject, Resource: arn:aws:s3:::bucket-name/* } ] }这是一个非常宽松的策略仅用于演示。生产环境中应使用IAM角色进行更精细的控制。创建IAM角色供EC2实例使用进入IAM控制台创建角色受信实体选择“AWS服务” - “EC2”。附加权限策略搜索并添加AmazonS3ReadOnlyAccess这是一个AWS托管策略授予对所有S3桶的只读权限。同样生产环境应缩小范围。角色名称EC2-S3-ReadOnly-Role创建。创建启动模板进入EC2控制台在“实例”下选择“启动模板”点击“创建启动模板”。名称web-server-template。选择Amazon Linux 2023 AMI或你熟悉的AMI。实例类型选择t2.micro免费套餐适用。密钥对选择或新建一个用于SSH登录后续调试用。网络设置不在此指定由自动伸缩组决定。高级详情 - IAM实例配置文件选择刚才创建的EC2-S3-ReadOnly-Role。这是关键一步让实例自动获得访问S3的权限。在“用户数据”文本框中输入以下脚本这是一个Bash脚本实例首次启动时会自动执行#!/bin/bash yum update -y yum install -y httpd systemctl start httpd systemctl enable httpd # 获取实例所在AZ并写入主页 AZ$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone) echo htmlbodyh1Hello from EC2 instance in AZ: $AZ/h1 /var/www/html/index.html echo pStatic image from S3:/p /var/www/html/index.html # 注意这里直接使用了桶名实际中应通过变量或配置传入。这里假设桶名为 my-web-static-assets-123456789012 echo img srchttps://my-web-static-assets-123456789012.s3.amazonaws.com/logo.png width200 /var/www/html/index.html echo /body/html /var/www/html/index.html这个脚本会安装Apache Web服务器并生成一个简单的HTML页面显示实例所在的AZ以及从S3加载的图片。配置存储根卷保持默认8GB gp2。创建安全组新建一个安全组web-server-sg添加入站规则允许来自0.0.0.0/0的HTTP80端口流量仅用于测试生产环境应限制为ALB的IP。同时添加入站规则允许来自你IP地址的SSH22端口流量以便管理。点击“创建启动模板”。5.3 第三步构建高可用核心——负载均衡器与自动伸缩现在我们将创建ALB将流量分发到多个实例并创建自动伸缩组ASG来管理这些实例的生命周期。创建应用负载均衡器ALB进入EC2控制台在“负载均衡”下选择“负载均衡器”点击“创建”。选择“应用负载均衡器”。名称my-web-alb。方案选择“面向互联网”IP地址类型选择“IPv4”。网络映射选择我们创建的VPCmy-ha-web-vpc并在两个公有子网public-subnet-1a/1b前打勾。ALB必须部署在公有子网。安全组新建或选择一个允许HTTP 80端口入站的安全组如alb-sg允许源0.0.0.0/0。监听器和路由默认监听HTTP 80端口。点击“创建目标组”来新建一个。目标组名称web-servers-tg目标类型实例协议端口HTTP:80健康检查路径/检查根目录其他保持默认点击“下一步”暂时不注册实例直接“创建目标组”。回到ALB创建页面为监听器选择刚创建的web-servers-tg作为默认操作。点击“创建负载均衡器”。创建自动伸缩组ASG进入EC2控制台在“自动伸缩”下选择“启动配置”较新控制台已整合到启动模板我们直接用模板这里我们点击“创建自动伸缩组”。名称web-asg。启动模板选择我们创建的web-server-template。网络选择VPCmy-ha-web-vpc和两个私有子网private-subnet-1a和private-subnet-1b。这样ASG创建的实例就会分布在两个AZ的私有子网中。负载均衡选择“附加到现有负载均衡器”目标组选择web-servers-tg。勾选“启用负载均衡器运行状况检查”。组大小设置所需容量为2最小容量2最大容量4。这表示ASG会始终保持至少2个实例运行并根据策略最多扩展到4个。缩放策略暂时选择“无”我们手动保持2个实例即可。其他设置保持默认点击“创建自动伸缩组”。ASG创建后它会立即开始启动2个EC2实例分别在两个AZ的私有子网中并将它们注册到ALB的目标组web-servers-tg中。等待几分钟直到实例状态通过健康检查变为“健康”。5.4 第四步验证与访问在EC2控制台的“目标组”中查看web-servers-tg应该能看到两个健康的实例。在“负载均衡器”中找到my-web-alb复制其DNS名称类似my-web-alb-1234567890.us-east-1.elb.amazonaws.com。将DNS名称粘贴到浏览器地址栏访问。多次刷新页面你可能会看到页面显示的AZ在变化因为ALB在轮询分发流量并且每次都能看到从S3加载的图片。这证明了一个简单的高可用Web应用已经运行起来用户通过ALB访问ALB将流量分发到位于不同AZ私有子网中的Web服务器Web服务器从S3读取静态资源。这个原型虽然简单但它涵盖了VPC、子网、路由、安全组、EC2、IAM角色、S3、ALB、ASG等核心服务并体现了高可用和分层安全的设计思想。你可以在此基础上继续探索为ALB添加HTTPS监听器需要ACM证书、将数据库RDS部署在私有子网、为实例配置更精细的IAM角色策略、设置基于CPU利用率的自动伸缩策略等等。每一次探索都会让你对AWS云技术基础的理解更加深刻。