aws的核心概念与常见使用场景

我之前帮一个刚接外包项目的朋友排查过一次服务中断问题，他第一次接触aws，赶着想上线项目，没仔细看文档里的可用区说明，把原本要做跨区容灾的两个实例全放到了同一个可用区。刚好那个区做临时硬件维护，整个服务就停了快两个小时，耽误了项目的上线时间。很多普通开发者第一次接触aws，大多只知道它是一类云计算服务，对里面的核心概念和实际适用场景其实摸得不太清楚，很容易踩这种看起来低级但影响很大的坑。

基础核心概念梳理

aws本质是一套覆盖全球多个区域的云计算服务集合，对外提供从底层基础设施到上层业务平台的各类服务。简单来说，传统模式下企业要跑线上业务，需要自己采购服务器、交换机、存储设备，找机房托管，还要安排专人维护硬件和网络，整个流程从采购到上线可能要几周甚至几个月。用aws的话，这些底层的硬件维护、网络扩容、机房管理工作都由平台方负责，用户只需要根据自己的需求申请资源，配置好就能部署业务，整个过程可以缩短到几小时甚至几十分钟。

很多新手会把aws和网上常见的共享虚拟主机弄混，这里可以做个简单区分：共享虚拟主机是把一台物理服务器的资源分给几百上千个用户共享使用，资源不隔离，一个用户占用资源多了会影响其他所有用户，适合很低流量的个人博客这类场景。而aws提供的计算资源大多是隔离的，你申请的实例资源会专门分配给你用，不会被其他用户影响，也可以随时根据需求升级或者降级配置，灵活性高很多，适合各类正式业务使用。

对于普通开发者来说，不需要一开始就掌握aws上所有上百种服务，只需要理清四个最常用的基础模块就够应对大部分场景：第一个是计算模块，最常用的就是弹性云服务器实例，也就是我们常说的虚拟机，你可以选择不同的配置，开通后就能远程登录部署你的代码。第二个是存储模块，常用的分三类，块存储用来挂给实例做系统盘和数据盘，低延迟适合随机读写；对象存储用来存静态文件、备份数据这类不需要经常修改的内容，存储容量几乎可以无限扩展，持久性也很高；文件存储用来给多个实例共享文件，适合多实例部署的业务需要。第三个是网络模块，最核心的是虚拟私有云，你可以在里面自己划分网段，配置公网访问规则，把你的资源和其他用户的资源隔离开，保障安全。第四个是权限管理模块，也就是aws的IAM服务，用来管理不同用户、不同服务能访问哪些资源，避免越权操作。

从设计逻辑上看，aws的很多基础功能都围绕分布式高可用设计，最核心的两个概念就是区域和可用区，这也是很多新手最容易搞混的地方。区域指的是不同地理位置的独立机房集群，不同的地区会有不同的区域，各个区域之间网络是互相隔离的。可用区是同一个区域内部，互相独立的多个机房，每个可用区都有独立的供电、冷却和网络线路，一个可用区出故障不会影响同一个区域里的其他可用区。想要做高可用，就得把你的服务实例部署在同一个区域的多个可用区，这样一个可用区出问题，其他可用区的实例还能正常运行，这就是我那个朋友踩坑的地方，他没搞懂可用区的作用，把所有实例放一个区，自然就全挂了。这个地方如果处理不合适，后面排查成本会变得更高，这一点我感觉比较值得注意。

常见的实际使用场景

对于普通开发者来说，aws在日常工作里的使用场景其实比较集中，我整理了几个最常见的：

第一个是新项目快速上线搭建。不管是创业团队做最小可行产品，还是普通开发者接的外包项目，都不需要投入太多成本和精力管理基础设施，直接在aws上申请资源，配置好网络和安全规则，就能部署业务，从开通到上线最快几个小时就能完成，比传统自建的流程快很多。而且如果项目后续发展起来，需要升级配置或者扩容，也可以随时调整，不用重新采购硬件。这里要再提醒一次，上线之前一定要确认实例分布在多个可用区，不要嫌麻烦跳过这一步，不然遇到区域维护或者单点故障，服务中断的影响会很大。

第二个是异地数据备份与容灾。现在很多企业都要求核心数据做异地备份，避免本地机房遇到故障的时候，数据全部丢失。aws的对象存储服务能提供很高的数据持久性，很多团队都会把核心数据的备份副本放到不同区域的对象存储里。我之前听同行说过一个案例，有家公司的本地机房多块硬盘同时损坏，本地备份也出了问题，还好他们把备份放到了aws的对象存储，而且开了版本控制，最后顺利恢复了数据，没有造成太大的业务损失。这里的经验是，做备份一定要打开对象存储的版本控制功能，不然不小心覆盖或者删除了备份文件，就找不回来了；另外最好把备份放到和主数据不同的区域，不要把所有资源放在同一个位置，万一遇到区域级的故障，也能从别的区域恢复数据。

