最近两年接触了好几个筹备业务出海的开发团队，不少人第一次接触企业出海aws的时候，都容易把这件事想简单。觉得无非就是把国内已经跑顺的代码，打包放到海外的云服务器上，改改配置就能上线。真推进起来才发现，各种之前没预想到的问题接连冒出来，排查半天找不到方向。我整理了几个这段时间碰到最多的共性问题，都是实际踩过坑之后总结的经验。
资源规划的常见误区
很多团队做企业出海aws的第一步，资源规划就容易出问题。最常见的两个误区，一个是照搬国内业务的资源估算逻辑，另一个是只考虑性能不考虑合规。
我之前碰到过一个做面向海外用户工具的团队，一开始按照国内同等用户量估算了计算资源，上线之后才发现，海外用户的请求分布和国内不一样，高峰时段的负载差了快一倍，临时扩容又手忙脚乱，差点影响原定的上线时间。还有的团队反过来，怕资源不够用就提前配置了很多冗余资源，结果大部分时间都处于闲置状态，造成不必要的资源浪费。
比资源估算错误更麻烦的是合规问题。很多人选择部署区域的时候，只看哪个区域离目标用户近、延迟低，就直接选哪个，完全没考虑当地对数据存储和业务合规的要求。我知道的一个团队，把所有欧洲用户的个人数据都存到了欧洲之外的区域，上线之前做合规检查才发现不符合当地要求，不得不整体迁移数据，前前后后花了十多天才搞定，耽误了整个项目的进度。
从这个角度看，做企业出海aws的资源规划，第一步不是算需要多少CPU内存，而是先理清楚目标市场的合规要求，先把符合要求的区域定下来，再根据实际的用户分布估算资源。非核心的不要求实时响应的业务，可以用弹性更高的资源类型，核心业务用稳定的固定资源，这样整体的负载平衡会好很多。
网络连通性的排查思路
做企业出海aws，网络问题是碰到最多的，也是最容易排查错的。很多人碰到访问慢或者链路波动，第一反应就是登录实例查本地负载，看是不是服务本身出了问题，折腾半天发现实例本身一切正常，问题其实出在中间链路上。
比如国内开发团队日常办公，远程访问aws上的测试实例，经常会碰到偶发的延迟升高或者丢包。很多人会先重启实例、重新部署服务，其实大部分时候问题和实例本身没关系，是中间链路的路由波动导致的。这种情况最好的做法是先用工具做分段测试，把链路拆成办公网出口到aws边缘节点、边缘节点到实例两段，分别测延迟和丢包率，很快就能定位问题出在哪，不用瞎折腾服务。
还有一个常见问题，就是很多新团队为了省事儿，把所有服务都部署在同一个可用区。aws的同一个区域下有多个可用区，彼此之间是物理隔离的，单个可用区可能会因为供电、网络等问题出现短时故障。如果所有服务都在一个可用区，出问题就是全业务不可用。我之前碰到过一次，一个创业团队的核心业务全部在一个可用区，那个可用区网络故障了三个小时，他们整整停服三个小时，对业务影响很大。这个问题其实很好避免，只要核心服务做多可用区部署，就算一个可用区出问题，流量也可以切到别的可用区，不会导致全服务中断。
还有静态资源的问题，不少人觉得aws本身有全球骨干网络，延迟肯定够，所以静态资源也直接放在源站，不用做缓存。实际用下来你会发现，就算骨干网络质量好，用户离源站远的话，静态资源的加载延迟还是会比走缓存高很多，还会增加源站的负载。合理把静态资源拆分到缓存节点，能明显降低用户访问延迟，也能减轻源站的压力，这一点是比较关键的。
权限安全容易漏的细节
安全问题不管在哪里做部署都重要，但是做企业出海aws，有几个细节是很多新手容易漏掉的。第一个就是根账号的使用，很多团队一开始只有一两个人开发，图方便就一直用根账号做所有操作，包括日常部署、修改配置。根账号拥有整个账号的所有权限，一旦泄露，对方可以做任何操作，包括删除所有资源、修改所有配置，后果不堪设想。正确的做法是根账号只用来做最基础的账号管理，日常所有操作都用IAM子用户，而且遵循最小权限原则，只给每个用户开通他需要的权限，不要一开就是全权限。
还有就是密钥的管理，很多开发图方便，把访问aws的密钥直接写在代码里，还提交到了代码仓库。不管代码仓库是公开还是私有，这种做法都非常危险。我之前听过一个案例，一个团队的公开代码仓库里漏了密钥，被自动化工具爬走之后，不到半天就出现了大量非授权的资源创建，清理起来花了好几天，还留下了不少安全隐患。现在aws本身有密钥管理服务，也可以用环境变量或者本地配置文件管理密钥，不要把密钥放到代码里，这个习惯一定要养成。
还有很多团队忘了给所有子用户开多因素认证，只要密码泄露，没有多因素认证的话，对方就能直接登录账号。开多因素认证只需要几分钟，但是能把账号被盗的风险降非常多，这个投入产出比很高，很多新手就是嫌麻烦不做，等到出问题才后悔。
容灾备份不能全靠云厂商
很多做企业出海aws的团队，有一个普遍的误解，就是觉得云服务商肯定会帮我做好备份，我自己不用再做了。某种意义上说，这是对云服务责任边界的误解，大部分aws的存储服务，默认不会帮你做自动的跨区域备份，也不会保留所有的历史版本，如果碰到误删除、数据损坏或者区域级故障，你自己没备份的话，数据找不回来的概率非常高。哪怕是云厂商提供的自动备份，也建议你自己导出一份到跨区域的存储里，多一层备份总没错。
我之前碰到过一个团队，开发人员误操作删除了一个存储桶，里面存了好几年的用户上传数据，他们之前从来没做过备份，去找云厂商也恢复不了，最后只能给用户逐个沟通道歉，对业务信任的影响非常大。
还有一个常见的问题，就是很多团队确实做了备份，但是从来没有做过恢复测试。备份配置错了路径、备份文件损坏、备份过程没跑完自己不知道，这种情况都挺常见的。你不做恢复测试，等到真的需要恢复数据的时候，才发现备份用不了，那个时候就来不及了。我的经验是，不管业务多忙，每半年至少做一次全量的恢复演练，确认备份是可用的，恢复流程是顺的，这样出问题的时候才不会慌。
总的来说，企业出海aws需要考虑的约束，比在国内部署常规业务要多很多，很多问题不是技术实现不了，而是前期规划的时候没考虑到，等到出问题再补救，成本就高很多。大部分坑其实都是可以提前避免的，只要多花一点时间在前期规划、合规检查、安全配置上，就能少踩很多没必要的坑。