aws亚马逊是提供公有云基础设施及相关服务的平台，核心逻辑和多数公有云类似，就是把原本需要用户自己采购、搭建、维护的计算、存储、网络等硬件资源，转化为可按需调用的服务。和传统自建基础设施比，它的优势在于不用提前投入大量硬件成本，可以根据业务需求调整资源用量。这点其实很多公有云都有，不过aws亚马逊的服务细分程度比较高，从基础的计算实例到高阶的数据处理相关服务，覆盖的场景很广，新手刚接触的时候很容易被大量的服务名词搞晕，找不到切入点。
第一个常见场景，是多区域应用部署。很多做覆盖多区域用户业务的开发者，会选择用aws亚马逊的多区域节点部署应用。这里的核心需求是降低不同区域用户访问的延迟，同时减少单区域链路波动对整体业务的影响。我之前见过一个做内容分发的小团队，他们把核心服务分别部署在三个不同区域的可用区，当某一个区域出现链路波动的时候，DNS解析可以自动把流量切到其他可用区，整体业务的可用性提升了不少。这里要注意一个容易混淆的概念，很多新手会把可用区和区域当成一个概念，其实区域是指不同的地理区域，可用区是同一个区域里互相独立的物理机房，供电和网络都是互相隔离的，做高可用部署至少要跨两个可用区，这点是比较关键的。如果只把服务部署在同一个可用区，这个可用区出故障的话，整个服务就不可用了，达不到高可用的目的。
第二个常见场景，是数据备份与容灾。不少企业和开发者会用aws亚马逊的存储服务做异地容灾备份。容灾备份的核心需求是数据不丢失，同时数据要存放在和主站点不同地理区域的位置，避免主站点出问题的时候备份也一起出问题。aws亚马逊的对象存储服务默认会把数据存放在同一个区域的多个不同物理节点，数据持久性指标很高，适合存放需要长期保存的备份数据。我之前听过一个案例，有开发者把自己的核心业务数据备份存到这个服务里，后来本地存储出了硬件故障，所有数据都读不出来，最后完全从备份恢复了数据，没有造成太大的业务损失。
但这里也有一个非常常见的坑，很多新手刚开始配置存储资源的时候，不注意权限设置，图方便把存储桶的权限开成了公共读写，哪怕是备份数据，也可能会导致数据泄露，或者被莫名占用资源。我见过不止一个新手碰到过这种情况，本来只是用来存备份的存储桶，被非授权用户发现后拿来存放其他数据，占用了大量资源，排查了很久才找到问题源头。所以不管是用来做什么的存储资源，权限配置都要遵循最小可用原则，只开放业务需要的权限，不要给不必要的开放权限，这一点我感觉比较值得提醒。
第三个常见场景，是弹性应对突发流量。不少做面向终端用户业务的开发者，业务流量会有比较明显的波动，比如做推广活动的时候，流量可能是平时的好几倍，平时流量又维持在比较低的水平，如果自己采购硬件服务器，要么高峰期资源不够用导致服务卡顿，要么平时资源闲置，造成浪费。aws亚马逊的弹性伸缩服务可以根据预设的规则，自动增加或者减少计算实例的数量，自动匹配当前的流量需求，不用人工手动调整。
这个场景对中小团队来说还是比较实用的，不用安排专人天天盯着流量变化调整资源。不过这里也有容易踩的坑，我之前帮人排查过一个不稳定的故障，就是弹性伸缩的阈值设置不对。那个开发者为了不影响用户访问，把阈值设得太灵敏，CPU使用率超过50%就扩容，低于30%就缩容，结果有一次流量出现小幅波动，十分钟之内反复扩容缩容了十几次，反而导致业务出现了不稳定的情况，还额外消耗了更多资源。还有的开发者刚好相反，把阈值设得太高，流量涨了半天都没有触发扩容，高峰期直接把服务打挂了。
所以配置弹性伸缩的时候，最好先观察一周左右的正常流量曲线，再根据实际业务的波动情况设置阈值，不要上来就直接用默认配置，默认配置不一定适合所有业务。
除了这几个常见场景，还有一个很多新手容易忽略的点，就是IAM权限管理。aws亚马逊的权限体系设计得比较细，几乎每个服务的每个操作都可以单独配置权限。很多新手刚上手的时候，图调试方便，给每个新建的账号都开了全权限，觉得这样不会碰到权限不够的报错，省得一次次调整。这个习惯其实非常危险，一旦账号信息泄露，整个账户下的所有资源都会被非授权用户控制，后果非常严重。哪怕是内部开发用的测试账号，也要按照岗位和工作需求分配权限，开发只给开发需要的权限，运维只给运维需要的权限，不要给超出工作需求的权限。
还有就是账户的根账号，一定要保管好访问凭证，不要把根账号给普通开发人员日常使用，也不要把访问凭证硬编码到代码里，更不要把带凭证的代码推到公开的代码仓库，这种案例我听过不少，很多人不小心把带凭证的代码推到了公开仓库，很快就被自动扫描工具发现，随后出现了资源被非授权占用的情况，处理起来非常麻烦。
我接触下来，发现新手对aws亚马逊常见的认知误区有三个，第一个误区，就是很多人觉得用了aws亚马逊的服务，就不用管运维了，所有事情都由平台负责。其实不是这样，aws亚马逊负责的是底层基础设施的运维，比如硬件故障处理、物理网络的维护，上层的应用代码、操作系统安全补丁、应用层面的安全配置，还是需要用户自己负责维护。
之前有个开发者，用基础计算实例跑网站，大半年没更新过系统补丁，被漏洞入侵了，还以为是平台的安全问题，其实是自己没做好上层的维护工作。第二个误区，就是觉得必须用aws亚马逊的全系列原生服务，才能把服务用好。其实不是这样，很多小项目或者早期创业团队，业务规模不大，只需要用基础的计算、存储、网络服务就够，不用硬上那些复杂的托管服务，反而会增加不必要的学习成本，拉长开发周期。可以根据自己的业务规模逐步升级服务，不用一开始就追求全栈使用原生服务。第三个误区，就是用完资源不清理，很多开发者做测试的时候，临时开了几个实例和存储资源，测试完项目就放在一边，忘记销毁这些资源，这些资源一直运行，会持续占用资源，所以哪怕是测试用的临时资源，也要养成用完就清理的习惯，避免不必要的消耗。
刚接触aws亚马逊的时候，我建议可以先从小规模的测试项目入手，先熟悉基本的操作逻辑和核心概念，再逐步往上面跑核心业务，不用一开始就把核心业务直接迁移过去，毕竟不同平台的操作逻辑和习惯有一些差异，熟悉之后再迁移会稳妥很多。另外就是一定要开启核心服务的监控告警，不管是资源使用率过高，还是出现异常的权限操作，都可以及时收到提醒，提前处理问题，不要等出了故障再去排查，那样会增加很多排查的时间成本。