很多人对aws亚马逊的认知，就是一套提供计算、存储、网络资源的公有云服务平台，从技术本质来说，和其他主流云计算平台没有特别大的区别，都是通过虚拟化技术把物理资源池化，然后按需分配给用户使用。但因为aws亚马逊的服务体系发展时间长，模块拆分非常细，很多默认规则和多数用户习惯的其他平台不太一样，加上很多用户第一次接触的时候，不会花时间通读默认配置的说明文档，很容易在这些细节上出问题。
第一个最容易踩的坑就是资源配额的默认限制。很多人不知道，aws亚马逊对几乎所有资源都设置了默认配额，而且这个配额是按区域分开计算的，你在甲区域用掉的配额，不会影响乙区域的配额，很多新手扩容的时候，只看自己当前用了多少资源，不知道每个区域都有独立的上限，所以一扩容就创建失败。刚才说的那个朋友的带宽问题，也是区域级的默认配额，他选的区域对新用户默认的出口带宽配额就是较低的，他不知道可以申请调整，就一直卡着。
还有一种情况，很多用户用弹性伸缩自动扩容实例，提前把弹性伸缩的最大实例数配置好了，结果到了高峰期需要扩容的时候，偏偏扩不出来，追根究底还是配额不够。你弹性伸缩设置了最多扩20台，但是你的区域vCPU配额只够10台，自然没法继续扩容。这种问题平时低流量的时候发现不了，一到高峰期就直接掉链子，而且排查起来非常隐蔽，因为手动创建一两台实例是可以成功的，只是到了总配额上限没法继续，很多人会排查半天应用和伸缩配置，根本想不到是平台层面的配额限制。我之前听过一个团队的案例，大流量时段弹性伸缩扩不出来，直接导致近一半用户无法访问服务，问题根源就是没提前核对配额。
从平台的角度来说，设置较低的默认配额主要是为了防止资源被恶意占用，毕竟多数新账号只是用来测试，不会用到太高的配额，所以默认给低限，如果用户有更高需求，可以提交申请调整。但对普通开发者来说，这个规则如果没人提醒，几乎不可能主动想到，因此踩坑的概率非常高。
从我实际接触到的案例来看，第一次在aws亚马逊上部署正式业务之前，先做一次全链路的配额检查，是非常有必要的。需要检查的内容包括你用到的每一种资源：计算实例的vCPU总数、弹性IP的数量、公网出口带宽、数据库的连接数、存储的容量上限，这些都要对着自己的业务峰值需求算一遍，最好比最大需求多留两成左右的冗余，要是超过默认配额，提前申请调整。这里要额外提醒，配额调整申请不是立刻就能通过的，部分配额调整需要人工审核，快的几个小时，慢的可能需要一到两个工作日，要是等到业务要上线了才去申请，很容易耽误事，这一点我遇到过好多次，感觉比较值得注意。
备份配置里容易忽略的细节
很多用户用aws亚马逊存储数据，不管是应用静态资源还是数据库备份，都常用对象存储或者块存储快照，这两种服务本身的可靠性设计很高，但配置不对照样会出大问题。我之前听同行说过一个案例，一个创业团队把主数据库的每日备份存在aws亚马逊的对象存储里，开通了跨区域复制用来做容灾，结果主区域的存储出了故障，他们切到备区域准备恢复数据，发现所有备份文件都没法访问，系统提示没有操作权限。查了半天才发现，aws亚马逊的跨区域复制默认不会同步对象的访问权限，你在主区域给备份桶设置了对应角色的只读权限，复制到备区域之后，默认只有创建者有访问权限，其他角色都没法读取，最后只能手动重新给所有对象设置权限，耽误了很久的恢复时间。这个就是典型的对服务特性不了解，以为开了复制就万事大吉，结果真出问题的时候用不了。
还有一个非常常见的坑就是增量快照的清理规则。很多用户用aws亚马逊的块存储做系统盘或者数据盘，会定期打快照做备份，知道快照是增量存储，只保存和上一次快照不一样的数据，所以就放心的一直生成快照，很少主动清理。等到快照数量越来越多，需要清理旧快照释放空间的时候，很多人会按时间排序，直接把最早的基础快照删掉，这就刚好踩中了规则陷阱。aws亚马逊的增量快照，所有后续的增量快照都是依赖最早的那个基础快照的，如果你删了基础快照，所有基于这个基础快照做的增量快照，都会丢失部分数据，整个快照链就没法正常使用。这个规则很多新手不清楚，我见过有人删完旧快照之后，想恢复一周前的数据，发现增量快照已经损坏，最后只能回滚到更早的可用快照，丢了好几天的业务数据。
要避开这些问题其实也不难，从实际操作经验来看，定期做全量快照，清理的时候只清理超过保留周期的完整快照链，不要单独删除快照链里的中间或基础快照，就能避开这个坑。另外，不管是对象存储备份还是快照备份，备份生成完成之后，一定要做一次恢复测试，不要觉得备份显示成功就没问题，很多配置错误只有在恢复的时候才会暴露出来。这个习惯不管用什么云计算服务都重要，在aws亚马逊上因为配置规则的特殊性，就更需要注意。
权限管理别图省事
aws亚马逊的权限体系基于IAM设计，精细化程度很高，可以给不同的用户、角色分配完全不同的操作权限，很多普通开发者一开始图方便，不管是开发账号还是部署用的访问密钥，直接给了全部资源的管理员权限，觉得这样开发起来不用一直申请权限，省了很多麻烦。这个做法看起来省事，实际上留下了非常大的安全隐患。
我之前知道一个案例，一个开发者把带有管理员权限的密钥写到了项目的配置文件里，不小心上传到了公开的代码仓库，不到半天就被自动化工具扫描到，账号里的所有计算实例都被异常占用，部署了非授权进程，整个开发环境完全瘫痪，团队花了整整一天才把所有资源清理干净，恢复正常开发。很多人觉得，反正就是开发测试环境，出问题也没关系，实际上开发环境如果被控制，攻击者很容易通过开发环境进一步渗透到正式环境，风险一点都不小。
还有一个常见的不好的习惯，就是很多人用同一个密钥做多个用途，开发、部署、本地测试都用同一个密钥，一旦密钥泄露，所有场景都会受到影响。aws亚马逊支持创建不同用途的访问密钥，每个密钥对应不同的角色和权限，不用的密钥要及时删除，这个只是很小的操作，但是能降低很多不必要的风险。
正确的做法其实就是最基础的最小权限原则，你这个用户或者角色只需要完成什么操作，就给对应范围的权限，不要多给。比如部署应用的角色，只需要给对应的计算实例、存储桶的操作权限，不需要给管理IAM用户或者调整全局配额的权限，开发测试的用户，只给开发环境资源的权限，不给正式环境的操作权限。aws亚马逊本身也提供了权限审计工具，可以定期扫描账号里的权限配置，找出过度授权的用户和角色，及时清理不用的密钥和账号，这个操作花不了多少时间，但是能避开绝大多数因为权限问题带来的风险。
托管服务不是完全不用管
很多普通开发者觉得，用aws亚马逊的托管服务，比如托管数据库、托管缓存，平台都帮你管好了底层基础设施，不用自己做配置和维护，直接用就行，其实不是这样。托管服务只是帮你处理了底层的硬件维护、故障迁移这类工作，上层的业务配置还是要你自己根据业务需求调整，默认配置很多时候只适合测试场景，不适合正式业务。
比如最常见的托管数据库连接数问题，aws亚马逊的很多托管数据库默认的连接数上限是按基础规格设定的，阈值比较低，如果你做的是Web应用，高峰期会有大量并发连接，默认的连接数上限很快就会被打满，打满之后新的连接请求就会被拒绝，应用直接报错。多数人遇到这种情况，第一反应会觉得是数据库性能不足，扩容了实例规格还是解决不了问题，最后才发现是连接数上限的配置没手动调整。
还有备份的问题，托管数据库默认的自动备份保留时间一般只有几天，备份频率是一天一次，如果你需要更长的保留时间，或者更高的备份频率，必须自己手动改配置，很多人默认不改，等到误删数据要恢复的时候，才发现超过保留时间的备份已经被自动删除，找不回来。另外，很多托管服务默认只部署在单个可用区，如果对应可用区出现故障，你的服务就会中断，很多新手不知道要开多可用区部署，觉得能用上就行，结果遇到可用区故障只能等待平台恢复，白白耽误业务运行。
还有一个很小但很常见的问题，很多人把静态资源直接存在aws亚马逊的对象存储里，用自带的静态网站托管功能，配置完就能用，很多人配置完之后忘了给存储桶设置合适的跨域规则，结果前端网页调用资源的时候直接触发跨域报错，很多新手排查半天，以为是前端代码的问题，最后才发现是存储桶的配置不对，这种小问题虽然好解决，但也挺浪费排查时间的。
所以说，哪怕用托管服务，也要把核心配置过一遍，根据自己的业务需求调整，不能默认什么都不改就直接上线用。
总的来说，aws亚马逊的服务体系比较成熟，功能覆盖也比较全，多数用户遇到的问题，其实不是服务本身的问题，大多是对默认规则和设计逻辑不熟悉，不小心踩了细节上的坑。对第一次接触的开发者来说，部署业务之前多花一两天时间把核心服务的默认配置和规则过一遍，比出了问题再到处排查效率要高很多。配额、备份、权限、托管服务配置这几个地方，只要提前核对好，大部分常见问题都能提前避开。