亚马逊云国际账号 国际AWS亚马逊云私有镜像制作

为什么非得自己做私有AMI？别被官方文档绕晕了

先说句大实话：AWS控制台里那个「Create Image」按钮，点下去容易，用起来真不一定靠谱——尤其是当你需要批量部署、合规审计、或把一套跑得飞起的生产环境原样复制到另一套VPC时。官方AMI就像盒装方便面，能吃，但调料包永远少一包；而私有AMI，是你亲手熬了三小时的高汤底料+手擀面+溏心蛋，端出来就是标准答案。

我见过太多人踩坑：有人用默认Ubuntu镜像装完JDK、Nginx、Python一堆东西，直接打AMI，结果下次启动发现/tmp里堆着5G临时日志、~/.ssh/authorized_keys里还留着自己测试用的密钥、甚至MySQL root密码明文写在/etc/my.cnf里……这哪是镜像？这是安全隐患压缩包。

动手前：三问自己，省下两小时排错时间

第一问：你到底想固化什么？

不是所有东西都该打进AMI。操作系统补丁？该打。公司内部证书？该放。但应用数据、数据库文件、用户上传目录？千万别！AMI本质是「系统快照」，不是「数据备份」。建议只固化：基础OS层（含内核参数）、运行时环境（Java/Node/Python版本）、中间件（Nginx配置模板、Redis systemd服务单元）、安全基线（fail2ban规则、UFW策略）、以及统一日志轮转脚本。其余，交给UserData或Ansible。

第二问：实例选型是否匹配目标场景？

别图便宜选t3.micro打AMI——它内存小、磁盘I/O弱，打包过程可能因OOM直接卡死。推荐起步用m5.large（2vCPU+8GB），哪怕最终部署用t3.small，制作镜像时也请「高配起步，低配交付」。另外注意：ARM64（Graviton）和x86_64镜像不互通，选错架构=白干。

第三问：网络与安全组是否已「脱敏」？

启动实例时，务必禁用「Auto-assign Public IP」，安全组只开SSH（22端口）且限制源IP段（比如你的办公IP）。别让一台正在做镜像的机器暴露在公网——曾经有位同事忘了关，凌晨三点被扫出27个暴力破解会话，第二天镜像里直接多了3个可疑用户……

实战四步法：从裸机到可复用AMI

第一步：干净启动 + 基础加固

亚马逊云国际账号 用AWS最新版Amazon Linux 2023或Ubuntu 22.04 LTS启动实例（别用老古董16.04）。登录后立刻执行：

sudo apt update && sudo apt upgrade -y  # Ubuntu
# 或
sudo dnf update -y  # AL2023
sudo systemctl enable --now unattended-upgrades  # Ubuntu自动更新
sudo ufw enable && sudo ufw default deny incoming  # 防火墙兜底
sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

顺手删掉默认用户（ubuntu/ec2-user）的家目录下.bash_history和.viminfo——这些文件会记录你执行过的每条命令，包括带密码的curl、mysql连接串。

第二步：装软件 + 配环境（但别留「指纹」）

装JDK？用tar.gz手动解压到/opt/java，别用apt install openjdk-17-jdk——后者会在/var/log/apt/history.log里记下安装时间、包名、甚至你当时用的代理地址。装Nginx？配置文件里别写server_name your-dev-server.local，换成server_name _;，用反向代理逻辑解耦主机名。

关键技巧：所有配置文件修改后，立即执行sudo chown root:root /etc/nginx/nginx.conf && sudo chmod 644 /etc/nginx/nginx.conf。AMI打包时若发现文件属主是普通用户，AWS可能拒绝创建（尤其涉及systemd服务时）。

第三步：深度清理 + 解绑服务

这是90%的人跳过的致命步骤：

• 清空所有日志：sudo journalctl --vacuum-size=1M && sudo truncate -s 0 /var/log/*.log
• 删除SSH主机密钥：sudo rm -f /etc/ssh/ssh_host_*（否则所有用此AMI启动的实例，SSH指纹全一样！）
• 清空/var/lib/cloud/instances/（Cloud-init缓存，否则新实例启动时会复用旧元数据）
• 停用并禁用cloud-init：sudo systemctl stop cloud-init && sudo systemctl disable cloud-init（防止后续实例重复初始化）

最后执行：sudo aws s3 cp s3://your-bucket/cleanup-script.sh /tmp/ && sudo bash /tmp/cleanup-script.sh——把清理逻辑写成脚本存S3，确保每次流程一致。

第四步：创建AMI + 验证可用性

回到控制台，右键实例 →「Create image」，填名称如prod-web-ubuntu2204-v2.3.1-20240520（含版本号+日期，别用「latest」这种玄学命名）。勾选「No reboot」——AWS会静默快照，比重启更安全。

AMI生成后，立刻启动一台新实例验证：
• 检查SSH能否连通（别用密钥对，试试SSM Session Manager）
• 运行curl -I http://localhost看Nginx是否响应
• 执行java -version确认JDK路径和版本
• sudo ss -tlnp | grep :8080确认应用端口监听正常

验证通过？恭喜，你拥有了第一个真正意义上的「可交付AMI」。

进阶操作：跨区共享、加密与权限锁死

跨区域复制？别直接Copy，先Check再Copy

在us-east-1打好AMI后，想同步到ap-northeast-1？别急着点「Copy AMI」。先去目标区域检查KMS密钥是否存在（若源AMI用了加密EBS卷，目标区必须有同名KMS key）。更稳妥做法：在目标区新建一个未加密AMI，用aws ec2 register-image命令手动注册，指定--block-device-mappings映射加密卷，全程可控。

权限最小化：谁都不能乱删你的AMI

默认情况下，你账户下所有人（包括刚入职的实习生）都能删除AMI。解决方案：用Resource-based Policy锁定。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "ec2:DeregisterImage",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:image/ami-0abcdef1234567890",
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROA...:admin-role",
            "AIDA...:your-personal-id"
          ]
        }
      }
    }
  ]
}

粘贴进AMI的「Modify Image Permissions」→「Add statement」，从此只有指定角色/用户能注销它。

最后送你三条血泪经验

1. 版本号不是摆设：给AMI加语义化版本（v1.2.0），比「web-server-final-2」强一百倍。CI/CD流水线靠它自动拉取，审计时靠它追溯变更。

2. 别信「一次制作，永久有效」：Linux内核每月更新，OpenSSL漏洞半年爆发一次。建议设置Lambda定时任务，每月扫描所有AMI的CVE漏洞（用Amazon Inspector），超期未更新的自动标记为「Deprecated」。

3. 文档比代码重要：在AMI描述栏里写清楚：基于哪个基础镜像、安装了哪些组件及版本、清理脚本S3路径、已知限制（如「不支持IPv6」、「需手动挂载EFS」）。别等三个月后自己重装时，对着控制台发呆。

做完这些，你交出去的就不是一张镜像，而是一份可审计、可回滚、可传承的云基础设施契约。下次老板说「再起十台一样的」，你敲一行aws ec2 run-instances --image-id ami-xxx，然后泡杯茶，看进度条走完——这才是云原生该有的体面。