我前两个月帮一个做独立开发的朋友排查故障，他刚把服务迁到aws上，本地测试全程正常，迁过去之后隔三差五出现服务响应超时，重启实例后能恢复正常，过几个小时又会重复出现问题。他翻了不少中文资料，改了好几个应用层面的配置参数，折腾了快一周都没找到根因。最后查下来，问题出在最基础的资源配额设置上，他完全不知道aws默认给新用户的资源配额是有限度的。
很多第一次接触aws的普通开发者，都会把大部分注意力放在让服务正常运行上，很少去关注平台预设的规则和默认配置，这也是绝大多数问题产生的主要原因。aws是一个提供全栈云服务的平台，小到单个计算实例，大到全球性的集群部署，都能找到对应的服务支持，对于普通开发者来说，不需要自己采购维护物理硬件，只需要按需申请资源就能部署业务，这也是很多人接触它的原因。但不少人对aws的认知只停留在"云服务器提供商"层面，忽略了它本身的服务规则设计，很容易在基础环节踩坑。
资源配额的默认限制
很多新手默认认为，aws上的资源可以随时创建，想用多少就用多少，不需要提前考虑额度问题，这个认知误区已经坑了不少人。为了避免资源被恶意占用，平台对每个账号的每种资源都设置了默认配额，不同类型的账号默认配额不一样，新账号的默认配额通常比较低，刚好满足小型测试项目的需求。
我那个朋友的问题，就是他给项目加了自动扩缩容功能，本意是高峰期自动增加实例来扛流量，没想到默认的计算实例配额只有5个，高峰期流量上来之后，自动扩缩容需要创建第6个实例，请求直接被平台驳回，原有5个实例的负载被打满，自然就出现了大面积的响应超时。等到低谷期流量降下去，自动扩缩容释放了多余实例，负载回落到正常范围，服务又恢复正常，所以才会出现这种断断续续的故障，很难一下子定位到根因。
要避免这个问题其实很简单，在正式部署项目之前，先到aws的配额管理页面核对一遍核心资源的配额，包括计算实例数量、弹性IP数量、存储容量这些，根据自己的业务预估来判断当前配额够不够，如果不够，提前提交配额调整申请，大部分常规调整申请都能很快通过。这个步骤只需要十几分钟，能避免后期出了问题再慌慌张张排查，这一点我感觉比较值得注意。
权限配置的安全原则
另一个很多人容易踩的坑，就是权限配置过于宽松。不少个人开发者，为了调试的时候不出现权限不足的提示，直接给IAM用户开通了所有资源的全权限，觉得反正只是自己一个人用，没必要搞那么麻烦的权限划分。这种做法确实能省掉调试的时候调权限的时间，但是留下的安全隐患非常大。
aws的权限体系本身是按照最小权限原则设计的，也就是说，只给账号完成当前任务必须的权限，多余的权限一律不开放，这么设计就是为了降低密钥泄露之后的风险。如果你的账号密钥不小心泄露，比如把带密钥的代码提交到了公共代码仓库，拥有全权限的账号可以被任何人操作所有资源，不管是删除数据还是创建新资源，都会带来不可挽回的损失。我之前听过好几个类似的案例，就是因为全权限密钥泄露，导致整个账号的资源被控制，最后丢了所有数据。
所以哪怕是个人独立开发，也要严格遵守最小权限原则，只给当前项目需要的权限，不需要的权限一律不开。还要养成定期轮换访问密钥的习惯，不要一个密钥用好几年，如果密钥不再使用了，及时删除，这些都是成本很低的安全加固措施，能大幅降低安全风险。
存储与网络的常见坑
除了配额和权限，存储和网络配置也是新手踩坑最多的地方。很多开发者用aws的对象存储存放静态资源，比如网页、图片、用户上传的内容，为了方便访问，不少人直接把存储桶的权限改成了公共读写。这里要特别注意，公共读写意味着任何人都可以读取甚至修改存储桶里的所有内容，如果你的存储桶里混存了敏感的配置文件或者用户数据，就会直接导致数据泄露。还有一些新手，创建存储桶的时候不小心改了默认权限，自己完全没印象，等到出问题了才发现。
正确的做法是，如果需要放公开访问的静态资源，只开放公共只读权限，不要开放写入权限，同时把公开资源和敏感数据分开存放在不同的存储桶里，不要混在一起。aws本身自带了存储桶权限扫描工具，可以定期检查有没有过度开放的权限，打开这个功能就能提前发现很多问题，不用自己一个个去核对。
再就是网络连通性异常的排查，很多人遇到访问不了服务的情况，第一反应是实例宕机或者平台网络出问题，其实超过七成的这类问题，都是安全组配置错误导致的。aws的安全组是实例层面的流量过滤规则，默认情况下只开放远程管理需要的端口，比如SSH或者RDP，如果你跑的是web服务，需要开放80或者443端口，必须手动添加对应的放行规则，不然外部流量根本进不来，自然访问不了服务。我自己刚接触aws的时候，也踩过这个坑，折腾了快两个小时才发现是安全组没开对应端口，所以对这个问题印象特别深。
架构规划的小建议
很多新手刚接触aws，看到平台有这么多高可用功能，忍不住一开始就把能加的功能都加上，又是多可用区部署，又是负载均衡，又是自动扩缩容，把架构搞得非常复杂，其实对于大部分个人开发的小项目或者测试项目来说，完全不需要这么做。过度设计不仅会增加配置的复杂度，出问题的时候排查难度也会提升很多，本来一个简单的问题，因为分层太多，要找半天才能找到根因。
从这个角度看，新手入门的时候，应该先从最简单的架构开始，先把服务跑通，等业务量真的上来了，再逐步添加高可用组件，优化架构，不需要一开始就追求完美的架构。另外，区域选择也不要随便选，如果你服务的用户集中在某个地区，选离用户更近的区域，能明显降低响应延迟，同时还要提前确认你需要用的服务在目标区域有没有开放，有些特殊服务只在特定区域可用，不要部署完才发现不对，再迁数据就很麻烦。
最后还有一个容易忽略的点，就是监控告警的配置。很多人部署完服务就不管了，不开监控也不开告警，等到服务出问题，用户找上门才知道，耽误很多处理时间。其实aws自带基础的监控告警功能，不需要复杂的配置，只需要把CPU使用率、内存使用率、实例状态这些核心指标的告警打开，设置好通知方式，出问题就能第一时间收到提醒，提前处理，不会等到影响用户了才发现。这个步骤花不了十分钟，但是对服务稳定性的提升很大，很多新手容易跳过这一步，其实很不划算。