跨AWS账户共享AMI镜像失败：镜像不可见及WordPress迁移咨询

排查步骤 #

• 确认共享权限的账户ID正确：源账户共享AMI时，必须输入目标账户的12位数字ID，不能用账户名或邮箱。检查ID是否输入错误，有没有多余空格。
• 确保区域一致：AMI是区域专属资源，目标账户要切换到和源AMI完全相同的AWS区域（比如源在ap-southeast-1，目标也得切到这个区域），再去EC2控制台的「私有AMI」列表里查找。
• 检查加密AMI的KMS权限：如果你的Bitnami AMI是加密的（部分Bitnami镜像默认启用加密），源账户还需要给目标账户授予对应KMS密钥的访问权限：
  1. 源账户登录KMS控制台，找到加密AMI用的密钥
  2. 在「密钥策略」里添加目标账户的ID，授予DescribeKey、Decrypt、ReEncrypt*权限
• 刷新控制台或重新登录：有时候AWS控制台会有缓存，刷新页面或者退出后重新登录目标账户，再查看私有AMI列表。

这种方式是可行的，但不是最优解，具体分析：

优点 #

• 操作简单，能完整保留原有Bitnami服务器的所有配置、插件、依赖环境，不需要重新搭建站点基础环境。

缺点 #

• 区域绑定：AMI只能在所属区域直接使用，跨区域迁移需要先复制AMI，增加操作步骤和时间。
• 镜像体积大：会包含服务器上所有冗余数据，占用更多存储资源，迁移成本更高。
• 灵活性差：后续如果想更换服务器规格、优化环境或者拆分站点，不如单独迁移数据灵活。

更优替代方案 #

• Bitnami自带备份恢复：用Bitnami的bnbackup-tool脚本备份站点，在目标账户的新Bitnami WordPress实例上恢复，轻量化且适配性强。
• 手动迁移：导出WordPress数据库（用mysqldump或phpMyAdmin），打包wp-content文件夹，在新实例上导入数据库、替换文件并配置wp-config.php，适合需要自定义环境的场景。
• AWS MGN服务：如果是大规模迁移或有多台服务器，用AWS应用迁移服务自动化完成迁移，稳定性更高。

内容的提问来源于stack exchange，提问作者Dantes