前两个月帮一个做产品开发的朋友梳理环境，他第一次接触aws，对着控制台的上百个服务选项看了半天，问我到底哪些是普通开发者真正用得到的。我当时翻了不少官方文档，发现很多内容讲得太偏向资深架构师，对普通开发者不够友好。很多人对aws的认知，还停留在"海外的云计算服务"这个模糊的层面，其实弄清楚几个核心逻辑和常见场景，日常开发就能避开大部分不必要的坑。
从技术定义来说，aws是一套完整的云计算服务集合，从底层的硬件资源到上层的应用托管，都有对应的服务提供。和我们接触的其他云计算服务的核心逻辑一致，都是把物理资源虚拟化之后，按需分配给用户使用。不过因为aws发展时间较长，服务覆盖的领域多，目前公开的服务条目有几百个，多数新手初次进入控制台页面，会因为服务选项过多感到无所适从，不清楚应该从哪里着手准备。其实对普通开发者来说，只需要先搞懂三类最常用的基础服务，理清几个容易混淆的核心概念，剩下的特殊需求等到要用的时候再查资料也完全来得及。
几个容易搞混的核心概念
第一个要理清的是区域与可用区的区别。很多人第一次使用aws，会把这两个概念混为一谈，进而埋下稳定性隐患。简单来说，区域指的是物理上分散的不同地理位置，不同大洲、不同国家都会划分出独立的区域，各个区域之间物理隔离，网络延迟也有明显差异。而可用区是同一个区域内部，多个互相独立的数据中心，每个可用区都配备独立的供电、散热和网络链路，一个可用区出现硬件故障或者维护操作，不会影响同一个区域内的其他可用区。我之前听过一个实际案例，一个新手开发者做项目，为了方便把所有服务都部署在同一个可用区，后来那个可用区做例行硬件升级，网络临时中断了几个小时，整个项目直接停服，本来只要多分布在两个可用区就能避免的问题，就因为概念没理清造成了不必要的损失。
第二个容易搞混的是默认网络和自定义网络的区别。aws会给新账号提供一个默认的虚拟私有云（也就是常说的VPC），很多新手图省事，直接就在默认VPC里部署所有服务，刚开始小项目用着没什么问题，等到业务慢慢扩张，需要给不同团队划分独立的网络网段，做不同等级的访问控制，才发现默认VPC的初始规划已经没办法满足需求，想要重构整个网络拓扑，不仅耗时久，还容易影响线上服务的正常运行。这个问题我自己也碰到过，之前帮朋友调整环境，光是梳理现有资源的网络归属就花了两天时间，要是一开始就做简单规划，根本不会有这么大的工作量。还有一个很多新手容易踩的小坑：aws的资源是按区域隔离的，不同区域的资源不能直接通用，如果创建资源的时候选错了区域，翻半天找不到自己创建的资源，我第一次用的时候就犯过这个错，折腾了十多分钟才反应过来，细节很小但很耽误时间。
第三个要理清的是权限体系的逻辑。aws的权限采用的是细粒度的分配方式，不同的用户、不同的服务都可以单独分配对应的操作权限，这个设计本来是为了安全，但是很多新手图方便，不管什么场景都直接给最高权限，很容易留下安全隐患。比如开发测试用的账号，本来只需要操作测试环境的资源，结果给了整个账号的管理员权限，一旦账号泄露，整个账号下的所有生产资源都会受到影响，这个风险其实完全可以提前避免。
普通开发者常见的使用场景
第一个常见场景是多地域用户的服务部署。很多面向全球用户的产品，会选择用aws的多区域节点部署服务，让不同地域的用户就近访问，降低网络延迟，提升访问体验。这里需要注意的是，不是所有服务都需要部署到每一个区域，一般来说，静态内容比如图片、样式文件、网页，可以放到缓存服务里下沉到边缘节点，只有动态的业务服务，才需要根据用户的分布情况，部署到核心的几个区域。另外，跨区域的数据同步规则一定要提前测试，我之前帮人排查过一个问题，用户下单的交易数据只存储在主区域，跨区域同步的延迟参数没有调好，导致另一个区域的用户刷新页面，好几分钟都看不到自己刚下的订单，排查了很久才定位到同步规则的问题。
第二个常见场景是静态资源存储和异地数据备份。aws的对象存储服务，稳定性和可用性都有官方承诺，很多开发者会用来存放网站的静态资源，或者把核心业务数据备份到这里，做异地容灾。这里最容易出问题的就是权限配置，aws的默认设置里，新建的存储桶是私有状态，只有授权的主体能访问，但是很多开发者为了让用户能直接获取静态资源，图省事直接把整个存储桶改成了公开读写权限，这就会导致存储桶里存放的其他数据，比如备份文件、配置文件，也能被任意人访问，很容易造成敏感数据泄露。我见过不止一次这样的问题，有的是测试环境的配置没改，直接带到了生产环境，结果存储桶里的用户数据被爬虫批量爬走，造成了很严重的安全事故。其实这个问题只要稍微调整一下权限规则，只开放静态资源存放路径的公共读权限就可以解决，不需要给整个存储桶开公开权限，很多人就是图省一步，留下了大隐患。
第三个常见场景是临时开发测试环境的搭建。普通开发者做产品版本迭代，经常需要开辟一个独立的测试环境来验证新功能，测试完成之后这个环境就不需要了。aws支持按需创建和释放资源，适合这种短期的、弹性的需求。但是这里有一个非常容易被忽略的点，很多人测试完成之后，只关掉了计算实例，忘记释放绑定的存储块、公网地址、负载均衡这些附加资源，这些资源会一直占用账号的资源配额，对后续的资源分配造成影响。所以我每次用完临时环境，都会把整个环境相关的资源列出来挨个检查，确认全部释放之后才会结束操作，这个小习惯能避免很多不必要的麻烦。
从这几次接触和使用aws的经验来看，新手最容易犯的错，要么就是一下子想要把所有新服务都用上，追求所谓的"先进架构"，要么就是完全不做规划，上来就直接搭服务，走到哪算哪。其实对普通开发者来说，刚开始不用碰太复杂的高阶服务，先把基础的计算、存储、网络这三块搞清楚，满足当前项目的需求就足够了。有几个点我觉得比较值得提醒：
第一，哪怕是小项目，也要提前做简单的资源规划，比如VPC的网段怎么分，不同环境的可用区怎么分配，不同团队的权限怎么划分，提前花一天时间想好，比后面出问题了再重构要省很多时间。
第二，监控告警一定要提前配置好，aws自带的基础监控只能展示一些通用指标，针对自己业务的关键指标，比如服务可用性、CPU使用率、磁盘使用率，一定要提前配置告警规则，出问题的时候能第一时间收到通知，不要等用户反馈了才知道服务出了异常。
第三，权限一定要遵守最小权限原则，不管是个人开发者账号还是服务的授权账号，只给完成工作需要用到的权限，不要图方便给全量权限，绝大多数云计算相关的安全问题，都是权限配置不当导致的，这一点绝对不能偷懒。
从实际使用的角度来看，aws本质就是一个提供云计算资源的平台，核心能力和其他云计算平台没有本质的区别，只是它的全球覆盖节点比较多，所以做面向全球用户的项目时，使用的比例会高一些，普通开发者只需要根据自己项目的实际需求选择就可以，不用盲目追新，也不用刻意排斥。