十多年来，「我昨天就该在 AWS 上有个 WordPress」这句话的默认答案就是 Bitnami。它把半个互联网 打包成 AMI、容器和 chart，配置齐全，两次点击就能启动。如果你过去十年碰过基础设施，几乎肯定 启动过其中之一。
那个免费目录已经不再维护。归入 Broadcom 之后，镜像被挪进了不再更新的 legacy 仓库，AMI 也 从 AWS Marketplace 下架了。没有新版本可以启动，也没有人可以开工单。
问题不在他们停止发布的那一天
而在第二天。你的实例照样启动，和昨天一模一样：同样的服务、同样的路径、同样的性能。什么都 没坏——而这正是陷阱所在。真正变化的东西，从外面看不见。
从那一刻起，每一条针对基础系统或其中软件公布的 CVE，都会在你的机器上一直敞着。没有打好补丁 的镜像可以重新启动，没有通知，也没人应答。债务在沉默中累积，直到有人发现它：一次审计、一位 索要漏洞清单的客户，或者更糟的情况。
而手工重建镜像并不简单。Bitnami 的 AMI 不只是「装好的软件包」：它有自己的目录树、启动脚本、 以特定方式串起来的服务，以及多年前做出的一大堆决定——而你的应用把这些都当成了理所当然。
我们做了什么
发布我们真正会维护的替代镜像。这个想法故意做得很「无聊」：同样的架构、同样的路径、同样的 服务，好让迁移不是一个项目，而是一个下午的事。
- 定期打补丁。 镜像的每个修订版都会纳入基础系统与随附软件的安全更新。
- 安全审计。 对每一个发布的镜像做漏洞扫描与 CIS 加固核查，并附上报告。
- 真人支持。 工单直接送到构建镜像的团队手里。
目录会按照迁移团队的需求扩充，每个可用的 AMI 都列在替代对照表里，紧挨着它 所替代的 Bitnami 技术栈。
如何迁移
大多数情况下只要三步，什么都不用重写：
- 从 AWS Marketplace 启动替代镜像，用与原来相同的区域和实例类型。
- 迁移数据：恢复转储，或挂载数据卷。路径与服务与 Bitnami 一致。
- 把弹性 IP 移到新实例上。你的用户毫无察觉。
如果你的技术栈还不在对照表里，写信告诉我们。新的替代镜像按呼声高低排优先级，而知道有人真的 需要它，正是推动这份清单前进的动力。
bitnami迁移awsamis
