★ FEATURED ARTICLE 前两天团队里新来的实习生问我“哥AWS这么多服务我到底该从哪儿开始学”我当时没直接回答反手给他开了一台EC2让他自己把环境装明白。他折腾了一下午回来说“服务太多了光看控制台就头晕。”这句话我特别能理解——AWS目前对外提供的云服务超过200项每个服务打开都有一堆术语新人很容易陷进去不知道学什么。这份内容就是奔着“少走弯路”去的。我先按实际用途把AWS的核心服务重新梳理一遍再用一个完整的实战项目从零跑通账号准备、CLI安装、网络搭建、EC2部署、RDS落地、S3存储一路到CloudFront分发最后还会聊几个我真实踩过的坑——包括前一阵第三方组件异常引发AWS大规模中断的事件复盘。无论你是刚开始接触云计算AWS的新手还是已经上手一阵子、想系统补全知识体系的运维开发者这份东西都应该对你有用。1. AWS不是一堆云服务的堆砌而是一整套云计算操作系统很多新手看AWS的第一眼是被它的“全”吓到的。EC2是虚拟机、S3是存储桶、Lambda是函数、CloudFront是CDN、RDS是数据库、IAM是权限……每项单独看都挺清晰合在一起就不知道怎么串。其实换个角度理解就顺了AWS就像一台“超级计算机”它把物理数据中心里的一切都拆成了可以按需付费的API然后按层次组织起来。1.1 从“服务多到让人劝退”说起AWS在2024年财报中披露的活跃服务数量超过240个但别被这个数字吓退。绝大多数业务项目真正高频使用的其实只有十几个。我自己的经验是把服务按“生命周期”而不是按“字母表”去记会轻松很多。比如一个新项目上线它的生命周期是这样的算力从哪来——EC2、ECS、EKS、Lambda数据往哪放——S3、EBS、EFS数据库用哪个——RDS、DynamoDB、Aurora网络怎么连——VPC、Route 53、CloudFront安全和权限怎么管——IAM、KMS、WAF出了问题怎么看——CloudWatch、CloudTrail、X-Ray按这条线去理解服务之间就有了逻辑关系不再是离散的“产品列表”。这也是我推荐所有新手的第一种学法先建立全局地图再逐个击破。1.2 用四层模型理解AWS的顶层设计如果非要给AWS服务分层我习惯分成四层每一层都解决一类固定的问题层级核心服务解决什么问题基础设施层EC2、EBS、VPC、S3、Route 53提供计算、存储、网络等基础资源数据与AI层RDS、DynamoDB、Bedrock、SageMaker管理数据、训练和调用模型应用集成层Lambda、API Gateway、SQS、SNS把业务逻辑串联成完整系统运维与治理层CloudWatch、IAM、CloudTrail、Organizations监控、审计、权限与成本治理理解这四层之后你再去看AWS的官方文档目录比如Well-Architected Framework会发现它讲的架构最佳实践本质上就是这四层怎么协同。五根支柱——卓越运营、安全性、可靠性、性能效率、成本优化都是落在这四层之上。我自己带人入门时有个土办法让新人用“四层模型”把任何一个AWS案例拆一遍。比如一个常见的电商网站架构拆完就是——EC2跑应用、RDS存订单、S3放商品图、CloudFront做加速、IAM控制后台权限、CloudWatch看监控。拆完三个案例整个AWS的骨架也就清楚了。2. 记住这六个核心服务AWS入门就算站稳了服务地图建立之后下一步就是精读几个核心服务。下面这六个是我认为“无论如何都要搞懂”的它们几乎是所有云上应用的底座。每个我都会把原理、用途、常见误区一起说清楚。2.1 EC2能跑Linux和Windows的“云端虚拟机”EC2Elastic Compute Cloud是AWS的标志性产品也是大多数人接触云计算AWS的第一站。它的本质就是一台虚拟机但和你在VMware里开的虚拟机有一个关键区别EC2的底层是AWS在全球多个可用区Availability Zone里维护的大规模虚拟化集群你可以在几分钟内开出任意配置的实例用完还能释放。EC2有几个核心概念必须吃透AMIAmazon Machine Image操作系统的“模板”。除了官方提供的Amazon Linux、Ubuntu、Windows Server也可以自己封装镜像或者从Marketplace买第三方镜像。实例类型决定CPU、内存、网络性能的组合。t系列是低成本通用型c系列是计算优化型r系列是内存优化型g系列是GPU实例。新手最容易犯的错是“一上来就开大规格”其实很多测试负载用t3.micro就够了。密钥对Key Pair登录实例的SSH凭证。AWS不会保存你的私钥下载完一定要放好丢了就只能重建实例。安全组Security Group实例级别的虚拟防火墙。默认出站全放通、入站全拒绝你需要显式放通22端口SSH和80端口HTTP。我实际用下来EC2最需要注意的是“成本”。按需实例价格看着不高但我见过有人忘了关实例一个月跑出几百美元账单。防护手段很简单给实例打Name标签设置预算告警非生产环境尽量用“按小时计费定时关机”的策略。2.2 S3对象存储中的事实标准S3Simple Storage Service全称里有“Simple”但它绝不简单。作为对象存储的鼻祖S3几乎成了整个互联网的“公共文件系统”。它的设计理念是把文件当作“对象”存进“桶Bucket”里每个对象有一个唯一的键Key通过URL访问。S3有几个不可替代的特点存储等级分层S3 Standard适合热数据S3 Glacier适合冷数据归档S3 Intelligent-Tiering可以根据访问频率自动调层。合理设置生命周期策略能省下不少钱。静态网站托管不用跑任何服务器直接把HTML/CSS/JS上传到桶里开启Static Website Hosting就能得到一个对外访问的静态站点。版本控制与跨区域复制开启版本控制后误删文件也能找回跨区域复制则能用空间换容灾能力。初学者最容易踩的坑是“桶权限”。S3默认是私有的但很多人为了图方便给桶配了Public Access结果数据被全网公开。S3的安全最佳实践是保持默认私有需要对外分享时用CloudFront配合Origin Access ControlOAC来授权而不是直接把桶公开。这个习惯一定要从第一天就养成。2.3 VPC你在云上的私有网络空间VPCVirtual Private Cloud是最容易被初学者忽略、但实际最核心的服务。可以把它理解成“你在AWS机房里的私有网络隔间”。你在这个隔间里自己规划IP网段、划分子网、配置路由表和网关。VPC里几个必懂的概念子网Subnet把VPC的IP段切成小段。公有子网里的实例可以分配公网IP私有子网里的实例只有内网IP。典型做法是把Web服务器放在公有子网数据库放在私有子网。互联网网关IGWVPC通向公网的“大门”想从公网访问你的实例就必须挂上它。NAT网关让私有子网里的实例能主动访问外网比如下载补丁但外网无法主动连进来。路由表Route Table定义每段流量该往哪儿走是VPC的“导航系统”。很多人问“我用默认VPC不就行了为什么还要自己搭”默认VPC确实能用但它把很多细节藏了起来一旦遇到网络不通的问题就无从排查。自己手动搭一遍VPC你会真正理解IP规划、路由、网关这些网络基础知识这个坑早踩比晚踩好。2.4 RDS和Lambda托管数据库与服务端无服务器计算RDSRelational Database Service是“托管数据库”的典型代表。所谓托管就是你不用关心数据库服务器的补丁安装、备份、故障转移这些底层运维只管连接、建表、写SQL就行。RDS支持MySQL、PostgreSQL、SQL Server、MariaDB和Oracle还支持Aurora这种云原生数据库。我个人的建议是新项目如果选开源数据库优先选Aurora PostgreSQL或Aurora MySQL——性能和兼容性都在线运维更省心。Lambda则是另一类思维——无服务器计算。你不买服务器只上传代码指定触发条件比如API请求、文件上传到S3、定时任务AWS会在需要时自动运行你的代码用多少算多少。Lambda的计费粒度是毫秒级对于间歇性任务非常便宜。Lambda的学习成本不在“写函数”而在“转变架构思维”。传统思路是“服务器常驻请求来了处理”无服务器思路是“事件来了临时拉起代码处理”。一旦习惯这种事件驱动模型你会发现很多场景图片处理、消息通知、定时任务用Lambda加S3、SQS组合比维护一堆服务器轻量得多。2.5 IAM权限设计决定云上安全的下限IAMIdentity and Access Management是AWS所有服务的安全底座。它的核心逻辑就两件事你是谁身份你能干什么权限。身份包括用户User、用户组Group和角色Role权限则通过JSON格式的策略文档Policy来定义。IAM的常见误区有两种一是“长期用根账号”二是“一上来就给管理员权限”。根账号的权限大到无法限制一旦密钥泄露等于整个云账号拱手让人。正确做法是用根账号创建管理员用户后平时就切换到管理员用户操作。给每个开发成员创建独立用户按需分配策略。服务器上不自建账号直接用IAM Role授权临时凭证。IAM Role是AWS里非常优雅的设计。EC2实例、Lambda函数、甚至外部应用都可以“扮演”一个角色自动获取临时访问凭证无需在代码里写死Access Key。这样既安全又方便我在实战里凡是涉及跨服务访问比如EC2访问S3一律用Role。3. 用真实项目跑通AWS从账号准备到Demo部署的完整链路服务讲再多不如亲手跑一遍。下面我以一个典型的Web应用部署为例带你从零到一走完整条链路。这是我自己带新人时固定的教学项目一个基于Node.js的待办事项应用前端静态资源放S3后端API跑在EC2上数据库用RDS PostgreSQL所有网络通信经过VPC和子网隔离。3.1 本地开发环境准备在macOS上安装AWS CLI做云上开发第一步不是登录网页控制台而是在本地装好AWS命令行工具。命令行是连接AWS的最短路径尤其适合批量操作和自动化脚本。以macOS为例安装AWS CLI v2推荐用官方提供的捆绑安装包# 下载安装包后运行 sudo installer -pkg AWSCLIV2.pkg -target / # 验证安装 aws --version # 配置凭证 aws configureaws configure会依次要你输入Access Key ID、Secret Access Key、默认地域和输出格式。Access Key在IAM用户控制台生成生成时要一次性保存好Secret。配置完成后用aws sts get-caller-identity验证身份是否生效。如果你用的是旧版本CLI可以通过curl脚本安装但我个人更推荐官方pkg安装包升级方便也避免了Python环境依赖的坑。3.2 第一步构建网络与安全基线任何生产系统都不该直接用默认VPC。我们在实战里手动搭建一个标准的二层网络结构一个VPC网段规划为10.0.0.0/16。两个公有子网分别放在两个可用区用于部署EC2。两个私有子网同样跨两个可用区用于部署RDS数据库。一个互联网网关挂到VPC上路由表指向它。这个结构的意义在于数据库没有公网IP外网无法直接访问只有同一VPC内的应用服务器能连。我把这套搭建过程写成了CloudFormation模板但首次学习建议先手动在控制台点一遍这样每个资源之间的依赖关系才记得住。安全组方面我给EC2配置两条入站规则22端口只允许你的办公网IP访问80端口允许所有人访问。数据库安全组则只允许来自EC2安全组的流量访问5432端口。安全组引用的好处是以后EC2实例换IP也不影响数据库访问。3.3 第二步用EC2搭建应用节点选型上学习环境用t3.micro足够生产环境看负载再升级。操作系统选Amazon Linux 2023它和AWS各服务的集成度最高内置了SSM Agent。启动实例时给实例绑定一个IAM Role角色策略里授予S3只读权限——这样应用读取S3里的静态配置时不需要在服务器上保存任何Access Key。实例启动后SSH连上去装运行环境sudo dnf update -y sudo dnf install -y nodejs npm nginx然后把应用代码上传到/var/app用systemd托管Node.js进程。Nginx作为反向代理把80端口流量转发到应用监听的内网端口。这时候访问EC2的公网IP应该能看到应用首页但数据库还没接上登录接口是报错的。这里有个小技巧给实例打上NameTodoApp-Web-01和EnvDev两个标签。标签在AWS里有“元数据管理”的作用后续看账单、做自动化、按环境隔离都靠它。3.4 第三步RDS数据库与服务代码联调创建RDS实例时引擎选PostgreSQL 16规格从db.t3.micro起步。网络配置里VPC选刚建好的子网组选两个私有子网。这个实例不会分配公网IP所以只能从VPC内部访问。连接数据库有两种方式如果EC2上有工具直接psql连如果本地想连就得先搭一个SSH隧道ssh -i ~/.ssh/key.pem ec2-userEC2_PUBLIC_IP -L 5432:RDS_ENDPOINT:5432 -N隧道建立后本地数据库工具就能连到RDS的5432端口。这个操作在生产上很实用日常调试数据库用隧道不把数据库直接暴露到公网。应用配置里把数据库连接信息放进环境变量再重启Node.js服务。建表语句跑完后注册、登录、增删待办事项这几个接口就能全通。联调通过后我把这套配置的过程写成了一份部署文档以后只需要按文档执行二三十分钟就能复现一套完整环境。3.5 第四步在S3上存储对象文件并将静态资源托管到CloudFront应用的图片上传和导出文件建议直接交给S3处理不要写进服务器磁盘。我在Bucket里建了uploads/和exports/两个“前缀”相当于文件夹然后给实例的IAM Role加上对这个桶的PutObject、GetObject权限。代码里调用SDK二三十行就能实现文件上传。前端静态资源同样放在S3上。做法是构建完前端后用aws s3 sync命令同步到桶里aws s3 sync dist/ s3://my-todo-app-frontend/然后创建一个CloudFront分发源站指向这个S3桶通过OAC授权访问。这样浏览器访问的是CloudFront的加速域名后端API仍然走EC2动静分离的好处是——静态资源访问压力全部打在CDN节点上源站EC2只处理API请求抗压能力强很多。整个实战跑完你就把AWS的六大核心服务全部串了一遍VPC管网络、EC2提供算力、RDS管理数据、S3存储对象、CloudFront加速分发、IAM控制权限。这套架构虽然简单但它的骨架和大型生产系统完全一致后面换容器、加微服务都是在这个骨架上做加法。4. 实战中被真实故障教育过的那些事——从Kiro中断风波聊起服务用熟了之后比功能更重要的是“故障处理能力”。云上应用出问题第一反应不应该是甩锅而是快速定位、缩小爆炸半径。我结合一次影响面很大的AWS中断事件聊聊实战中的排障思路。4.1 一次第三方依赖失效为什么能放大成“大规模中断”前段时间有个叫Kiro的组件出了问题导致大量AWS用户在短时间内出现服务不可用的情况。这件事在技术圈讨论很多但很多人没意识到它本质上不是“AWS宕机”而是“第三方依赖引发的连锁故障”。Kiro这类组件通常被集成在应用层负责消息推送或API网关的逻辑。一旦它出现异常比如配置回退、请求限流所有依赖它的业务都会出现超时和报错。如果调用方没有设置超时时间和熔断机制请求就会层层堆积把下游服务拖垮最终看起来就像一次“大规模中断”。从我自己的经验来看这个场景离我们并不远。我曾经负责的一个服务高峰期突然所有接口响应时间飙到10秒以上查了半天才发现是短信服务商限流了而我们的代码里没有做超时控制HTTP客户端一直傻等。后来在代码里加了连接超时2秒和读取超时5秒又接了一个备用短信通道问题才算彻底解决。4.2 云上故障排查的完整链路从CloudWatch到CloudTrail云上排障和传统机房排障最大的区别是你有很多现成的观测工具。AWS上最常用的三件套是CloudWatch监控CPU、内存、网络、磁盘等指标还能查应用日志和设置告警。CloudTrail记录账号里的每一个API调用谁在什么时候做了什么操作一目了然。X-Ray追踪一个请求从入口到各个服务之间的完整调用链适合定位分布式系统里的慢请求。遇到线上问题我的排查顺序是固定的先看CloudWatch告警有没有触发再看对应的指标曲线是不是出现拐点CPU飙升、错误率上升、连接数打满然后进到应用日志里找异常堆栈最后用CloudTrail看是不是有人改了配置。有一次某个环境突然无法写入数据库所有人都在查数据库连接池我顺手看了一眼CloudTrail结果发现前一天晚上有人修改了安全组规则把数据库的入站端口关了。这种“人祸”类问题没有CloudTrail真的会排查到怀疑人生。4.3 写进架构设计的三个高可用习惯排障经验多了之后我把“如何避免故障”总结成三个习惯现在每次设计架构都会自我检查一是多可用区部署。至少把应用和数据库的主备分布在两个可用区。AWS的可用区之间物理隔离一个可用区出问题另一个还能顶上。成本增加不多但可用性提升是质的。二是配置自动扩缩容。用Auto Scaling Group管理EC2实例设定“CPU超过70%持续5分钟就扩容、低于30%持续15分钟就缩容”的策略。这样即使流量是平时10倍系统也能自动加机器扛住而不是等告警响了再手动点。三是“默认失败快”的编码习惯。所有外部调用都设超时、配重试、加熔断。如果一个依赖服务5秒还没响应直接返回降级结果而不是让用户无限等待。这个习惯在云原生环境里比加多少台服务器都管用。Kiro这类事件给我们的启示是云平台做得再稳你的架构里只要有“单点依赖”和“无兜底调用”就迟早会出事。把这些护城河提前挖好才是云上真正的安全感。5. 下一代玩法Bedrock上的生成式AI、Arm实例与云上教学生态核心链路跑通、排障能力就位之后可以抬头看看AWS上更新的方向了。现在这个阶段生成式AI、低成本ARM架构、云上教学生态是三个明显热点我把自己的上手体会分享一下。5.1 用LiteLLM统一接入Bedrock上的各类大模型AWS Bedrock是AWS推出的生成式AI服务平台它最大的卖点是你不用自己部署模型直接通过API调用Anthropic Claude、Meta Llama、Amazon Titan等主流大模型数据还留在你的VPC内安全可控。直接调Bedrock API本身不难但实际做AI应用时经常要“同一个接口切换多套模型”。比如我手上有几个测试用户有的习惯Claude的回答风格有的觉得Llama性价比更高要逐一切换太麻烦。我的做法是引入LiteLLM这一层代理它是一个开源的模型网关统一封装了OpenAI、Anthropic、Bedrock等主流API格式。from litellm import completion response completion( modelbedrock/anthropic.claude-3-haiku-20240307-v1:0, messages[{role: user, content: 用一句话解释什么是云计算}] )LiteLLM把“改用哪个模型”从代码层面的改动降级成了配置层面的改动——换模型时只改model参数就行不用动业务代码。这对快速做模型对比、成本评估都非常有用。5.2 Mac实例与Arm架构在AWS上的价值很多人不知道AWS其实提供了Mac实例EC2 Mac。它是在AWS数据中心里跑着真物理Mac mini的裸金属实例主要用于iOS开发、macOS系统自动化测试以及Apple生态的CI/CD流水线。如果你做过iOS持续集成应该能体会这在云端是稀缺能力——以前只能买一台Mac放在办公室当构建机现在按小时租就行。更通用的是Arm架构实例Graviton处理器。AWS自研的Graviton系列处理器在性价比上已经把不少同规格x86实例甩开一截尤其在Web服务、容器工作负载上性能完全够用成本却能低20%以上。我自己的轻量服务已经全部迁移到Graviton实例价格便宜、性能稳定没有遇到兼容性问题。在macOS上配合使用也很简单安装AWS CLI走标准流程绝大部分AWS资源都能用CLI在本地创建和管理。如果你还想配置多账户开发环境可以用~/.aws/config里的profile机制不同项目切不同配置避免凭证混在一起。5.3 云原生的教学线路Docker容器与Hadoop集群的搭建思路云计算相关的学历教育和在线实训平台这两年也把AWS生态纳入课程比如头歌这类平台上有大量“云计算Docker”“Hadoop搭建”的实验课。这些课程的底层逻辑和你在真实AWS上做容器化部署、搭大数据集群的思路是相通的我觉得值得聊一下。Docker的思路是在EC2上装Docker引擎然后用镜像把应用打成标准单元不管底层是什么机器都能跑# 在EC2上装Docker sudo dnf install -y docker sudo systemctl start docker # 构建并运行一个简单的Web容器 docker build -t hello-docker . docker run -d -p 8080:80 hello-docker这种方式的价值在于“一次构建到处运行”。真实项目里AWS的ECS和EKS就是把Docker容器再往上托管一层省去管理容器编排的麻烦。实验课里学的docker run、docker build都是以后的硬通货。Hadoop集群的搭建则更偏“分布式系统基本功”。在AWS上搭Hadoop的常规思路是用多台EC2组成集群一台做NameNode控制节点几台做DataNode数据节点再配合S3做数据湖存储。真正生产上很少有人再自己搭Hadoop都会直接用EMRElastic MapReduce这类托管服务。但自己搭一遍的意义在于理解分布式系统的组件角色、网络互通、节点通信机制——这些知识不会过时。综合来看AWS的教学生态把“云服务使用”和“底层原理掌握”拉得越来越近。通过实战把Docker、Hadoop这些基础组件在AWS上亲手部署一遍学到的就不只是AWS控制台的点击操作而是一套完整的云原生技术底座。我对AWS这些新功能的整体感觉是别被“新”字吓住它们的底层还是计算、存储、网络、权限这四个老生常谈的维度。Bedrock是多了个模型调用层Mac实例和Graviton只是把硬件选项变多了EMR跑Hadoop还是那套分布式逻辑。把核心链路理解透了新服务对你来说无非是换个入口的“老友”。最后分享一个实操层面的小技巧AWS的免费套餐额度很适合折腾新账号第一年有750小时的t2.micro免费EC2、5GB的S3存储、20GB的RDS免费额度。我当年就是靠这些免费额度在一个个人项目上练完了所有核心服务的手感。但你一定要在控制台设置好账单告警阈值就设1美元一旦超过就邮件提醒——很多人第一张AWS账单都是这么来的。别问我是怎么知道的。
阅读完成 · 觉得有帮助？