第三个是弹性应对波动较大的业务流量。有不少业务的流量波动很大，比如每年固定时间做线上活动，平时流量只有几百并发，活动开始的时候一下子涨到几万甚至十几万，如果是自建机房，就得提前很久扩容硬件，活动结束之后这些硬件又闲置下来，占用很多资源。aws支持自动扩缩容功能，可以配置基于CPU使用率、流量或者其他指标的扩缩容规则，流量涨上来的时候自动新增实例承接流量，流量降下去之后自动销毁多余的实例，既能应对高峰流量，又不会造成不必要的资源占用。我之前帮一个做线上活动的团队调整过自动扩缩容的阈值，一开始他们把扩容阈值设得太高，流量涨上来的时候扩容不及时，还是出现了卡顿，后来把阈值调低，让系统提前一点扩容，就解决了卡顿的问题，这个小调整很多人容易忽略。

第四个是搭建临时开发测试环境。很多团队需要给每个开发者或者每个需求开独立的测试环境，测试完之后就不需要了，aws可以快速创建和销毁实例，还能把配置好的环境做成自定义镜像，下次开新环境直接从镜像创建，不用重复配置依赖和环境，节省很多开发者的时间。测试完成之后直接销毁整个环境就行，不会占用多余的资源，很适合这类临时场景。

容易踩错的几个细节

我接触过不少第一次用aws的开发者，踩过的坑其实大多不是什么复杂问题，都是一些基础细节没注意到，这里整理几个最常见的：

第一个是权限配置过度开放。aws的IAM权限支持细粒度的配置，可以给每个用户只开他需要用到的操作权限，但是很多新手开发者遇到权限报错的时候，图省事直接给用户开了全局管理员权限，这样虽然能快速解决报错，但是留下了很大的安全隐患。如果用户的访问密钥不小心泄露，攻击者就能操作你账号里的所有资源，后果很严重。正确的做法是遵循最小权限原则，只给用户开放他完成工作必须用到的权限，哪怕配置起来麻烦一点，也比出了安全问题好。

第二个是安全组配置不当。安全组相当于aws里实例的防火墙，用来控制实例的进出站流量，很多新手图方便，直接把入站方向的所有端口对所有地址开放，这样任何人都可以尝试连接你的实例的所有端口，很容易被扫描攻击。正确的做法是只开放业务必须用到的端口，比如web服务只开放80和443端口，管理用的远程连接端口最好只对你的办公IP段开放，不要对全网开放，这样能很大程度降低被攻击的风险。

第三个是闲置资源忘记释放。很多开发者做完测试，或者项目下线之后，忘了销毁不用的实例、存储桶或者弹性IP这些资源，这些资源会一直处于运行或者占用状态，给团队的整体资源规划带来不必要的压力。我习惯每隔一段时间就查一遍账号里的资源列表，把确认不用的资源及时释放掉，这个习惯花不了多少时间，能避免很多不必要的问题。

第四个是区域选择随意。很多新手选区域的时候随便挑一个，其实区域选择对访问速度影响很大，区域离你的目标用户越近，网络延迟越低，用户访问你的服务速度就越快。如果你的用户主要集中在某个地区，最好选离该地区最近的区域，不要随便选，不然用户访问体验会差很多。另外如果有数据存储的合规要求，也要提前确认所选区域是否符合要求，不要等部署完才发现不符合规定，还要重新迁移，浪费时间。

第五个是忽略监控告警配置。很多人部署完服务就不管了，不配置监控告警，等到服务断了用户找上门才知道出问题，耽误很多处理时间。aws自带基础的监控服务，可以给CPU使用率、磁盘使用率、服务状态这些指标配置告警，出问题的时候及时通知到负责人，能很大缩短故障处理的时间，这个配置花不了十分钟，但是用处很大，很多新手容易忘了做。

很多刚接触aws的开发者，看到平台上面繁多的服务种类，会觉得无从下手，其实完全不需要一开始就把所有服务都学会。对于普通开发者来说，先把计算、存储、网络、权限这几个基础模块的概念搞清楚，把最常用的几个服务的操作练会，就够应对大部分日常开发和部署的需求了。等遇到特殊需求的时候，再去查对应的服务文档就可以，不用一开始就啃完所有文档，那样反而容易记混。

还有一个常见的误区，就是很多人觉得用云服务就一定不会出问题，其实不管用什么基础设施，都有可能出故障，aws也不例外，所以高可用配置、数据备份、容灾演练这些工作还是要做，不能把所有保障都交给平台。比如就算平台承诺了很高的可用性，自己做好多可用区部署和备份，还是能进一步降低故障的风险，这个意识一定要有。