第一次打开阿里云控制台，很多人会被产品数量和名词绕晕。更容易出事的是账号和密钥。AccessKey 一旦被写进代码仓库，就可能被别人拿去使用。本文按操作顺序梳理阿里云配置的主要环节，并用一个小型电商站的案例说明每一步的理由。
一、先确定需求
动手前先回答三个问题：业务跑在哪里，大概有多少访问量，数据存在哪里。答案决定要买哪些产品。个人博客或内部工具一般只需要一台云服务器ECS和一个域名。如果网站要存放订单和用户信息，就要再加上数据库RDS。有图片、视频或文件下载需求的，可以考虑对象存储OSS。
二、先锁住账号，再创建资源
主账号拥有全部权限，日常运维不应该直接使用它。更稳妥的做法是通过RAM访问控制创建子账号，让每个人只拿到完成工作所需的权限。
- 在RAM访问控制中创建子账号。需要登录控制台的人勾选控制台访问。只通过接口或脚本操作的，勾选编程访问即可，两者不必都开。
- 给子账号绑定最小权限策略。比如只负责服务器运维的同事，授予AliyunECSFullAccess就够了。不要图省事直接给AdministratorAccess，一旦子账号泄露，影响范围会大很多。
- 为主账号和高权限子账号开启多因素认证（MFA）。密码被撞库或被钓鱼时，MFA 还能再挡一道。
- AccessKey 不写进代码或公开仓库，统一放在环境变量或凭据管理服务里。迁移代码或分享给同事时，也不要顺手把密钥带出去。
三、创建并配置ECS实例
在ECS控制台创建实例时，有几项参数上线后调整成本较高，购买前要想清楚：
- 地域与可用区：选离目标用户近的地域。面向国内用户的业务，华东或华北的访问延迟通常较低。地域确定后，迁移实例和数据的成本较高，不要随便选。
- 实例规格：入门网站可以从2核4G起步。上线后看CPU和内存监控曲线，长期跑满就升配，长期很空闲就降配，不要凭感觉定规格。
- 镜像：长期维护的生产服务器，建议选Alibaba Cloud Linux或Ubuntu LTS这类长期支持版本，减少系统升级带来的麻烦。
- 系统盘与数据盘：把网站数据和系统分开，数据盘单独挂载。重装系统时，数据盘上的内容可以保留，前提是不对数据盘做格式化。
- 公网带宽：按流量计费还是按固定带宽计费，取决于流量形态。流量忽高忽低的业务适合按流量计费。流量比较平稳、峰值可以预估的，固定带宽更容易算账。
四、配置安全组
安全组相当于实例前面的虚拟防火墙。规则放得太松，服务器会暴露在不必要的入口里。放得太严，业务又访问不进来。建议只开放业务必需的端口：
- 22端口（SSH）：只允许运维人员的固定IP访问，不要对0.0.0.0/0开放。出口IP经常变化的话，可以先通过固定的跳板机或办公网出口登录。
- 80和443端口：对外提供Web服务。没有特殊需要，不要再额外开放其他端口。
- 3306等数据库端口：不对公网开放，只允许同一VPC内的应用服务器访问。
每次新增或修改规则后，从外部网络试连一次，确认只有预期的端口能通。规则写对了，不代表实际效果也对。
五、案例：小型电商站上线
某团队要做一个日均约三千人次访问的服装电商站。最初他们把网站、数据库和部署脚本都放在同一台ECS上，数据库端口直接对公网开放，部署脚本则使用主账号的AccessKey。上线两周后，有人在公开代码仓库里找到了这组AccessKey，随后云上出现了一笔异常的资源创建费用。
团队随后做了三处调整：
- 吊销旧AccessKey。为部署脚本单独创建子账号和密钥，权限限制在ECS和OSS的读写范围内。即使脚本出问题，影响也只限于这两项权限。
- 把RDS从ECS中拆出来。数据库只允许同一VPC内的应用服务器访问，安全组里删除了3306端口的公网规则。
- 配置云监控告警。CPU连续五分钟超过80%，或出网流量突增时，短信和邮件同时通知负责人，避免问题拖到第二天才有人看到。
调整之后，团队在下一次促销活动中没有出现安全事件，服务器负载也保持在可控范围内。这个案例里，服务本身并不难跑起来。难的是权限和网络边界有没有先收紧。这类问题在上线前往往不显眼，出了事才会被看见。
六、常见问题
- 无法通过SSH连接：先检查安全组是否放行22端口，再确认实例已绑定公网IP，最后看本地出口IP是否在白名单里。按这个顺序排查，通常能定位原因。
- 域名访问提示未备案：国内服务器对外提供网站服务，需要先完成ICP备案。备案期间可以先用IP地址做功能测试，页面和接口确认没问题后再切换域名。
- 费用超出预期：在费用中心设置预算告警。定期检查是否有未释放的云盘和快照，这些资源即使闲置也会产生费用。
上线前的检查顺序
按这个顺序过一遍：先确定需求，再收紧账号权限，然后根据业务选实例参数，最后关闭多余端口并开启监控。每一步耗时都不长。跳过任何一步，后面的补救成本通常更高。
