{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"description":"imaxe.cloud 团队的工程笔记、目录动态与实用指南。","favicon":"https://www.imaxe.cloud/favicon.ico","feed_url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/feed.json","home_page_url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/","icon":"https://www.imaxe.cloud/assets/icon-512.png","items":[{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/arm64-por-defecto_hu_99c180b1a81b7f6a.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/arm64-por-defecto_hu_99c180b1a81b7f6a.webp\" alt=\"处理器硅片的显微细节\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e每个 AMI 都是为某一种特定的 CPU 架构构建的：x86_64（Intel 或 AMD），或 ARM64（aarch64，\n即 AWS Graviton 及同类芯片所用）。不存在「两边通吃」的镜像：它们是不同的二进制。因此，在\n搭建产品目录时，我们必须决定默认走哪一条路。\u003c/p\u003e\n\u003cp\u003e我们衡量了成本、性能、能效、生态成熟度以及市场走向。结论很明确：\u003cstrong\u003e今天，对绝大多数负载来\n说，ARM64 是更好的选择。\u003c/strong\u003e 我们的镜像便是这样构建的。\u003c/p\u003e\n\u003ch2 id=\"为什么-arm64-对多数人更划算\"\u003e为什么 ARM64 对多数人更划算\u003c/h2\u003e\n\u003ch3 id=\"1-更好的性价比\"\u003e1. 更好的性价比\u003c/h3\u003e\n\u003cp\u003e这是决定性的理由。在 Web、API、微服务、容器、数据库和队列等广泛负载上，ARM（Graviton）\n实例始终能提供\u003cstrong\u003e每一欧元更多的性能\u003c/strong\u003e。实践中，迁移到 ARM 通常意味着计算成本节省约\n\u003cstrong\u003e20 % 到 40 %\u003c/strong\u003e。在云成本不断上涨的当下，这个差距大到无法忽视。\u003c/p\u003e\n\u003ch3 id=\"2-更高能效更少耗电\"\u003e2. 更高能效，更少耗电\u003c/h3\u003e\n\u003cp\u003eARM 处理器天生就是围绕低功耗设计的。这意味着每瓦特完成更多工作、更低的能源成本，以及每\n单位算力\u003cstrong\u003e更低的碳足迹\u003c/strong\u003e。如果可持续性是你（或你客户）的目标之一，ARM 站在你这边。\u003c/p\u003e\n\u003ch3 id=\"3-生态早已成熟\"\u003e3. 生态早已成熟\u003c/h3\u003e\n\u003cp\u003e几年前，「有没有 ARM 版本？」还是个合理的问题。今天，绝大多数服务器软件——操作系统、编程\n语言、运行时、数据库、常用容器镜像——都有一流的 ARM64 支持。兼容性已从例外变成了常态。\u003c/p\u003e\n\u003ch3 id=\"4-同样的安全性同样的运维模型\"\u003e4. 同样的安全性，同样的运维模型\u003c/h3\u003e\n\u003cp\u003e换架构并不会改变你的工作方式：配置、加固、cloud-init、你的置备脚本和流水线都照旧。ARM64\n不会要求你在运维或安全姿态上做任何让步。\u003c/p\u003e\n\u003ch2 id=\"一张表看对比\"\u003e一张表看对比\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e标准\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eARM64（Graviton）\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003ex86_64（Intel/AMD）\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e性价比\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e多数负载上更优\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不错，但单位成本更高\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e能效\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e非常高\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e较低\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e软件兼容性\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e如今优秀且广泛\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e最高，普适\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e遗留专有二进制\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e有时没有 ARM 版本\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e完全支持\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e市场走向\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e增长中，具战略意义\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e已成熟稳固\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e典型成本\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e更低：约低 20 % 至 40 %\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e更高\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e对现代负载而言，ARM64 在最要紧的三件事上取胜：成本、能效与未来。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"什么时候-x86_64-依然合理\"\u003e什么时候 x86_64 依然合理\u003c/h2\u003e\n\u003cp\u003e诚实是做好选择的一部分。确实有些场景 x86_64 仍是正确答案，我们不希望任何人被迫做一次让\n自己更难受的迁移：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e只有 x86 编译版本的\u003cstrong\u003e专有软件或二进制文件\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e没有 ARM 构建的\u003cstrong\u003e原生依赖\u003c/strong\u003e（编译型扩展）。\u003c/li\u003e\n\u003cli\u003e绑定在 x86 上的\u003cstrong\u003e遗留工具\u003c/strong\u003e或第三方集成。\u003c/li\u003e\n\u003cli\u003e针对 x86 指令手工优化过的\u003cstrong\u003e高度特化负载\u003c/strong\u003e。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"我们的决定默认-arm64x86_64-按需定制\"\u003e我们的决定：默认 ARM64，x86_64 按需定制\u003c/h2\u003e\n\u003cp\u003e基于以上理由，\u003cstrong\u003e我们的 AMI 默认构建在 ARM64 上。\u003c/strong\u003e 我们相信这对大多数人价值最高：同样的\n工作花更少的钱，用更少的电，并搭上正在为云定调的那条架构路线。\u003c/p\u003e\n\u003cp\u003e但我们也清楚，并非所有负载都合适。所以，\u003cstrong\u003e如果你需要 x86_64，只要开口，我们就为你做一份\n定制镜像\u003c/strong\u003e——同样的配置、同样的加固、同样的品质，只是构建为 x86_64。同一个产品、同一套基\n线，架构由你的场景决定。\u003c/p\u003e\n\u003ch2 id=\"30-秒做出决定\"\u003e30 秒做出决定\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e现代技术栈——Web、API、容器、解释型语言、常见数据库：毫不犹豫选 \u003cstrong\u003eARM64\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e有只跑在 x86 上的专有二进制或依赖？\u003cstrong\u003e跟我们要 x86_64 版本。\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e拿不准？先用 ARM64 试试；如果哪里不合适，我们给你做 x86_64，就这么简单。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e你们的 AMI 是 ARM64 还是 x86_64？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e默认构建在 ARM64（Graviton）上，因为对多数负载来说它的性价比最高。如果你需要 x86_64，我\n们会为你定制一份，配置与品质完全一致。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e用 ARM64 需要改我的应用吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e多数情况下不需要。解释型语言与现代软件在 ARM 上无需改动即可运行。只有专有二进制或没有\nARM 版本的原生依赖才会带来摩擦；那种情况下我们提供 x86_64 版本。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e怎么申请定制的 x86_64 镜像？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e开口即可。我们从同样的基线与同样的加固出发，把镜像构建为 x86_64，你拿到的是同一个产品，\n只是换成了你需要的架构。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e用 ARM64 真的能省钱吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e对合适的负载来说，计算成本节省 20 % 到 40 % 很常见，还能少耗电。要确认你自己的情况，最好\n的办法就是把负载跑起来对比一下。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们押注 ARM64，因为我们相信这对你的账单、你的性能和这颗星球都更好。而\n如果你需要 x86_64，只要开口，我们就为你定制一份。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-08-04T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E9%BB%98%E8%AE%A4arm64/","image":"https://www.imaxe.cloud/blog-covers/arm64-por-defecto_hu_99c180b1a81b7f6a.webp","language":"zh-Hans","summary":"设计镜像时，我们必须选定一个默认架构。我们仔细思考、实测比较，最终选择了 ARM64。这里说明为什么我们认为它对多数人是更好的选择——以及为什么如果你需要 x86_64，只要开口就行。","tags":["动态","arm64","graviton","x86_64","架构","定制"],"title":"默认 ARM64：我们为什么把 AMI 构建在 Graviton 上","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E9%BB%98%E8%AE%A4arm64/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/optimizar-tamano-arranque-ami_hu_69b1788d3fbcbc6c.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/optimizar-tamano-arranque-ami_hu_69b1788d3fbcbc6c.webp\" alt=\"黑色背景上的怀表式秒表\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e镜像的体积与启动时间看似技术细节，实则关系到业务真正在意的三件事：\u003cstrong\u003e自动伸缩的速度\u003c/strong\u003e——你多久\n能接住一个流量高峰、\u003cstrong\u003e成本\u003c/strong\u003e——存储以及等待启动时白白空转的算力，还有\u003cstrong\u003e安全\u003c/strong\u003e：软件越少，攻击面\n越小。\u003c/p\u003e\n\u003cp\u003e一份又轻又快的镜像，几乎总是更好的镜像。\u003c/p\u003e\n\u003ch2 id=\"给镜像瘦身少即是多\"\u003e给镜像瘦身：少即是多\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e从最小化基线出发\u003c/strong\u003e：用操作系统的 \u003cem\u003eminimal\u003c/em\u003e 变体，而不是完整安装。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e只装必需的东西\u003c/strong\u003e：每多一个软件包，都是重量、维护负担与攻击面。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e构建后做清理\u003c/strong\u003e：封存前删掉软件包缓存（\u003ccode\u003ednf clean all\u003c/code\u003e、\u003ccode\u003eapt-get clean\u003c/code\u003e）、日志、文档与\n临时文件。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e移除构建工具\u003c/strong\u003e：如果编译过东西，把编译器与开发依赖清出去。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e复核卷的大小\u003c/strong\u003e：软件只占 8 GB，就别拖着一块 100 GB 的盘走。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"加快启动\"\u003e加快启动\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e烘焙，而不是开机才装\u003c/strong\u003e：你放进 user-data 的每一样安装，都是启动时间；把它挪进镜像。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e开机时服务保持最少\u003c/strong\u003e：首次启动用不到的，统统关掉。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e预加载依赖\u003c/strong\u003e：驱动、运行时与基础容器如果已经就位，就省掉了首次下载。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e优化 cloud-init\u003c/strong\u003e：短小且幂等的 user-data 启动更快。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e快照与预热\u003c/strong\u003e：善用云平台的选项，让卷更快「灌满」数据。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"影响用数字说话\"\u003e影响，用数字说话\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e手段\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e对自动伸缩的影响\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e对成本与安全的影响\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e镜像更小\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e复制与启动更快\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e快照成本更低，CVE 更少\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e启动更快\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e更早接住流量高峰\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e更少「付了钱却没服务」的算力\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e软件包更少\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e需要加载与初始化的更少\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e攻击面缩小\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e优化镜像，同时改善性能、成本与安全。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"别刹过头\"\u003e别刹过头\u003c/h2\u003e\n\u003cp\u003e优化不是截肢。删得太狠，可能弄断某些不起眼的依赖，或让排障变得困难。正确的纪律是：把体积与\n启动时间纳入流水线来度量，有判断地裁剪，始终在预发环境验证，并记录你删掉了什么、为什么删。\n把这些指标当作镜像的质量信号，而不是执念。\u003c/p\u003e\n\u003ch2 id=\"优化检查清单\"\u003e优化检查清单\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e最小化的操作系统基线。\u003c/li\u003e\n\u003cli\u003e只保留必不可少的软件包。\u003c/li\u003e\n\u003cli\u003e封存前清理缓存、日志与临时文件。\u003c/li\u003e\n\u003cli\u003e最终镜像中不留编译工具。\u003c/li\u003e\n\u003cli\u003euser-data 保持短小；重活都烘焙进镜像。\u003c/li\u003e\n\u003cli\u003e卷大小贴合实际用量。\u003c/li\u003e\n\u003cli\u003e流水线中跟踪体积与启动指标。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e优化镜像能把启动加速多少？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e取决于起点，但把安装动作从 user-data 挪进镜像、再削减开机服务，通常能显著缩短启动时间，这会\n直接提升自动伸缩的响应速度。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e镜像更小就更安全吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e总体上是：装的软件越少，潜在漏洞越少，攻击面也更小，而且更容易审计。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e用最小化操作系统值得吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e对多数服务器负载来说值得：启动更快、占用更小、也更安全。只是别精简到妨碍排障，或弄断你确实\n需要的依赖。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们用心让镜像轻巧、启动迅速、易于维护。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-31T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E4%BC%98%E5%8C%96ami%E4%BD%93%E7%A7%AF%E4%B8%8E%E5%90%AF%E5%8A%A8%E6%97%B6%E9%97%B4/","image":"https://www.imaxe.cloud/blog-covers/optimizar-tamano-arranque-ami_hu_69b1788d3fbcbc6c.webp","language":"zh-Hans","summary":"臃肿的镜像启动慢、存储贵，还会撑大攻击面。给 AMI 瘦身、让它启动更快，能一举改善自动伸缩、账单与安全。方法如下。","tags":["运维","性能","启动","成本","自动伸缩","最小化镜像"],"title":"为你的 AMI 瘦身，并缩短启动时间","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E4%BC%98%E5%8C%96ami%E4%BD%93%E7%A7%AF%E4%B8%8E%E5%90%AF%E5%8A%A8%E6%97%B6%E9%97%B4/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/imagenes-ia-gpu-2026_hu_57244b43363ee40d.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/imagenes-ia-gpu-2026_hu_57244b43363ee40d.webp\" alt=\"带散热片与风扇的显卡\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e随着「AI 上生产」成为 2026 年的大主题，越来越多团队启动 GPU 实例来训练模型、跑推理。但 GPU\n不会独自工作：它需要一套非常具体的软件栈——\u003cstrong\u003eNVIDIA 驱动、CUDA、cuDNN、各类框架\u003c/strong\u003e——而这些\n版本之间必须彼此对得上。每台实例都手工准备这一切，既慢又脆弱。\u003c/p\u003e\n\u003cp\u003e这正是\u003cstrong\u003eGPU 就绪镜像\u003c/strong\u003e的价值所在：它把那套验证过的软件栈一次性封装好，开机即可开工。\u003c/p\u003e\n\u003ch2 id=\"一份-ai-用的-ami-该带什么\"\u003e一份 AI 用的 AMI 该带什么\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e与目标 GPU 相匹配的 \u003cstrong\u003eNVIDIA 驱动\u003c/strong\u003e，例如加速实例家族所用的那些。\u003c/li\u003e\n\u003cli\u003e与你将要使用的框架版本对齐的 \u003cstrong\u003eCUDA 与 cuDNN\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e框架\u003c/strong\u003e，如 PyTorch 或 TensorFlow；更好的做法是装上 \u003cstrong\u003eNVIDIA Container Toolkit\u003c/strong\u003e，把它们\n跑在容器里。\u003c/li\u003e\n\u003cli\u003e预装好的 \u003cstrong\u003eMLOps 工具\u003c/strong\u003e与 GPU 监控组件，例如 DCGM。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e启动优化\u003c/strong\u003e：预先加载驱动，避免每次启动都白白耗掉几分钟——以及几分钟的 GPU 费用。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"自己构建还是用现成镜像\"\u003e自己构建，还是用现成镜像\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e选项\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e优势\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e代价\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e官方 GPU 镜像（NVIDIA GPU-Optimized、Deep Learning）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e软件栈经过验证并有人维护\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e对版本的掌控较少\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e自定义镜像\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e完全掌控版本与加固\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e维护落在你身上\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e基础 AMI 上跑 GPU 容器\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e可移植、可复现\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e需要 toolkit 和带驱动的节点\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e按你愿意承担多少版本掌控与维护负担来选择。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"成本说了算gpu-很贵\"\u003e成本说了算：GPU 很贵\u003c/h2\u003e\n\u003cp\u003eGPU 时间是你 AI 账单上最贵的资源，而压低 \u003cstrong\u003eGPU 空转\u003c/strong\u003e正是 2026 年的优先事项之一。镜像会直接\n影响这一点：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e快速启动\u003c/strong\u003e：驱动与依赖都已就位的镜像，避免了那几分钟「付了钱却在干等」的 GPU。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGPU 容器\u003c/strong\u003e：把模型环境打包好，在任何带驱动的节点上都能瞬间复现。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e边缘推理\u003c/strong\u003e：用轻量镜像把模型带到数据近旁，压低延迟与成本。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e弹性伸缩与竞价实例\u003c/strong\u003e：把现成镜像与竞价实例结合，为可容忍中断的负载省钱。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"最佳实践\"\u003e最佳实践\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e固定并记录驱动、CUDA 与框架的\u003cstrong\u003e版本\u003c/strong\u003e：这套兼容关系很脆弱。\u003c/li\u003e\n\u003cli\u003e面对驱动与操作系统的安全补丁，保持镜像\u003cstrong\u003e及时更新\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e把\u003cstrong\u003e平台层\u003c/strong\u003e（驱动、toolkit）与\u003cstrong\u003e模型层\u003c/strong\u003e（容器）分开，好让迭代跑得快。\u003c/li\u003e\n\u003cli\u003e度量\u003cstrong\u003e每次推理的成本\u003c/strong\u003e，据此优化镜像与实例规格。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e该用官方的 Deep Learning AMI，还是自己造？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e官方 GPU 镜像能省下大量时间，并且自带验证过的软件栈。如果你需要特定版本、特定加固或严格合规，\n那就自己造一份。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e为什么 GPU 上的快速启动这么要紧？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e因为 GPU 是最贵的资源：GPU 实例花在装驱动上的每一分钟，都是付了钱却没产出。把东西预装好的\n镜像能削掉这份浪费。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGPU 上做 AI，用容器还是直接安装？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e配合 NVIDIA Container Toolkit 的 GPU 容器带来可复现与可移植，是推荐做法。它要求节点上装有\n驱动，而这正好由一份好的基础 AMI 解决。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们密切跟踪 AI 负载的演进，好让我们的镜像帮你免去驱动地狱与漫长启动。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-28T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ai%E4%B8%8Egpu%E9%95%9C%E5%83%8F2026/","image":"https://www.imaxe.cloud/blog-covers/imagenes-ia-gpu-2026_hu_57244b43363ee40d.webp","language":"zh-Hans","summary":"手工搭一套跑在 GPU 上的 AI 环境，就是一场驱动、CUDA 版本与框架互不兼容的狂欢。一份准备妥当的 GPU 镜像，能省下你好几天的煎熬。2026 年一份 AI 用的 AMI 该带什么，我们来说清楚。","tags":["动态","ai","gpu","nvidia","cuda","mlops"],"title":"2026 年面向 AI 与 GPU 的机器镜像：GPU 入场后，什么变了","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ai%E4%B8%8Egpu%E9%95%9C%E5%83%8F2026/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/arm-graviton-ahorro_hu_564873198e07c9a3.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/arm-graviton-ahorro_hu_564873198e07c9a3.webp\" alt=\"安装在主板上的 Exynos 芯片\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e以 \u003cstrong\u003eAWS Graviton\u003c/strong\u003e 为代表的 ARM 处理器，已经成为生产负载的一流选择。它的主张简单而有力：\n对许多负载而言，\u003cstrong\u003e性价比优于传统 x86 方案\u003c/strong\u003e，同时功耗更低。\u003c/p\u003e\n\u003cp\u003e在云成本持续上涨的大背景下——这正是 2026 年的一大趋势——迁移到 ARM 是 FinOps 策略中最有效\n的省钱杠杆之一。\u003c/p\u003e\n\u003ch2 id=\"到底能省多少\"\u003e到底能省多少\u003c/h2\u003e\n\u003cp\u003e具体数字因负载而异，但业界一致反映，迁移到 Graviton 能带来可观的节省：对合适的负载而言，\n计算成本大约下降 \u003cstrong\u003e20 % 到 40 %\u003c/strong\u003e，这得益于更优的每 vCPU 价格与更高的能效。这不是魔法：\n你必须用真实负载验证，但潜力很大，而且这往往是白白留在桌上的钱。\u003c/p\u003e\n\u003ch2 id=\"哪些迁移顺利哪些需要留心\"\u003e哪些迁移顺利，哪些需要留心\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e迁移顺利\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e需要验证\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e解释型语言：Python、Node、Java、Go\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e只为 x86 编译的二进制文件\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e使用多架构镜像的容器\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e没有 ARM 构建的原生依赖\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eWeb、API 与微服务\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e没有 ARM 版本的专有软件\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e常见数据库与缓存\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e特定的驱动或扩展\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e大多数现代负载迁移起来毫无戏剧性；留意原生依赖即可。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"多架构镜像的角色\"\u003e多架构镜像的角色\u003c/h2\u003e\n\u003cp\u003e干净迁移的关键，是把镜像同时构建为 \u003cstrong\u003ex86_64 与 arm64 两种架构\u003c/strong\u003e。在容器世界里，\u003cem\u003emulti-arch\u003c/em\u003e\n镜像让同一个 tag 在两种架构上都能跑。在 AMI 世界里，值得把流水线——Packer 或 EC2 Image\nBuilder——准备好，在产出 x86 镜像之外同时产出 arm64 版本，并复用同一套 provisioner。\u003c/p\u003e\n\u003ch2 id=\"五步迁移计划\"\u003e五步迁移计划\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e盘点\u003c/strong\u003e你的负载，找出可能没有 ARM 版本的依赖。\u003c/li\u003e\n\u003cli\u003e在流水线中与 x86 并行\u003cstrong\u003e构建 arm64 镜像\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e在预发环境\u003cstrong\u003e测试\u003c/strong\u003e：性能、兼容性与功能结果。\u003c/li\u003e\n\u003cli\u003e用金丝雀或蓝绿方式\u003cstrong\u003e分阶段迁移\u003c/strong\u003e，实测真实成本与性能。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e优化\u003c/strong\u003e：让 Graviton 实例类型贴合负载画像。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"azure-与-gcp-上也有-arm\"\u003eAzure 与 GCP 上也有 ARM\u003c/h2\u003e\n\u003cp\u003e这股趋势并非 AWS 独有。Azure 提供基于 ARM 的机型——Cobalt 及合作伙伴机型——Google Cloud 也\n有 Axion、Tau T2A 等 ARM 实例。只要你把镜像当作代码来设计并面向多架构，就获得了在任何云上\n追逐最佳性价比的自由。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e用 Graviton 到底能省多少？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e取决于你的负载，但对合适的负载来说，计算成本节省 20 % 到 40 % 很常见。唯一确凿的办法，是\n把真实负载跑在 ARM 实例上做对比。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e我必须为 ARM 重写应用吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e很少需要。解释型语言与多数现代软件在 ARM 上无需改动即可运行。真正的工作量出现在只为 x86\n编译的二进制文件，或者没有 ARM 构建的原生依赖上。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e能不能让镜像同时支持 x86 与 ARM？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e可以：使用多架构容器镜像，并让 AMI 流水线同时产出两种变体。这样就能循序渐进地迁移，不会\n把自己卡住。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们设计镜像时会充分利用每种架构的长处，帮你优化成本与性能。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-24T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/arm-graviton%E6%88%90%E6%9C%AC%E8%8A%82%E7%9C%81/","image":"https://www.imaxe.cloud/blog-covers/arm-graviton-ahorro_hu_564873198e07c9a3.webp","language":"zh-Hans","summary":"ARM 早已不只是手机上的事：如今它撑起了云的一大块，性价比高到难以忽视。把镜像迁到 Graviton，账单往往能明显下降。我们来讲讲怎么做，以及要注意什么。","tags":["指南","arm","graviton","arm64","finops","多架构"],"title":"ARM 与 Graviton：迁移镜像，压低你的云账单","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/arm-graviton%E6%88%90%E6%9C%AC%E8%8A%82%E7%9C%81/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/migrar-ami-sin-downtime_hu_1ed2f0ccb833f256.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/migrar-ami-sin-downtime_hu_1ed2f0ccb833f256.webp\" alt=\"铁轨旁的道岔扳把\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e更换实例所用的 AMI，相当于在服务照常运行的同时更换它的地基。做得不好意味着中断；做得好，用户\n几乎察觉不到。好消息是：业界已有成熟的模式，能让这次迁移既安全又可逆。\u003c/p\u003e\n\u003cp\u003e共同的基础是：不去改动运行中的实例，而是\u003cstrong\u003e用新 AMI 启动新实例\u003c/strong\u003e，再有控制地转移流量。\u003c/p\u003e\n\u003ch2 id=\"迁移之前先把地基铺好\"\u003e迁移之前：先把地基铺好\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e在与生产完全一致的预发环境里\u003cstrong\u003e测试新 AMI\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e可靠的健康检查\u003c/strong\u003e：定义那些能真正确认新实例健康的检查项。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e回滚方案\u003c/strong\u003e：把上一个版本和回退步骤都准备好。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e可观测性\u003c/strong\u003e：备好指标与告警，以便第一时间发现退化。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"零停机的迁移策略\"\u003e零停机的迁移策略\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e策略\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e工作方式\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e适合场景\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e滚动更新\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e分批、逐步替换实例\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e处于 Auto Scaling Group 中的服务\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e蓝绿部署\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e起一套新环境，然后一次性切换流量\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e需要瞬时回滚的迁移\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e金丝雀发布\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e把一小部分流量导向新版本\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e以低风险在生产中验证\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e三种在不中断服务的前提下更换 AMI 的模式。\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"滚动更新\"\u003e滚动更新\u003c/h3\u003e\n\u003cp\u003e你把 Launch Template 更新为新 AMI，Auto Scaling Group 就会分批替换实例：先起新的，等它们\n通过健康检查，再撤下旧的。做法简单，也不需要额外基础设施，只是会有一段时间两个版本并存。\u003c/p\u003e\n\u003ch3 id=\"蓝绿部署\"\u003e蓝绿部署\u003c/h3\u003e\n\u003cp\u003e你用新 AMI 起一套并行环境（\u003cem\u003egreen\u003c/em\u003e），同时现有环境（\u003cem\u003eblue\u003c/em\u003e）继续对外服务。等 green 验证通过，\n就在负载均衡器或 DNS 层把流量切过去。一旦出问题，几秒钟就能切回 blue。这是回滚最快的模式，\n代价是要临时占用双倍资源。\u003c/p\u003e\n\u003ch3 id=\"金丝雀发布\"\u003e金丝雀发布\u003c/h3\u003e\n\u003cp\u003e你把一小部分流量导向使用新 AMI 的实例，然后观察。如果指标稳住，就逐步把比例提高到 100 %。\n这能把意外问题的影响半径压到最小。\u003c/p\u003e\n\u003ch2 id=\"迁移之后\"\u003e迁移之后\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e在宣布迁移成功之前，先盯一段合理时间的指标与日志。\u003c/li\u003e\n\u003cli\u003e把旧 AMI 标记为\u003cstrong\u003e弃用\u003c/strong\u003e，免得被误启动。\u003c/li\u003e\n\u003cli\u003e记录已上线的版本，以及这次变更的原因。\u003c/li\u003e\n\u003cli\u003e不要立刻删掉旧镜像：留着，以备回滚之需。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e要做到零停机，哪种策略最好？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e蓝绿部署回滚最快；滚动更新更简单也更省钱；金丝雀通过在生产中验证把风险压到最低。选哪种，取决\n于你的风险承受度与基础设施预算。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e迁移是不是必须把基础设施翻倍？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e只有蓝绿部署需要，而且只是暂时的。用滚动更新或金丝雀，你复用同一个组、逐步替换实例，不必复制\n整个环境。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e怎样确保我能退回去？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e保留上一个 AMI 及其 Launch Template，定义可靠的健康检查，并在开始迁移之前把回滚流程演练一遍。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们为镜像做版本管理，让版本之间的迁移既可预期又可逆。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-21T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E9%9B%B6%E5%81%9C%E6%9C%BA%E8%BF%81%E7%A7%BB/","image":"https://www.imaxe.cloud/blog-covers/migrar-ami-sin-downtime_hu_1ed2f0ccb833f256.webp","language":"zh-Hans","summary":"更新支撑服务的那份镜像，不必意味着一个不眠之夜或一张维护页。选对策略，你就能零停机切换 AMI，而且退路始终触手可及。","tags":["运维","蓝绿部署","滚动更新","金丝雀","自动伸缩","部署"],"title":"如何在不中断服务的情况下迁移到新的 AMI","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E9%9B%B6%E5%81%9C%E6%9C%BA%E8%BF%81%E7%A7%BB/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/byol-vs-pago-por-hora_hu_5e9a1e84b468f504.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/byol-vs-pago-por-hora_hu_5e9a1e84b468f504.webp\" alt=\"桌上的欧元硬币与纸币\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e当你从一份 AMI 启动实例时，除了计算成本——也就是 EC2 实例本身——还可能有一笔与镜像中\u003cstrong\u003e软件\u003c/strong\u003e\n相关的费用。这笔费用主要分为三种模式：免费（开源）、随实例按小时计费，以及 BYOL（自带许可）。\u003c/p\u003e\n\u003cp\u003e弄清其中的差别，能避免账单上的意外，也能避免许可合规上的麻烦。\u003c/p\u003e\n\u003ch2 id=\"三种模式一目了然\"\u003e三种模式，一目了然\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e模式\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e你怎么付费\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e主要优势\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e免费或开源\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e只付实例的钱\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e成本最低，无软件许可费\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e按小时计费（PAYG）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e软件按使用小时数计费\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e无承诺：随时扩容、随时关停\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eBYOL\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e复用你已有的许可\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e盘活既有投入，保留掌控权\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e机器镜像中软件成本的三种模式。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"按小时计费灵活性优先\"\u003e按小时计费：灵活性优先\u003c/h2\u003e\n\u003cp\u003e在按用量付费的模式下，软件成本会叠加到实例成本上，按使用的小时或秒计费。当你的负载多变或\n难以预测时，这非常合适：没有前期承诺，需要时扩容，关机就不再付费。代价是：如果使用强度大\n且持续，长期看可能比摊销自有许可更贵。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e优点\u003c/strong\u003e：零前期投入、完全弹性，维护与支持通常已包含在内。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e缺点\u003c/strong\u003e：按小时的费用如果 7×24 累加起来，可能超过一份已摊销的许可。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"byol把已有的资产用起来\"\u003eBYOL：把已有的资产用起来\u003c/h2\u003e\n\u003cp\u003e有了 \u003cstrong\u003eBring Your Own License\u003c/strong\u003e，你可以把已经拥有的许可——比如来自企业协议的——用在云上的\n镜像里。如果你此前已在许可上投入过，这能省钱，但也伴随责任：你必须遵守厂商条款、留意许可\n向云端的可迁移性，并自行管理合规。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e优点\u003c/strong\u003e：盘活既有投入，持续使用时可能更省，与原有供应商保持连续性。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e缺点\u003c/strong\u003e：合规复杂，存在厂商审计风险，管理成本落在你身上。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"需要留意的隐藏成本\"\u003e需要留意的隐藏成本\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e存储\u003c/strong\u003e：镜像的 EBS 快照是要花钱的，哪怕软件本身免费。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e数据传输\u003c/strong\u003e：跨区域或流向互联网的流量。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e支持\u003c/strong\u003e：是含在按小时价格里，还是另行收费？\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e实例规格\u003c/strong\u003e：软件可能要求更大的实例，从而推高计算成本。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e许可可迁移性\u003c/strong\u003e：有些 BYOL 许可要求专用租户，费用更高。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"该怎么决定\"\u003e该怎么决定\u003c/h2\u003e\n\u003cp\u003e实用法则：对\u003cstrong\u003e多变或短周期\u003c/strong\u003e的负载，按小时计费通常凭灵活性胜出。对\u003cstrong\u003e7×24 持续运行、生命周期\n长\u003c/strong\u003e的负载，摊销许可或预留容量往往能降低总成本。用你真实的使用画像——而不是最坏情况——来算\n账，别忘了把隐藏成本算进去。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eBYOL 和按小时计费，哪个更便宜？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e取决于你的用量。负载多变或断续时，按小时计费更划算；如果你已有需要摊销的许可，且要 7×24\n持续运行，BYOL 可能更合适。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAMI 里的软件免费，就意味着零成本吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e并非如此：哪怕软件是开源的，你仍要为实例、快照存储和数据传输付费。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eBYOL 有哪些法律风险？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你必须遵守厂商关于云端使用与许可可迁移性的条款。一旦违规，可能在审计时暴露，因此值得把条款\n仔细读一遍。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们会帮你理清每一份镜像的成本模式，让你在数字清清楚楚的前提下做选择。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-17T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/byol%E4%B8%8E%E6%8C%89%E5%B0%8F%E6%97%B6%E8%AE%A1%E8%B4%B9/","image":"https://www.imaxe.cloud/blog-covers/byol-vs-pago-por-hora_hu_5e9a1e84b468f504.webp","language":"zh-Hans","summary":"用镜像时是自带许可，还是按小时付费？答案会改变你的账单、你的灵活度，以及你的法律义务。这份指南帮你选出真正适合自己的模式。","tags":["指南","byol","许可","成本","marketplace","finops"],"title":"BYOL 与按小时计费：看懂你 AMI 的许可与成本","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/byol%E4%B8%8E%E6%8C%89%E5%B0%8F%E6%97%B6%E8%AE%A1%E8%B4%B9/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/gestion-secretos-ami_hu_ed7ffbea445a9c3c.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/gestion-secretos-ami_hu_ed7ffbea445a9c3c.webp\" alt=\"银行金库的装甲门\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e当你把一份凭据嵌进 AMI，它就会随着镜像的每一次复制而扩散、被刻进快照，并可能出现在你从未\n设想过的账户或区域里。只要有人对镜像有读权限，就能把它抠出来。而由于镜像是按版本保存的，\n这个机密可能在你以为早就轮换掉之后，依然活得好好的。\u003c/p\u003e\n\u003cp\u003e黄金法则：\u003cstrong\u003e镜像定义机器；机密在运行时交付\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2 id=\"机密该住在哪里\"\u003e机密该住在哪里\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e服务\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e云或环境\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e适合场景\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAWS Secrets Manager\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAWS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e可轮换的凭据，原生集成\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAWS SSM Parameter Store\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAWS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e简单参数与机密，成本低\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eHashiCorp Vault\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e多云\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e动态机密与精细控制\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAzure Key Vault / Google Secret Manager\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAzure / GCP\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e各云的原生对应物\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e把机密放进专用的管理器，绝不要放进镜像，也不要以明文放进 user-data。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"正确的模式用身份而不是密码\"\u003e正确的模式：用身份，而不是密码\u003c/h2\u003e\n\u003cp\u003e让实例访问资源，最安全的方式不是给它一个密码，而是给它一个\u003cstrong\u003e身份\u003c/strong\u003e。在 AWS 上，绑定到实例\n的 \u003cstrong\u003eIAM 角色\u003c/strong\u003e能让它取得临时且自动轮换的凭据，而不必让任何密钥随镜像旅行。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e实例 IAM 角色\u003c/strong\u003e：实例扮演某个角色并获得临时凭据。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKubernetes 上的 IRSA\u003c/strong\u003e：按 Pod 授予身份，节点上不留共享密钥。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVault 的动态机密\u003c/strong\u003e：按需生成的短生命周期凭据。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e运行时注入\u003c/strong\u003e：应用在启动时从管理器读取机密，而不是从烘焙进去的文件里读。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"保护元数据imdsv2\"\u003e保护元数据：IMDSv2\u003c/h2\u003e\n\u003cp\u003e角色的临时凭据是通过实例元数据服务获取的。利用 SSRF 漏洞的攻击者可能试图窃取它们。\n\u003cstrong\u003eIMDSv2\u003c/strong\u003e 要求会话令牌，能缓解这一类攻击：在你的启动配置中把它设为强制。\u003c/p\u003e\n\u003ch2 id=\"卫生不要在镜像里留下痕迹\"\u003e卫生：不要在镜像里留下痕迹\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e封存 AMI 之前，\u003cstrong\u003e删除\u003c/strong\u003e shell 历史、含凭据的日志、临时 SSH 密钥，以及带机密的配置文件。\u003c/li\u003e\n\u003cli\u003e用 gitleaks、trufflehog 之类适配文件系统的工具扫描镜像中的\u003cstrong\u003e机密\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e不要在 \u003ccode\u003e~/.ssh/authorized_keys\u003c/code\u003e 里留下多余的\u003cstrong\u003e已授权密钥\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e避免发布带机密的\u003cstrong\u003e公开 AMI\u003c/strong\u003e：如果你要发布，务必确认没有任何东西外泄。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"快速检查清单\"\u003e快速检查清单\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e镜像中零烘焙机密。\u003c/li\u003e\n\u003cli\u003e使用机密管理器，配合角色或联合身份。\u003c/li\u003e\n\u003cli\u003eIMDSv2 设为强制。\u003c/li\u003e\n\u003cli\u003e流水线中做机密扫描。\u003c/li\u003e\n\u003cli\u003e封存前清理痕迹。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e如果我的应用在启动时就需要机密怎么办？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e让它在运行时用实例身份从机密管理器读取。这样机密永远不会随镜像旅行，也能在不重建的情况下\n轮换。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e用 user-data 传机密安全吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e明文不安全：user-data 可从元数据读到。最多用它来指明该从管理器取哪一份机密，同时用 IMDSv2\n保护元数据。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e怎么发现一份镜像里是否已经烘焙了机密？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e用机密检测工具扫描它的文件系统，并在使用前逐一检查配置文件、历史记录与已授权密钥。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们构建的镜像不含任何凭据，并且从设计上就便于与机密管理器和联合身份集成。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-14T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E5%AF%86%E9%92%A5%E7%AE%A1%E7%90%86/","image":"https://www.imaxe.cloud/blog-covers/gestion-secretos-ami_hu_ed7ffbea445a9c3c.webp","language":"zh-Hans","summary":"镜像里的一个密码，就是一场等着发生的泄露：它会被复制、被分享，并永远留在某个快照里。规则很简单，也不容例外：机密永远不进镜像。以下是正确的做法。","tags":["安全","机密","vault","iam","imdsv2","secrets manager"],"title":"机密管理：绝不要把凭据烘焙进 AMI","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E5%AF%86%E9%92%A5%E7%AE%A1%E7%90%86/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/sbom-imagenes-de-maquina_hu_ffc36a1f6a89fff9.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/sbom-imagenes-de-maquina_hu_ffc36a1f6a89fff9.webp\" alt=\"仓库货架上码放整齐、已登记入册的托盘\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSBOM\u003c/strong\u003e（\u003cem\u003eSoftware Bill of Materials\u003c/em\u003e，软件物料清单）就是你软件的「配料表」：一份镜像里所有\n软件包、库、版本与依赖的完整清单。就像营养成分表一样，它明明白白告诉你里面装了什么。\u003c/p\u003e\n\u003cp\u003e它的价值会在关键漏洞爆发的那天显现：你不必手工翻查几十份镜像，只要查一下 SBOM，几秒内就知道\n哪些镜像含有受影响的组件、版本是多少。\u003c/p\u003e\n\u003ch2 id=\"它为何对你的镜像重要\"\u003e它为何对你的镜像重要\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e快速响应 CVE\u003c/strong\u003e：立刻判断某个新漏洞是否波及你。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e供应链安全\u003c/strong\u003e：你清楚每个组件的来路。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e合规\u003c/strong\u003e：越来越多的框架与客户把它当作证据来索要。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e透明度\u003c/strong\u003e：如果你对外发布镜像，SBOM 会让使用者更放心。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"标准格式\"\u003e标准格式\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e格式\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e出处\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e说明\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSPDX\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLinux 基金会 / ISO\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eISO 标准，在合规场景中广泛使用\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCycloneDX\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eOWASP\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e面向安全，做漏洞分析时信息更丰富\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e两种占主导地位的 SBOM 格式；很多工具都能同时导出。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"一步步为镜像生成-sbom\"\u003e一步步为镜像生成 SBOM\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e选工具\u003c/strong\u003e：Anchore 的 Syft 是为镜像与文件系统生成 SBOM 的事实标准；云上也有原生方案。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e在流水线里生成\u003c/strong\u003e：构建 AMI 的过程中扫描文件系统并产出 SBOM，例如同时输出 CycloneDX 与\nSPDX。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e分析漏洞\u003c/strong\u003e：把 SBOM 交给 Grype 或 Trivy，与 CVE 数据库做比对。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e签名并归档\u003c/strong\u003e：给 SBOM 签名——比如用 cosign——并作为与该镜像版本绑定的产物保存下来。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e需要时查询\u003c/strong\u003e：新的 CVE 出现时，翻查归档的 SBOM 就能确定影响范围。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"2026-年的监管背景\"\u003e2026 年的监管背景\u003c/h2\u003e\n\u003cp\u003e多年来，SBOM 作为供应链安全的良好实践分量越来越重。不过监管图景是有层次的：在美国，行政部门\n于 2026 年把沿袭下来的软件证明要求改为更偏向基于风险的路线；而在欧盟，《网络韧性法案》一类的\n规则则在推动软件透明度与组件清单。实用的结论是：无论监管如何摇摆，拥有 SBOM 都是一种防御上与\n商业上的优势，值得采用。\u003c/p\u003e\n\u003ch2 id=\"最佳实践\"\u003e最佳实践\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e每次构建都\u003cstrong\u003e自动生成\u003c/strong\u003e SBOM，而不是靠人手。\u003c/li\u003e\n\u003cli\u003e把它与对应镜像一起\u003cstrong\u003e做版本保存\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e与\u003cstrong\u003e漏洞扫描\u003c/strong\u003e结合，让它变得可操作。\u003c/li\u003e\n\u003cli\u003e为它签名，以保证\u003cstrong\u003e完整性\u003c/strong\u003e与来源可信。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eSBOM 和漏洞扫描是一回事吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e不是。SBOM 是组件清单；扫描则拿这份清单与 CVE 数据库比对，找出漏洞。两者互补：先知道你有什么，\n再判断它是否有漏洞。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e该选 SPDX 还是 CycloneDX？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eSPDX 是 ISO 标准，在合规中用得很多；CycloneDX 更偏安全。很多工具两种都能导出，所以你不必只选\n一个。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如果我只使用第三方镜像，还需要 SBOM 吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e需要。为你所用的镜像索要或自行生成 SBOM，能让你评估其风险、在漏洞出现时快速反应——哪怕镜像不是\n你构建的。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们押注可追溯性：把镜像里的软件登记造册并写清楚，本就是「把镜像做好」的一\n部分。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-10T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E6%9C%BA%E5%99%A8%E9%95%9C%E5%83%8Fsbom/","image":"https://www.imaxe.cloud/blog-covers/sbom-imagenes-de-maquina_hu_ffc36a1f6a89fff9.webp","language":"zh-Hans","summary":"下一个关键漏洞出现时，问题只有一个：「我受影响吗？」没有 SBOM，答案要靠几天的手工排查；有了它，只需几秒。我们来讲清它是什么，以及如何为你的镜像生成它。","tags":["安全","sbom","spdx","cyclonedx","syft","供应链"],"title":"机器镜像中的 SBOM：为你的软件建立清单与可追溯性","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E6%9C%BA%E5%99%A8%E9%95%9C%E5%83%8Fsbom/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/cloud-init-user-data_hu_6c8986f026962556.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/cloud-init-user-data_hu_6c8986f026962556.webp\" alt=\"笔记本电脑终端里正在进行系统更新\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ecloud-init\u003c/strong\u003e 是云实例首次启动时进行初始化的事实标准。当你启动一个实例并传入 \u003cstrong\u003euser-data\u003c/strong\u003e\n脚本时，正是 cloud-init 负责解释并执行它：创建用户、写入文件、安装软件包、挂载磁盘或启动\n服务。\u003c/p\u003e\n\u003cp\u003e理想的搭配很清楚：\u003cstrong\u003egolden AMI\u003c/strong\u003e 承载不变的部分——操作系统、运行时、加固；\u003cstrong\u003euser-data\u003c/strong\u003e 提供\n随环境或实例而变的部分：配置、注入的机密、角色。这样，一份镜像就能复用在众多场景里。\u003c/p\u003e\n\u003ch2 id=\"编写-user-data-的两种方式\"\u003e编写 user-data 的两种方式\u003c/h2\u003e\n\u003cp\u003euser-data 支持多种格式，最常见的两种是 shell 脚本与 cloud-config。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eshell 脚本\u003c/strong\u003e：以 \u003ccode\u003e#!/bin/bash\u003c/code\u003e 开头。用于快速任务，直接了当。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ecloud-config\u003c/strong\u003e：以 \u003ccode\u003e#cloud-config\u003c/code\u003e 开头，使用声明式 YAML。在配置用户、软件包、文件与\n命令方面更干净、更易读，也更幂等。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"一个-cloud-config-示例\"\u003e一个 cloud-config 示例\u003c/h3\u003e\n\u003cp\u003e典型的 \u003ccode\u003e#cloud-config\u003c/code\u003e 会声明这些段落：\u003ccode\u003epackages:\u003c/code\u003e（要安装的软件包）、\u003ccode\u003ewrite_files:\u003c/code\u003e\n（配置文件）、\u003ccode\u003eruncmd:\u003c/code\u003e（收尾命令）和 \u003ccode\u003eusers:\u003c/code\u003e（账户与密钥）。由于是声明式的，它比一长串\n脚本更易审阅和维护。\u003c/p\u003e\n\u003ch2 id=\"最佳实践\"\u003e最佳实践\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e让 user-data 保持精简\u003c/strong\u003e：如果它膨胀得太厉害，那部分内容多半应该烘焙进 AMI。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e幂等性\u003c/strong\u003e：把命令设计成重复执行也不会出问题。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e绝不要在 user-data 里放明文机密\u003c/strong\u003e：它可以从实例元数据读到。请在运行时从 Secrets\nManager、Parameter Store 或 Vault 注入。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e保护元数据访问\u003c/strong\u003e：启用 IMDSv2，缓解通过 SSRF 窃取凭据的风险。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e记录并调试\u003c/strong\u003e：出问题时，cloud-init 的日志（\u003ccode\u003e/var/log/cloud-init-output.log\u003c/code\u003e）是你最好的\n朋友。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"烘焙还是启动什么放哪里\"\u003e烘焙还是启动：什么放哪里\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e放进 AMI（烘焙）\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e放进 user-data（启动）\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e操作系统与补丁\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e与环境相关的配置\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e运行时、代理与加固\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e每个实例各自的变量与参数\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e稳定且体积大的软件\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e集群注册与服务发现\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e所有安装耗时的东西\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e运行时的机密注入\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e黄金法则：稳定又慢的东西烘焙进镜像；多变又轻的东西放在启动时。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"会浪费你几小时的常见错误\"\u003e会浪费你几小时的常见错误\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e把本该在镜像里的东西塞进 user-data，结果启动又慢又脆弱。\u003c/li\u003e\n\u003cli\u003e在元数据中以明文暴露机密。\u003c/li\u003e\n\u003cli\u003e以为 user-data 每次开机都会重跑：默认它只在首次启动时执行。\u003c/li\u003e\n\u003cli\u003e实例「没按预期工作」时，不去看 cloud-init 的日志。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e每次重启都会执行 user-data 吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e默认只在首次启动时执行。你可以配置 cloud-init 让某些部分每次启动都跑，但要有意识地做，并\n保证幂等。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e在 user-data 里传密码安全吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e不安全。user-data 可从实例元数据读取。请使用机密管理器并在运行时注入，同时用 IMDSv2 保护\n元数据。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ecloud-init 只能在 AWS 上用吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e不是。cloud-init 是跨平台的，可在 AWS、Azure、GCP 等环境运行，非常适合以可移植的方式自动化\n启动流程。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们设计的镜像本就打算与 cloud-init 搭配，让一份 AMI 在众多场景中都好用。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-07T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/cloud-init%E4%B8%8Euser-data/","image":"https://www.imaxe.cloud/blog-covers/cloud-init-user-data_hu_6c8986f026962556.webp","language":"zh-Hans","summary":"golden AMI 负责不变的部分；cloud-init 负责会变的部分。掌握 user-data 与 cloud-init，你就能把同一份镜像用在上千种场景里，而不必重烤。这是实用指南。","tags":["指南","cloud-init","user-data","ec2","引导初始化","imdsv2"],"title":"cloud-init 与 user-data：像专家一样在启动时配置实例","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/cloud-init%E4%B8%8Euser-data/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/ami-endurecida-kubernetes_hu_448c2b0b32cba86a.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/ami-endurecida-kubernetes_hu_448c2b0b32cba86a.webp\" alt=\"不来梅哈芬集装箱码头航拍图\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e人们很容易以为，一旦用上容器，宿主机的安全就不再重要。事实恰恰相反：每个 Kubernetes 节点\n都是一台从镜像启动的机器，宿主机一旦被攻破，其上承载的所有 Pod 都会沦陷。因此，\u003cstrong\u003e节点\nAMI\u003c/strong\u003e 是安全体系中的关键一环。\u003c/p\u003e\n\u003cp\u003e你有三条路：直接使用官方优化版 AMI，以它为基础做定制，或者完全自建。对于严肃的生产环境，\n在加固基线之上做定制或自建才是推荐做法。\u003c/p\u003e\n\u003ch2 id=\"一个好的节点-ami-应该包含什么\"\u003e一个好的节点 AMI 应该包含什么\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e针对容器运行时优化的基线\u003c/strong\u003e，containerd 与 kubelet 配置正确。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e操作系统的 CIS 加固\u003c/strong\u003e，必要时还包括 CIS Benchmark for Kubernetes 本身。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内核与组件的补丁保持最新\u003c/strong\u003e，并定期重建镜像。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e必要的代理程序\u003c/strong\u003e——日志、指标、安全——预装好，以便快速启动。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不烘焙任何密钥或凭据\u003c/strong\u003e；身份通过 IAM Roles for Service Accounts（IRSA）或等效机制获取。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e最小化配置\u003c/strong\u003e：删除节点用不到的软件包与服务。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"eks-的镜像选项\"\u003eEKS 的镜像选项\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e选项\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e优势\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e何时选用\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eEKS 优化版 AMI（AL2023）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e官方出品，由 AWS 维护\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e通用起点\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eBottlerocket\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e面向容器的最小化不可变操作系统\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e追求最高安全性与最小攻击面\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e自定义 AMI\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e完全掌控加固与代理程序\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e严格的合规要求\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e根据你在「掌控力」与「省心」之间的取舍来选择节点基线。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"bottlerocket容器优先\"\u003eBottlerocket：容器优先\u003c/h2\u003e\n\u003cp\u003eBottlerocket 是 AWS 推出的极简操作系统，专为运行容器而设计。它的攻击面极小、不可变，并且\n以镜像方式更新——而非热打补丁——与不可变基础设施的理念高度契合。如果你希望以最小的维护成本\n获得节点安全性，它值得认真评估。\u003c/p\u003e\n\u003ch2 id=\"无痛升级节点\"\u003e无痛升级节点\u003c/h2\u003e\n\u003cp\u003e只有持续保持节点更新，加固过的节点 AMI 才有意义。不可变模式在这里大放异彩：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e替换而非打补丁\u003c/strong\u003e：发布新版本 AMI 并轮换节点。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e节点组滚动更新\u003c/strong\u003e：用 \u003cem\u003ecordon\u003c/em\u003e 与 \u003cem\u003edrain\u003c/em\u003e 排空，然后逐个替换节点。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eManaged Node Groups\u003c/strong\u003e 或 Karpenter，自动完成新 AMI 的替换。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePodDisruptionBudgets\u003c/strong\u003e，确保轮换不影响服务可用性。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见错误\"\u003e常见错误\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e数月使用默认的优化版 AMI 而不更新。\u003c/li\u003e\n\u003cli\u003e把集群凭据烘焙进镜像，而不使用联合身份。\u003c/li\u003e\n\u003cli\u003e忘记加固 kubelet 本身以及文件系统权限。\u003c/li\u003e\n\u003cli\u003e不限制节点的 SSH 访问：理想状态是零 SSH，仅通过 SSM 访问。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e我需要自定义 AMI，还是 EKS 优化版就够了？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e起步阶段，官方优化版是不错的出发点。如果你有严格的合规或安全要求，就在它之上做定制，或用\n自己的加固与代理程序自建镜像。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eBottlerocket 能取代普通的 Linux AMI 吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e对于只运行容器的节点，可以：攻击面更小，更新不可变。但它不适合需要通用操作系统的负载。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e发布新 AMI 后如何升级节点？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e通过节点组滚动更新：逐步排空并替换节点，同时遵守 PodDisruptionBudgets，避免影响服务。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们设计的加固基础镜像，正适合作为你 Kubernetes 节点的基石。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-07-03T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/kubernetes%E5%8A%A0%E5%9B%BAami/","image":"https://www.imaxe.cloud/blog-covers/ami-endurecida-kubernetes_hu_448c2b0b32cba86a.webp","language":"zh-Hans","summary":"Kubernetes 的安全上限，就是它所运行节点的安全水平。一个经过加固、及时打补丁并调优的节点 AMI，是许多团队忽视的基础。我们来讲讲如何为 EKS 与自建集群构建理想的基础镜像。","tags":["指南","kubernetes","eks","bottlerocket","加固","节点"],"title":"面向 Kubernetes 节点的加固 AMI：集群的安全基石","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/kubernetes%E5%8A%A0%E5%9B%BAami/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/reconstruir-ami-ante-cve_hu_920b537b3bf25409.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/reconstruir-ami-ante-cve_hu_920b537b3bf25409.webp\" alt=\"带红灯的手动火警报警器\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e从一个关键漏洞被公布，到你在所有实例上修复它，中间那段时间就是\u003cstrong\u003e暴露窗口\u003c/strong\u003e。它持续得越久，\n攻击者可利用的时间就越多。在传统的「一台台服务器打补丁」模式下，这个窗口以天甚至周计。而在\n一套自动化良好的不可变镜像模式里，它以小时计。\u003c/p\u003e\n\u003cp\u003e关键在于：把 CVE 响应当成一个可复现的工程流程，而不是临阵磨枪的手工冲刺。\u003c/p\u003e\n\u003ch2 id=\"自动响应的架构\"\u003e自动响应的架构\u003c/h2\u003e\n\u003cp\u003e目标是：一旦某个关键 CVE 影响到你，一份打好补丁的新镜像就自动诞生、通过验证，并在几乎不需要\n人工介入的情况下待命上线。这条链路有四个环节。\u003c/p\u003e\n\u003ch3 id=\"1-检测\"\u003e1. 检测\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e用 Amazon Inspector、Trivy 或 Grype 对在用镜像做\u003cstrong\u003e持续扫描\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e漏洞情报源\u003c/strong\u003e——NVD、操作系统厂商公告——用来驱动告警。\u003c/li\u003e\n\u003cli\u003e每份镜像的 \u003cstrong\u003eSBOM\u003c/strong\u003e，让你在几秒内确认受影响组件是否真的存在。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2-触发\"\u003e2. 触发\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e关键或高危等级的告警触发重建流水线，例如通过 EventBridge 进入 CodeBuild，或用 webhook 打到\n你的 CI。\u003c/li\u003e\n\u003cli\u003e生产环境可以要求人工审批，同时把构建与验证保持完全自动。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-重建与验证\"\u003e3. 重建与验证\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e流水线——Packer 或 EC2 Image Builder——从更新后的基线重建镜像，执行 \u003ccode\u003ednf\u003c/code\u003e/\u003ccode\u003eapt update\u003c/code\u003e 并施加\n一贯的加固。\u003c/li\u003e\n\u003cli\u003e对新镜像\u003cstrong\u003e重新扫描\u003c/strong\u003e：如果 CVE 还在，发布毫无意义。\u003c/li\u003e\n\u003cli\u003e跑\u003cstrong\u003e测试\u003c/strong\u003e：启动、冒烟测试、InSpec，确保没有弄坏什么。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"4-分发与部署\"\u003e4. 分发与部署\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e新 AMI 完成\u003cstrong\u003e版本标记\u003c/strong\u003e，复制到需要的区域，并更新 SSM Parameter Store 中的指针。\u003c/li\u003e\n\u003cli\u003e更新 \u003cstrong\u003eLaunch Template\u003c/strong\u003e，由 Auto Scaling Group 执行\u003cem\u003e滚动更新\u003c/em\u003e或蓝绿部署。\u003c/li\u003e\n\u003cli\u003e存在漏洞的镜像标记为\u003cstrong\u003e弃用\u003c/strong\u003e，免得有人误启动。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"关键指标补丁-mttr\"\u003e关键指标：补丁 MTTR\u003c/h2\u003e\n\u003cp\u003e度量\u003cstrong\u003e从关键 CVE 公布，到你的机队全部跑上修复镜像的平均时间\u003c/strong\u003e。这个指标概括了你的成熟度。把它\n从数周压到数小时，是投资镜像流水线最大的回报之一。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e成熟度\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e典型 MTTR\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e怎么打补丁\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e手工\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e数天到数周\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e逐台 SSH\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e半自动\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e数小时到一两天\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e手工重建 + 滚动更新\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e自动\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e数小时\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e触发、重建、部署\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e流水线自动化能大幅压缩暴露窗口。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"最佳实践\"\u003e最佳实践\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e做演练\u003c/strong\u003e：在真正需要之前，用一个模拟的 CVE 把整条链路跑一遍。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e渐进式部署\u003c/strong\u003e：金丝雀或滚动更新，在不拖垮服务的前提下发现回归。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e备好回滚\u003c/strong\u003e：保留上一个版本，并准备好立刻回退的方案。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e留痕沟通\u003c/strong\u003e：记录每次重建是由哪个 CVE 触发的；这就是合规证据。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e是不是任何 CVE 都要重建？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e不是。按严重程度与可利用性排优先级，并确认受影响组件是否真的在你的镜像里——SBOM 在这里是关键。\n关键级和可利用的高危值得紧急重建；其余的可以等常规周期。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e部署新镜像时怎么避免弄坏生产？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e发布前做自动化验证——冒烟测试、InSpec——并采用渐进式部署：金丝雀、滚动更新或蓝绿，同时备好回滚。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e不在 AWS 上也能自动化吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e可以。这套模式——检测、触发、重建、部署——在 Azure 与 GCP 上用各自的对应服务同样成立；Packer 则\n为构建阶段带来可移植性。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，面对新漏洞我们会迅速重建并重新扫描镜像，让你始终从一个最新的基线出发。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-30T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/cve%E5%90%8E%E9%87%8D%E5%BB%BAami/","image":"https://www.imaxe.cloud/blog-covers/reconstruir-ami-ante-cve_hu_920b537b3bf25409.webp","language":"zh-Hans","summary":"下一个 Log4Shell 出现时，时钟已经在走。能在几小时内重建并重新分发镜像的组织睡得安稳；靠手工打补丁的则不然。这就是自动响应关键 CVE 的架构。","tags":["安全","cve","漏洞","流水线","inspector","mttr"],"title":"面对关键 CVE 时重建 AMI：把漏洞响应自动化","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/cve%E5%90%8E%E9%87%8D%E5%BB%BAami/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/aws-azure-gcp-imagenes_hu_4cc3e453ad41116a.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/aws-azure-gcp-imagenes_hu_4cc3e453ad41116a.webp\" alt=\"19 英寸机架中的配线架与以太网交换机\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e三大云解决的是同一个问题——拥有一份可复用的模板，用来启动一模一样的机器——只是各有各的做法\n与命名。搞清楚这些对应关系，是设计一套无摩擦多云策略的第一步。\u003c/p\u003e\n\u003cp\u003e在 AWS 它叫 \u003cstrong\u003eAMI\u003c/strong\u003e（Amazon Machine Image）；在 Azure 叫 \u003cstrong\u003eManaged Image\u003c/strong\u003e，更重要的是\n\u003cstrong\u003eAzure Compute Gallery\u003c/strong\u003e（旧称 Shared Image Gallery）；在 Google Cloud 则是 \u003cstrong\u003eCustom\nImage\u003c/strong\u003e。它们都封装了一块预配置的启动盘，但在版本管理、共享与分发方式上并不相同。\u003c/p\u003e\n\u003ch2 id=\"一眼看懂对应关系\"\u003e一眼看懂对应关系\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e概念\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eAWS\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eAzure\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eGoogle Cloud\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e机器镜像\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAMI\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eManaged Image\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCustom Image\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e目录或图库\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e无原生方案：靠标签与 SSM\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAzure Compute Gallery\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eImage Family\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e托管版本管理\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e手动，靠命名与标签\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGallery 原生支持\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eImage Family：族内取最新\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e跨区域分发\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e复制 AMI\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGallery 中的副本\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e默认全局镜像\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e底层存储\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEBS 快照\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eManaged Disks\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePersistent Disk\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e加密\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eKMS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e平台密钥或客户密钥\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGoogle 托管或 CMEK\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e三大云中机器镜像的功能对应关系。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"aws-ami事实标准\"\u003eAWS AMI：事实标准\u003c/h2\u003e\n\u003cp\u003eAMI 大概是最广为人知、生态最庞大的镜像格式。它的强项是成熟：目录极其庞大，与 EC2 Image\nBuilder、Marketplace 深度集成，社区规模惊人。它历史上的短板，是缺少一个自带托管版本管理\n的原生镜像图库：版本与跨区域分发得靠命名约定、标签、SSM Parameter Store 以及跨区域的显式\n复制来解决。\u003c/p\u003e\n\u003ch2 id=\"azure-compute-gallery版本与副本开箱即用\"\u003eAzure Compute Gallery：版本与副本开箱即用\u003c/h2\u003e\n\u003cp\u003eAzure 在镜像治理上下了重注。\u003cstrong\u003eCompute Gallery\u003c/strong\u003e 原生提供镜像定义、版本以及向多个区域自动\n复制的副本，还带有细粒度的访问控制。对需要按团队与区域有序分发镜像的大型组织来说，这套模型\n非常省心。代价是概念上的学习曲线略陡一些。\u003c/p\u003e\n\u003ch2 id=\"gcp-custom-image全局式的简洁\"\u003eGCP Custom Image：全局式的简洁\u003c/h2\u003e\n\u003cp\u003eGoogle Cloud 胜在简洁。它的镜像默认就是\u003cstrong\u003e全局的\u003c/strong\u003e——不必逐个区域复制——而 \u003cstrong\u003eImage Family\u003c/strong\u003e\n这个概念优雅地解决了版本问题：你指向某个族，永远拿到族内最新的未弃用镜像。这是一套减少摩擦\n的极简模型，对看重运维简洁性的团队尤其有吸引力。\u003c/p\u003e\n\u003ch2 id=\"多云策略一份模板三种镜像\"\u003e多云策略：一份模板，三种镜像\u003c/h2\u003e\n\u003cp\u003e如果你要在多朵云上发布或部署，维护三套独立的构建流程会很痛苦。业界的答案是 \u003cstrong\u003ePacker\u003c/strong\u003e：\n一份模板、共享的 provisioner，加上每朵云一个 source 块，就能从同一份定义并行产出 AMI、\nManaged Image 与 Custom Image。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e在三朵云上\u003cstrong\u003e复用\u003c/strong\u003e同一套安装与加固脚本。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e减少\u003c/strong\u003e环境间漂移：同一份配置，三个目标。\u003c/li\u003e\n\u003cli\u003e用统一的命名与元数据方案做到\u003cstrong\u003e一致的版本管理\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e自动化\u003c/strong\u003e向各图库的发布：Gallery、Image Family、标签与 SSM。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"到底该选哪个\"\u003e到底该选哪个？\u003c/h2\u003e\n\u003cp\u003e没有绝对赢家，取决于你的处境。要生态与成熟度，选 AWS。需要企业级镜像治理、原生版本与副本，\nAzure 的 Compute Gallery 最出彩。看重简洁与免复制的全局覆盖，选 GCP。而如果你同时生活在\n多朵云上，答案不是某个平台，而是一种\u003cstrong\u003e实践\u003c/strong\u003e：把镜像描述成代码，并以可移植的方式构建它们。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e能把 AWS 的 AMI 直接搬到 Azure 或 GCP 吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e不能直接搬：格式与底层存储都不一样。通常的做法是用一份公共模板在每朵云上重新构建镜像，比如\n用 Packer；或者通过各家提供商的导入流程导入磁盘。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e哪朵云的镜像版本管理最好？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAzure Compute Gallery 开箱即用的托管版本管理最完整；GCP 用 Image Family 优雅地解决了这件\n事；AWS 需要你自己多定一些约定，但也因此非常灵活。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e多云镜像策略值得吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e如果你出于数据主权、韧性或避免供应商锁定而在多朵云上运营，那是值得的。关键是把镜像当作代码\n来管理，避免维护成本成倍增长。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们从设计之初就考虑可移植性，让你的部署不必依赖任何单一的云。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-26T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/aws-azure-gcp%E9%95%9C%E5%83%8F%E5%AF%B9%E6%AF%94/","image":"https://www.imaxe.cloud/blog-covers/aws-azure-gcp-imagenes_hu_4cc3e453ad41116a.webp","language":"zh-Hans","summary":"AMI、Managed Image、Custom Image：同一件事——一份用来启动机器的模板——每朵云都有自己的叫法和规矩。如果你横跨多朵云，弄清差异能省掉不少意外。","tags":["指南","aws","azure","gcp","多云","packer"],"title":"AWS、Azure 与 GCP：跨云的机器镜像对比","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/aws-azure-gcp%E9%95%9C%E5%83%8F%E5%AF%B9%E6%AF%94/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/tendencias-cloud-2026_hu_c649ca0919e5a33f.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/tendencias-cloud-2026_hu_c649ca0919e5a33f.webp\" alt=\"欧洲核子研究中心数据中心的服务器通道\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e2026 年的第一条大新闻并不好听：价格持续下调的时代结束了。能源成本压力、对 AI 的巨额投入，\n以及 GPU 需求，正把价格往上推。降价成了例外，而不是常态。\u003c/p\u003e\n\u003cp\u003e这一底层变化左右着其余的一切。云便宜的时候，浪费是可以容忍的；云一变贵，效率就成了管理层\n议题。于是今年的趋势都围绕着「用更少做更多」以及「有判断地自动化」展开。\u003c/p\u003e\n\u003ch2 id=\"一不可变基础设施成为标准\"\u003e一、不可变基础设施成为标准\u003c/h2\u003e\n\u003cp\u003e「构建镜像然后替换」的模式，正稳固为默认实践。团队不再给运行中的服务器打补丁，而是烘焙带\n版本的镜像，通过替换实例来部署。这带来可预期的发布、干净的回滚，以及更小的攻击面。\n\u003cstrong\u003eGolden AMI\u003c/strong\u003e 与治理良好的机器镜像，正是这套做法的核心。\u003c/p\u003e\n\u003ch2 id=\"二finops-升上董事会\"\u003e二、FinOps 升上董事会\u003c/h2\u003e\n\u003cp\u003e云成本管理不再只是技术团队的事，而成了业务优先事项。今年最常动用的杠杆包括：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e为每一份负载做\u003cstrong\u003e打标签与可见性\u003c/strong\u003e建设，弄清谁花了什么钱。\u003c/li\u003e\n\u003cli\u003e用\u003cstrong\u003e预留实例与竞价实例\u003c/strong\u003e打磨单位成本。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e镜像优化\u003c/strong\u003e：轻量镜像、快速启动，以及清理孤儿快照——一项经典的隐藏成本。\u003c/li\u003e\n\u003cli\u003e持续\u003cstrong\u003e规格适配（rightsizing）\u003c/strong\u003e，关停闲置资源。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e拥抱 ARM 与 Graviton\u003c/strong\u003e，因为它们性价比更好。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"三ai从试验走向变现\"\u003e三、AI：从试验走向变现\u003c/h2\u003e\n\u003cp\u003e热潮初退之后，2026 年是把 AI 投入榨出回报的一年。重点转向压缩 GPU 空转时间、优化推理，并把\n模型推向边缘。此外还浮现出\u003cstrong\u003eAI 智能体网格\u003c/strong\u003e这一模式：由中枢来治理智能体之间的通信、施加成本\n管控，并把请求路由到能解决该任务的最便宜模型上。\u003c/p\u003e\n\u003ch2 id=\"四多云与边缘脚踏实地\"\u003e四、多云与边缘，脚踏实地\u003c/h2\u003e\n\u003cp\u003e多云正在普及，但态度务实：不是赶时髦，而是为了避免供应商锁定、满足数据主权要求，并汲取每\n朵云的长处。机器镜像的可移植性——一份模板产出面向多朵云的镜像——因此更有价值。与此同时，\n在 AI 与物联网的推动下，\u003cstrong\u003e边缘\u003c/strong\u003e不断生长，把算力挪到离数据更近的地方。\u003c/p\u003e\n\u003ch2 id=\"五监管合规之年\"\u003e五、监管：合规之年\u003c/h2\u003e\n\u003cp\u003e监管框架正在收紧。2026 年，欧洲人工智能法规的重要阶段与新的责任指令陆续生效，多个司法辖区\n也在强化云治理的要求。对基础设施的直接后果是：可追溯性——你运行了什么软件、如何保障它、又\n如何证明——变成了硬性要求。可审计的镜像链与 SBOM，不再是奢侈品。\u003c/p\u003e\n\u003ch2 id=\"这对你的基础设施意味着什么\"\u003e这对你的基础设施意味着什么\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e趋势\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e实际含义\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e建议动作\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e云更贵\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e每一份资源都要算账\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFinOps 与高效镜像\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e不可变\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e更少漂移，更强掌控\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003egolden AMI 流水线\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAI 上生产\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e优化推理与成本\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e共享 GPU、边缘、智能体\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e多云\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e避免锁定\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e用 Packer 做可移植镜像\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e监管\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e可追溯性成为义务\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSBOM 与可审计链路\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e把趋势落到你日常工作的具体动作上。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e2026 年云价格真的会涨吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e分析师指出，能源与 GPU 成本带来上行压力，而降价已成例外。这正是 FinOps 与资源效率今年分量\n如此之重的原因。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e什么是 AI 智能体网格？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这是一种架构：由中央枢纽治理 AI 智能体之间的通信，同时施加安全策略、成本管控，并把请求路由\n到最合适、最经济的模型。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e不可变并不是新概念，为什么现在成了趋势？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e因为当下的处境让它近乎成为必需：成本上涨、监管严苛，加上对可审计部署的需求，把「带版本的\n镜像加替换」这一模式推成了标准。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们紧盯这些趋势，好让我们的镜像贴合正在到来的云：高效、可移植、可审计。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-23T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E4%BA%91%E8%B6%8B%E5%8A%BF2026/","image":"https://www.imaxe.cloud/blog-covers/tendencias-cloud-2026_hu_c649ca0919e5a33f.webp","language":"zh-Hans","summary":"2026 年的云更贵、更受监管，也更聪明。对构建与部署基础设施的人来说，三股潮流——不可变、成本管控与 AI 驱动的自动化——决定了今年该把精力放在哪里。","tags":["动态","finops","趋势","多云","边缘计算","监管"],"title":"2026 云趋势：不可变镜像、FinOps 与 AI 定调","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E4%BA%91%E8%B6%8B%E5%8A%BF2026/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/amis-vs-contenedores_hu_9942fe419781baec.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/amis-vs-contenedores_hu_9942fe419781baec.webp\" alt=\"鹿特丹港堆叠的货运集装箱\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAMI\u003c/strong\u003e 打包的是一整套操作系统外加你的软件：它是整台虚拟机的模板。\u003cstrong\u003e容器\u003c/strong\u003e只打包你的\n应用及其依赖，并共享宿主机的内核。体积与隔离模型上的差别，几乎解释了其余一切。\u003c/p\u003e\n\u003cp\u003e这不是一场对决：实践中，容器运行在\u003cstrong\u003e由 AMI 启动的虚拟机之上\u003c/strong\u003e。有价值的问题不是谁赢，\n而是各自解决哪一层的问题。\u003c/p\u003e\n\u003ch2 id=\"直接对比\"\u003e直接对比\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e维度\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eAMI（虚拟机）\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e容器\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e包含什么\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e完整操作系统加软件\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e应用与依赖\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e隔离性\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e强，由虚拟机管理程序提供\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e进程级，共享内核\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e体积\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGB 级\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMB 级\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e启动\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e数秒到数分钟\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e毫秒到数秒\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e密度\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e较低：每个实例一台虚拟机\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e高：单宿主机可跑很多\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e可移植性\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e绑定云平台或虚拟机管理程序\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e极高：任何带运行时的宿主机\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e操作系统维护\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e由你负责\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e继承自宿主机或基础镜像\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e理想场景\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e单体应用、宿主机、专用虚拟机\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e微服务、快速伸缩\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eAMI 与容器在不同层面解决不同的问题。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"何时选择-ami\"\u003e何时选择 AMI\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e强制要求强隔离\u003c/strong\u003e：多租户负载，或隔离必须由虚拟机管理程序保证的严格合规场景。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e需要一整台机器的软件\u003c/strong\u003e：数据库、遗留应用、网络或安全设备。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e需要完全掌控操作系统\u003c/strong\u003e：当你需要内核模块、特定驱动或对系统做精细调优时。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e作为节点的基础\u003c/strong\u003e：即使在容器的世界里，你的 Kubernetes 节点也是从 AMI 启动的。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"何时选择容器\"\u003e何时选择容器\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e可独立伸缩与发布的\u003cstrong\u003e微服务\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e配合持续集成与持续交付的\u003cstrong\u003e快速发布节奏\u003c/strong\u003e。\u003c/li\u003e\n\u003cli\u003e用大量小负载压榨硬件的\u003cstrong\u003e高密度\u003c/strong\u003e部署。\u003c/li\u003e\n\u003cli\u003e在开发、测试与多个云之间的\u003cstrong\u003e可移植性\u003c/strong\u003e。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"成熟的答案两者结合\"\u003e成熟的答案：两者结合\u003c/h2\u003e\n\u003cp\u003e成熟的团队不做二选一，而是分层。他们构建一个\u003cstrong\u003e加固的 golden AMI\u003c/strong\u003e 作为宿主机基线——打好\n补丁、完成 CIS 加固、装好安全代理——然后在其上运行容器。这样就能兼得两全：在机器镜像层面\n获得宿主机的安全与掌控，在应用层面获得容器的敏捷与密度。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e基于加固且带版本的 AMI 构建 Kubernetes 或 ECS 节点。\u003c/li\u003e\n\u003cli\u003e宿主机通过替换 AMI 来更新（不可变），而非热打补丁。\u003c/li\u003e\n\u003cli\u003e用容器承载应用的快速生命周期。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"microvm边界正在模糊\"\u003eMicroVM：边界正在模糊\u003c/h2\u003e\n\u003cp\u003eFirecracker 这类技术——AWS Lambda 与 Fargate 背后的基础——创造了 \u003cstrong\u003emicroVM\u003c/strong\u003e：既有虚拟机\n的强隔离，又有毫秒级启动，几乎与容器无异。这说明未来不是「虚拟机还是容器」的二选一，而\n是一条连续谱，你可以为每种负载在隔离性与敏捷性之间选一个合适的位置。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e容器会让 AMI 过时吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e不会。容器运行在由镜像启动的机器上。加固过的 AMI 仍然是运行容器的节点的理想基线。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e虚拟机和容器哪个更安全？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e虚拟机在设计上提供更强的隔离。容器共享内核，因此需要额外的控制手段。对非常敏感的负载，\n通常把虚拟机与加固后的容器结合使用。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e能轻松从 AMI 迁移到容器吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e取决于应用。无状态、模块化的服务迁移顺利；与操作系统深度耦合的单体应用则需要更多工作。\n很多时候，混合且渐进的路线更合适。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们相信为每种负载选择合适的工具：因此我们的镜像既能直接作为宿主机，\n也能作为你容器的加固基线。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-19T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E4%B8%8E%E5%AE%B9%E5%99%A8%E5%AF%B9%E6%AF%94/","image":"https://www.imaxe.cloud/blog-covers/amis-vs-contenedores_hu_9942fe419781baec.webp","language":"zh-Hans","summary":"机器镜像还是容器？这个问题本身就问错了：它们并不竞争，而是互补。理解各自解决什么问题，能让你避免过度设计，并为每种负载挑到合适的工具。","tags":["指南","容器","kubernetes","docker","microvm","架构"],"title":"AMI 与容器：什么时候用哪个（以及什么时候一起用）","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E4%B8%8E%E5%AE%B9%E5%99%A8%E5%AF%B9%E6%AF%94/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/elegir-ami-de-confianza_hu_ab14e41f927a6439.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/elegir-ami-de-confianza_hu_ab14e41f927a6439.webp\" alt=\"放大镜正在检视一枚邮票\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e从一份 AMI 启动实例，实际上就是在你自己的账户里运行别人打包好的软件。如果镜像里藏着恶意\n软件、加密货币矿机、内嵌密钥，或者只是些没打补丁的软件包，这份风险就会直接走进你的基础\n设施。业界已有专为此设计的恶意公开镜像的记录在案。\u003c/p\u003e\n\u003cp\u003e解决办法不是疑神疑鬼，而是一套可重复的\u003cstrong\u003e核验流程\u003c/strong\u003e。挑一份好的 AMI，就像招聘一个人：交钥匙\n之前，你要核对身份、看推荐、检查状态。\u003c/p\u003e\n\u003ch2 id=\"可信-ami-的五大支柱\"\u003e可信 AMI 的五大支柱\u003c/h2\u003e\n\u003cp\u003e用这五条轴线去评估每一份候选镜像。若在多条上不合格，那就换一份。\u003c/p\u003e\n\u003ch3 id=\"1-来源是谁发布的\"\u003e1. 来源：是谁发布的？\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e核验发布该镜像账户的 \u003cstrong\u003eowner ID\u003c/strong\u003e；对匿名或来路不明的所有者保持怀疑。\u003c/li\u003e\n\u003cli\u003e优先选择官方厂商、已验证合作伙伴，或声誉可查的发布者所提供的镜像。\u003c/li\u003e\n\u003cli\u003e确认名称与描述对得上一个正当来源：当心 \u003cem\u003etyposquatting\u003c/em\u003e 式的仿冒。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2-安全里面装了什么\"\u003e2. 安全：里面装了什么？\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e它是否\u003cstrong\u003e已加固\u003c/strong\u003e（CIS 或同等加固），还是一份未加防护的基线？\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e快照是否加密\u003c/strong\u003e？\u003c/li\u003e\n\u003cli\u003e上生产之前，自己用 Inspector、Trivy 之类的工具扫一遍，找出 CVE 与机密。\u003c/li\u003e\n\u003cli\u003e检查里面有没有来路不明的\u003cstrong\u003e已授权 SSH 密钥\u003c/strong\u003e，或多余的用户账号。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-维护它还活着吗\"\u003e3. 维护：它还活着吗？\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e多久更新一次\u003c/strong\u003e？一年没有新版本的镜像是个警讯。\u003c/li\u003e\n\u003cli\u003e发布者是否在每个版本里说明\u003cstrong\u003e已修复的 CVE\u003c/strong\u003e？\u003c/li\u003e\n\u003cli\u003e是否有清晰的\u003cstrong\u003e文档\u003c/strong\u003e说明它包含什么、如何配置？\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"4-兼容性它适合你的场景吗\"\u003e4. 兼容性：它适合你的场景吗？\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e架构是否正确（\u003cstrong\u003ex86_64\u003c/strong\u003e 还是 \u003cstrong\u003eARM/Graviton\u003c/strong\u003e），以及虚拟化类型。\u003c/li\u003e\n\u003cli\u003e可用区域，以及能否复制到你所在的区域。\u003c/li\u003e\n\u003cli\u003e是否支持你需要的实例类型，以及能否与你的自动化衔接。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"5-成本与许可你付什么钱受什么条款约束\"\u003e5. 成本与许可：你付什么钱，受什么条款约束？\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e成本模式：免费、按小时计费，还是 BYOL。\u003c/li\u003e\n\u003cli\u003e所含软件的许可及其义务。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e快照\u003c/strong\u003e及相关存储的费用。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"快速核验清单\"\u003e快速核验清单\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e检查项\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e好的迹象\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e警讯\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e所有者\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e已验证且知名的 owner\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e匿名或刚创建的账户\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e加密\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e快照已加密\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e未加密\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e更新\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e版本新且更新频繁\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e12 个月以上没有变化\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e文档\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e有版本说明与 CVE 记录\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e稀薄或干脆没有\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e自行扫描\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e无关键 CVE，无机密\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e存在漏洞或内嵌密钥\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e成本\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e模式清晰、可预期\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e存在隐藏的存储费用\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e把一份 AMI 送上生产之前，请逐条核验。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"好做法在你拿到的镜像之上重烤一遍\"\u003e好做法：在你拿到的镜像之上重烤一遍\u003c/h2\u003e\n\u003cp\u003e即便是可信的镜像也会老化。最稳妥的做法，是取一份可靠的基础 AMI，\u003cstrong\u003e在你自己的流水线里重烤\u003c/strong\u003e：\n打上你的补丁、施加你的加固与配置，用你的密钥加密，并做好版本管理。这样你既继承了源镜像的\n优点，又叠加了自己的质量把关与可追溯性。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e使用社区的公开 AMI 安全吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e可能安全，但你必须核验所有者、内容与状态，并在使用前扫描。生产环境更适合用可信发布者的\n镜像，或者干脆自己重烤一份。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e我怎么知道一份 AMI 里有没有后门？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e没有万无一失的办法，但扫描镜像、检查用户与已授权密钥、审视计划任务，并在隔离的测试实例上\n观察网络流量，能大幅降低风险。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e付费镜像是不是比免费镜像更值得信任？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e价格并不担保安全，但一个持续维护并撰写文档的发布者——无论收费与否——通常比一份被遗弃的匿名\n镜像更让人放心。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们构建来源清晰、加密到位、持续更新的镜像，让你可以放心部署。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-16T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E5%A6%82%E4%BD%95%E9%80%89%E6%8B%A9%E5%8F%AF%E4%BF%A1ami/","image":"https://www.imaxe.cloud/blog-covers/elegir-ami-de-confianza_hu_ab14e41f927a6439.webp","language":"zh-Hans","summary":"并非所有公开镜像都安全，也并非所有安全的镜像都适合你。用别人的 AMI 启动实例之前，值得掀开引擎盖看一眼。这就是有判断力的团队所用的检查清单。","tags":["指南","ami","安全","来源","检查清单","marketplace"],"title":"投入生产之前，如何挑选一份可信的 AMI","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E5%A6%82%E4%BD%95%E9%80%89%E6%8B%A9%E5%8F%AF%E4%BF%A1ami/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/cifrado-parches-cumplimiento-cloud_hu_d680a8e49016fa16.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/cifrado-parches-cumplimiento-cloud_hu_d680a8e49016fa16.webp\" alt=\"露出键盘的恩尼格玛密码机\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e企业在保护网络与应用上投入巨大，却常常忽视了一切启动的起点——\u003cstrong\u003e基础镜像\u003c/strong\u003e。一份带着过期软件\n包、快照未加密的 AMI，会把风险传染给由它诞生的每一个实例。好消息是：保护镜像是一个单点、\n性价比极高的控制项。\u003c/p\u003e\n\u003cp\u003e解决这件事的三件套说起来简单，做起来需要长期坚持：\u003cstrong\u003e加密\u003c/strong\u003e、\u003cstrong\u003e补丁\u003c/strong\u003e与\u003cstrong\u003e可证明的合规\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2 id=\"1-加密保护静态与传输中的数据\"\u003e1. 加密：保护静态与传输中的数据\u003c/h2\u003e\n\u003cp\u003e当其他防线都失守时，加密就是最后一道防线。对机器镜像而言，它体现在多个层面：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e用 AWS KMS \u003cstrong\u003e加密 EBS 快照\u003c/strong\u003e；在其他云上则用 Azure Disk Encryption 与 Google CMEK。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e由客户管理的密钥（CMK）\u003c/strong\u003e，配合自动轮换与最小化访问策略。\u003c/li\u003e\n\u003cli\u003e在账户层面启用\u003cstrong\u003e默认加密\u003c/strong\u003e，让任何镜像都不会以明文诞生。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e把机密留在镜像之外\u003c/strong\u003e：绝不要把密码或令牌烘焙进去；用 Secrets Manager、Vault 或\nParameter Store 在运行时注入。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"2-补丁与-cve-赛跑\"\u003e2. 补丁：与 CVE 赛跑\u003c/h2\u003e\n\u003cp\u003e漏洞每天都在公布。镜像在创建当天是安全的，此后每过一天就少安全一分。在不可变的世界里，补丁\n管理不是去更新还在运行的服务器，而是\u003cstrong\u003e频繁重烤\u003c/strong\u003e镜像。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e重建节奏\u003c/strong\u003e：基础镜像至少每月重建一次；若你的技术栈出现关键 CVE，则立即重建。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e在流水线中扫描\u003c/strong\u003e：集成 Trivy、Grype 或 Amazon Inspector，在发布前发现 CVE。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e质量门禁\u003c/strong\u003e：一旦出现超过阈值的漏洞（例如关键级或可利用的高危），就阻断发布。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSBOM\u003c/strong\u003e：生成\u003cem\u003e软件物料清单\u003c/em\u003e，弄清每份镜像到底装了什么，好在下一个 Log4Shell 到来时迅速\n作出反应。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"3-合规做到还要证明\"\u003e3. 合规：做到还要证明\u003c/h2\u003e\n\u003cp\u003e审计场合，安全本身还不够：你得用证据证明它。治理良好的镜像会自然而然地产出这些证据。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e框架\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e它对你的镜像有何期待\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e你能拿出的证据\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSOC 2\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e一致且受监控的安全控制\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e加固报告与构建日志\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eISO 27001\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e漏洞管理与变更控制\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCVE 扫描、版本记录与 SBOM\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ePCI DSS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e安全配置与有据可查的补丁\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCIS 基线与重建历史\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eENS / GDPR\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e加密与数据最小化\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eKMS 加密，且镜像中不含个人数据\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003e安全镜像的实践如何转化为合规证据。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"2026-年的新监管环境\"\u003e2026 年的新监管环境\u003c/h2\u003e\n\u003cp\u003e监管环境正在收紧。2026 年，欧洲人工智能法规的关键阶段与新的产品责任指令陆续生效，多个司法\n辖区也在强化云治理与合规要求。落到实处就是：你运行了哪些软件、又是如何保障它们的，这份可\n追溯性不再是可选项。一条可审计的镜像链，就是你最好的保险。\u003c/p\u003e\n\u003ch2 id=\"镜像安全检查清单\"\u003e镜像安全检查清单\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e已启用默认加密，快照使用 CMK。\u003c/li\u003e\n\u003cli\u003e没有烘焙进去的机密；凭据在外部管理。\u003c/li\u003e\n\u003cli\u003e每次构建都做 CVE 扫描，并设有质量门禁。\u003c/li\u003e\n\u003cli\u003e定期重建，遇关键 CVE 立即重建。\u003c/li\u003e\n\u003cli\u003e已应用并验证 CIS 基线。\u003c/li\u003e\n\u003cli\u003eSBOM 与构建日志归档留存为证据。\u003c/li\u003e\n\u003cli\u003e过期镜像安全退役。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e不可变镜像多久该打一次补丁？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e它不做热补丁，而是重建。每月一个周期是不错的下限，若关键 CVE 影响到你的软件，则临时追加\n重建。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSBOM 是什么，我为什么需要它？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eSBOM 是你镜像中全部软件与依赖的清单。有了它，几分钟内就能判断某个新漏洞是否波及你；而且\n合规方面对它的要求越来越普遍。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e加密会影响性能吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e用 KMS 做 EBS 加密是透明的，对绝大多数负载而言，性能影响几乎察觉不到。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们对镜像持续施加加密、扫描与更新，让你从一个能在任何审计中站得住脚的\n基线出发。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-12T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E4%BA%91%E7%AB%AF%E5%8A%A0%E5%AF%86%E8%A1%A5%E4%B8%81%E4%B8%8E%E5%90%88%E8%A7%84/","image":"https://www.imaxe.cloud/blog-covers/cifrado-parches-cumplimiento-cloud_hu_d680a8e49016fa16.webp","language":"zh-Hans","summary":"把数据加密、把补丁跟上、并能在审计中拿出证据：这三件事合起来，能让你的机器镜像成为可信资产，而不是潜伏的风险。","tags":["安全","加密","kms","cve","soc 2","iso 27001","pci dss"],"title":"加密、补丁与合规：云镜像的安全三件套","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/%E4%BA%91%E7%AB%AF%E5%8A%A0%E5%AF%86%E8%A1%A5%E4%B8%81%E4%B8%8E%E5%90%88%E8%A7%84/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/hardening-cis-ami-ec2_hu_8c72206698ec85fc.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/hardening-cis-ami-ec2_hu_8c72206698ec85fc.webp\" alt=\"挂锁与铁链锁住的金属大门\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCIS 基线\u003c/strong\u003e（CIS Benchmarks）是由 Center for Internet Security 发布的安全配置指南，经专家\n共识编写而成。它覆盖各类操作系统——Amazon Linux、Ubuntu、RHEL、Windows——给出数百条具体建议：\n文件权限、内核参数、口令策略、应当关闭的服务，以及审计配置。\u003c/p\u003e\n\u003cp\u003e把加固施加在 \u003cstrong\u003eAMI\u003c/strong\u003e 上——而不是在每一台已部署的服务器上——是最高效的：加固一次，之后每个实例\n生来就是安全的。这正是 ISO 27001、SOC 2、PCI DSS 等框架所要求的「默认安全」路线。\u003c/p\u003e\n\u003ch2 id=\"l1-与-l2-级别该拧多紧\"\u003eL1 与 L2 级别：该拧多紧\u003c/h2\u003e\n\u003cp\u003eCIS 按级别定义了配置档。选对档位，才不会因为用力过猛而弄坏应用。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e配置档\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e目标\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e何时采用\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eLevel 1（L1）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e基础安全，对功能几乎没有影响\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e多数负载的起点\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eLevel 2（L2）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e面向敏感环境的纵深防御\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e受监管数据、高风险场景；可能需要调优\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSTIG\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e美国国防部的要求\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e政府或国防合同\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eCIS 加固配置档及其适用范围。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"如何在镜像里自动化加固\"\u003e如何在镜像里自动化加固\u003c/h2\u003e\n\u003cp\u003e手工加固既不可扩展，也无法审计。以下是把它纳入构建流水线最常见的三条路径：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eEC2 Image Builder 搭配 CIS 组件\u003c/strong\u003e：AWS 提供与托管 CIS 级别的集成，在构建过程中应用并\n校验基线，也可以选用 Marketplace 上的 CIS Hardened 镜像。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnsible 加一个加固角色\u003c/strong\u003e：在 Packer 的 provisioner 里复用面向 Linux 的 CIS 角色；这在\n各朵云之间都可移植。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e自己写幂等脚本\u003c/strong\u003e：适合特定场景，优点是完全掌控，缺点是要自己维护。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"不可或缺的高价值控制项\"\u003e不可或缺的高价值控制项\u003c/h2\u003e\n\u003cp\u003e如果必须排优先级，以下这些 CIS 控制项能以最低成本换来最大的风险下降：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e禁用 SSH 的 root 直连\u003c/strong\u003e，强制使用密钥登录，绝不用口令。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e移除不必要的软件包与服务\u003c/strong\u003e，缩小攻击面。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e配置主机防火墙\u003c/strong\u003e（firewalld 或 nftables），默认拒绝。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e启用审计\u003c/strong\u003e（\u003ccode\u003eauditd\u003c/code\u003e）与集中式事件日志。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e应用安全的内核参数\u003c/strong\u003e（\u003ccode\u003esysctl\u003c/code\u003e），防范欺骗与网络攻击。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e严格的口令策略与账户锁定。\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e关键文件的正确权限\u003c/strong\u003e：\u003ccode\u003e/etc/passwd\u003c/code\u003e、\u003ccode\u003e/etc/shadow\u003c/code\u003e 以及启动目录。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"验证加固是否真的生效\"\u003e验证加固是否真的生效\u003c/h2\u003e\n\u003cp\u003e只加固不验证，是一种信仰行为。请加入一个自动化验证阶段：对照基线给镜像打分，未达阈值就让\n构建失败。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eCIS-CAT、InSpec 或 OpenSCAP\u003c/strong\u003e 扫描刚烤好的实例，生成合规报告。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e通过阈值\u003c/strong\u003e：比如把「L1 控制项通过率 ≥ 95 %」设为质量门禁。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e审计证据\u003c/strong\u003e：把报告作为构建产物保存下来；下一次 SOC 2 或 ISO 审计时它就是真金白银。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"平衡点既安全又不弄坏应用\"\u003e平衡点：既安全，又不弄坏应用\u003c/h2\u003e\n\u003cp\u003e经典的错误是盲目套用 L2，然后发现应用启动不了。稳妥的策略是：从 L1 起步，做度量，再在预发\n环境中逐项验证、有选择地提升到 L2。为每一个合理的例外写下记录；带着书面理由关掉的控制项在\n审计中可以接受，悄悄关掉的则不行。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eCIS 加固会拖慢我的实例吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eL1 配置档对性能的影响几乎为零。L2 中某些高强度审计控制项可能带来额外开销，所以要有选择地\n应用并加以度量。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e我必须购买 CIS Hardened 镜像，还是可以自己来？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你完全可以自己加固——用 Ansible、OpenSCAP 或 EC2 Image Builder 的组件。Marketplace 上的\nCIS Hardened 镜像能省事，还自带验证，但并非必需。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e做了加固就等于符合 ISO 27001 或 PCI DSS 了吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e加固是一项重要的技术控制，但合规还涵盖流程、政策与证据。加固 AMI 让你离目标近得多，却不能\n替代合规框架的其余部分。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们从按业界良好实践加固过的镜像出发，让你在安全的基线上部署。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-09T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/cis%E5%8A%A0%E5%9B%BAec2-ami/","image":"https://www.imaxe.cloud/blog-covers/hardening-cis-ami-ec2_hu_8c72206698ec85fc.webp","language":"zh-Hans","summary":"一份未加固的镜像，就是一扇敞着的门，只等有人走进来。把 CIS 基线应用到你的 AMI，能一举抬高安全水位，也让你更接近合规。我们来讲讲怎么做，同时不拖慢团队。","tags":["安全","cis","加固","合规","inspec","安全"],"title":"AMI 的 CIS 加固：加固 EC2 镜像的实用指南","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/cis%E5%8A%A0%E5%9B%BAec2-ami/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/ciclo-de-vida-ami_hu_d04b0e8cea647c79.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/ciclo-de-vida-ami_hu_d04b0e8cea647c79.webp\" alt=\"拆开的硬盘盘片与磁头\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e很多团队把 AMI 当成「建一次就忘掉」的东西。问题会在几个月后浮现：几十份没有标签的镜像、没人\n敢确认能不能删的 EBS 快照，以及一张莫名其妙不断上涨的账单。管理 \u003cstrong\u003eAMI 的生命周期\u003c/strong\u003e，意味着把\n它当成一个软件产物来对待：有诞生、有版本、有成熟期、有弃用，也有退役。\u003c/p\u003e\n\u003cp\u003e良好的镜像治理能降低成本、提升安全——不会有人误启动一份一年前、没打补丁的镜像——并让合规审计\n变得轻松。\u003c/p\u003e\n\u003ch2 id=\"阶段一--有意义的版本管理\"\u003e阶段一 —— 有意义的版本管理\u003c/h2\u003e\n\u003cp\u003e版本管理是脊梁。没有它，「最新那份好用的 AMI」只是走廊里的口头约定，而不是可查的事实。我们\n建议采用一套可读且一致的方案。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e带版本的名称\u003c/strong\u003e：例如 \u003ccode\u003eimaxe-ubuntu22-nginx-2026.07.1\u003c/code\u003e，包含产品、基线与日历版本。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e必备标签\u003c/strong\u003e：\u003ccode\u003eVersion\u003c/code\u003e、\u003ccode\u003eGitCommit\u003c/code\u003e、\u003ccode\u003eBuildDate\u003c/code\u003e、\u003ccode\u003eOwner\u003c/code\u003e、\u003ccode\u003eEnvironment\u003c/code\u003e、\u003ccode\u003eCISLevel\u003c/code\u003e、\n\u003ccode\u003eStatus\u003c/code\u003e。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不可变：一个版本，一份产物。\u003c/strong\u003e 永远不要修改已发布的 AMI；创建新版本即可。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e中心化登记\u003c/strong\u003e：用 AWS Systems Manager Parameter Store 保存「当前生产 AMI」的 ID，让你的\nLaunch Template 按引用读取。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"阶段二--端到端加密\"\u003e阶段二 —— 端到端加密\u003c/h2\u003e\n\u003cp\u003eAMI 的数据存放在 EBS 快照里。如果没有加密，任何一份治理不善的副本都是潜在的泄露。加密应当是\n常态，而不是例外。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e默认加密\u003c/strong\u003e：在账户与区域层面开启 \u003cem\u003eEBS encryption by default\u003c/em\u003e。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e由你管理的密钥（CMK）\u003c/strong\u003e：使用自己的 KMS 密钥，而非 AWS 默认密钥，以掌控权限与轮换。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e复制即重新加密\u003c/strong\u003e：把 AMI 复制到另一个区域或账户时，顺势用目标密钥重新加密。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e用 KMS grant 共享\u003c/strong\u003e：把 AMI 分发给其他账户时，以最小权限策略授予密钥访问。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"阶段三--弃用先预警再删除\"\u003e阶段三 —— 弃用：先预警，再删除\u003c/h2\u003e\n\u003cp\u003eAWS 允许给 AMI 打上带日期的\u003cstrong\u003e弃用\u003c/strong\u003e（\u003cem\u003edeprecated\u003c/em\u003e）标记。从那一刻起，它在默认搜索中不再出现，\n但对显式引用它的人依然可用。这是「在用」与「已删除」之间那个体面的中间态：你发出了预警、给了\n迁移的余量，也不会弄坏别人的部署。\u003c/p\u003e\n\u003ch2 id=\"阶段四--自动清理以及快照的隐藏成本\"\u003e阶段四 —— 自动清理（以及快照的隐藏成本）\u003c/h2\u003e\n\u003cp\u003e钱就藏在这里。当你删除一份 AMI 时，它关联的 EBS 快照\u003cstrong\u003e并不会自动删除\u003c/strong\u003e。这正是存储账单神秘\n增长的头号原因。一套退役策略必须先注销 AMI，随后删除它留下的孤儿快照。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e保留策略\u003c/strong\u003e：保留最近 N 个版本（比如最近三个），其余退役。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e用云能力自动化\u003c/strong\u003e：Amazon Data Lifecycle Manager（DLM）可以按策略管理镜像的创建与删除。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e围猎孤儿快照\u003c/strong\u003e：定期审计没有关联 AMI 的快照并清除。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e绝不盲删\u003c/strong\u003e：退役前先确认没有活跃实例或 Launch Template 依赖这份 AMI。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"生命周期一览表\"\u003e生命周期一览表\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e阶段\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e关键动作\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e工具或服务\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e创建\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e可复现的构建与打标签\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePacker / EC2 Image Builder\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e加密\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e用 CMK 加密快照\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAWS KMS + EBS 默认加密\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e分发\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e跨区域或跨账户复制与重新加密\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAMI copy / AWS RAM\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e在用\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e登记当前 ID\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSSM Parameter Store\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e弃用\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e打上带日期的弃用标记\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eec2 enable-image-deprecation\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e退役\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e注销并删除快照\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDLM / 定时脚本\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eAMI 治理的六个阶段，以及如何把它们自动化。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"你应该盯住的指标\"\u003e你应该盯住的指标\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e在用 AMI 的\u003cstrong\u003e平均年龄\u003c/strong\u003e：越低，补丁越新。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e孤儿快照数量\u003c/strong\u003e及其每月成本。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e已加密 AMI 的比例\u003c/strong\u003e，目标是 100 %。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e从关键 CVE 到新镜像发布的时间\u003c/strong\u003e，也就是补丁的 MTTR。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e我都把 AMI 删了，为什么 EBS 账单还在涨？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e因为注销 AMI 并不会删除它的快照。你必须显式删除。定期审计孤儿快照；它们通常是最大的隐藏成本。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e把加密过的 AMI 共享给另一个账户安全吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e安全，只要你通过特定 grant、以最小权限授予对 KMS 密钥的访问。没有这份访问权限，目标账户根本\n无法启动该镜像。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一份 AMI 该保留多少个版本？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e取决于你的回滚需求与合规要求，但保留最近两到四个版本，通常是回滚保障与成本之间不错的平衡。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们的镜像从源头就带着版本管理与加密，好让它们的生命周期可预期、可审计。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-05T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F/","image":"https://www.imaxe.cloud/blog-covers/ciclo-de-vida-ami_hu_d04b0e8cea647c79.webp","language":"zh-Hans","summary":"创建一份 AMI 很容易；随时间治理它，才是专业团队与「孤儿镜像坟场加虚高账单」之间的分界线。这是一份让你无痛完成版本管理、加密与清理的完整指南。","tags":["运维","版本管理","kms","快照","治理","成本"],"title":"AMI 的生命周期：版本管理、加密与自动清理","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/ami%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/golden-ami-packer-pipeline_hu_cdeb95d898f689f8.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/golden-ami-packer-pipeline_hu_cdeb95d898f689f8.webp\" alt=\"机房里的服务器机柜\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eGolden AMI\u003c/strong\u003e（「黄金镜像」）是一份预先配置、加固并验证过的 Amazon Machine Image，作为启动\n一模一样 EC2 实例的唯一模板。与其每次都开一台空服务器、手工装依赖，不如把所有东西一次性\n「烘焙」进去——打好补丁的操作系统、各类代理、运行时、配置与安全控制——然后在每次部署中复用。\u003c/p\u003e\n\u003cp\u003e这套做法是\u003cstrong\u003e不可变基础设施\u003c/strong\u003e的基石：不给运行中的服务器热打补丁，而是构建新镜像、替换实例。\n结果是更少的配置漂移、自动伸缩时更快的启动，以及可审计、可回滚的部署。\u003c/p\u003e\n\u003ch2 id=\"golden-ami-与启动时引导配置的对比\"\u003eGolden AMI 与启动时引导配置的对比\u003c/h2\u003e\n\u003cp\u003e有两种哲学。在**引导配置（bootstrapping）**里，实例在启动时才配置自己（user-data、Ansible\npull、cloud-init）。这很灵活，但慢且脆弱：软件包仓库一挂，你的自动伸缩就失败。在\n**golden AMI（烘焙）**模型里，重活只在流水线里干一次；启动几乎是瞬时且确定的。多数成熟团队\n两者兼用：把稳定的部分烘焙进去，只把随环境变化的配置留到启动时处理。\u003c/p\u003e\n\u003ch2 id=\"为什么用-packer\"\u003e为什么用 Packer\u003c/h2\u003e\n\u003cp\u003eHashiCorp 的 Packer 是从单一模板自动化、跨云构建机器镜像的事实标准工具。你把镜像定义成代码\n（HCL2）；它会启动一台临时实例、执行你的 provisioner、创建 AMI，然后销毁临时资源。同一份\n模板可以为 AWS、Azure 与 GCP 产出镜像，因此当你在多朵云上发布时尤其合适。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e可复现\u003c/strong\u003e：镜像被描述在一个纳入 Git 版本管理的文件里。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e多云\u003c/strong\u003e：一条流程同时覆盖 AMI、Azure Managed Image 与 GCP Custom Image。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e易集成\u003c/strong\u003e：能嵌入 CI/CD（GitHub Actions、GitLab CI、CodePipeline）。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e可审计\u003c/strong\u003e：每次构建都有记录，附带 manifest 与产物。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"一份-packer-模板hcl2的解剖\"\u003e一份 Packer 模板（HCL2）的解剖\u003c/h2\u003e\n\u003cp\u003e现代模板由若干块组成。\u003cstrong\u003esource\u003c/strong\u003e 块定义 builder（例如 \u003ccode\u003eamazon-ebs\u003c/code\u003e）、基础 AMI、实例类型与\n区域。\u003cstrong\u003ebuild\u003c/strong\u003e 块把安装与配置软件的 \u003cstrong\u003eprovisioner\u003c/strong\u003e 串起来。\u003cstrong\u003epost-processor\u003c/strong\u003e 则生成诸如\n带有产出 AMI ID 的 JSON manifest 之类的产物。\u003c/p\u003e\n\u003ch3 id=\"一个带注释的最小示例\"\u003e一个带注释的最小示例\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003esource \u0026quot;amazon-ebs\u0026quot; \u0026quot;app\u0026quot;\u003c/code\u003e —— 以官方基础 AMI 为起点，通过 \u003ccode\u003edata \u0026quot;amazon-ami\u0026quot;\u003c/code\u003e 按所有者与\n名称模式动态查找，避免写死一个终将失效的 ID。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eprovisioner \u0026quot;shell\u0026quot;\u003c/code\u003e —— 执行安装与更新脚本（\u003ccode\u003ednf update -y\u003c/code\u003e、安装运行时、CloudWatch 代理、\nSSM 代理）。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eprovisioner \u0026quot;ansible\u0026quot;\u003c/code\u003e —— 如果你已经有 Ansible 角色，直接复用它们，以幂等方式配置镜像。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003epost-processor \u0026quot;manifest\u0026quot;\u003c/code\u003e —— 写出 \u003ccode\u003emanifest.json\u003c/code\u003e，其中的 \u003ccode\u003eartifact_id\u003c/code\u003e 会被你的流水线\n读取，用来确认诞生的是哪一份 AMI。\u003c/p\u003e\n\u003ch2 id=\"流水线分步拆解\"\u003e流水线分步拆解\u003c/h2\u003e\n\u003cp\u003e以下是我们推荐的流程，让一份 golden AMI 安全、可重复地从提交走到生产：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e步骤\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e发生了什么\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e常用工具\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e1. Commit\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e修改模板或脚本并推送到 Git\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGit / PR 评审\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e2. Validate\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003epacker fmt\u003c/code\u003e + \u003ccode\u003epacker validate\u003c/code\u003e 校验语法\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePacker、CI\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e3. Build\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePacker 启动临时实例并执行 provisioner\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePacker\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e4. Harden\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e应用 CIS 基线并清理凭据\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAnsible / CIS\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e5. Scan\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e漏洞与机密扫描\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eTrivy、Inspector\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e6. Test\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e启动一台实例并做验证\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eInSpec / Goss\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e7. Tag \u0026amp; version\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e给 AMI 打标签（版本、提交、日期）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAWS CLI\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e8. Distribute\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e共享或复制到其他区域与账户\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAWS RAM / copy\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e9. Deploy\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e在 Launch Template 中引用该 AMI\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eTerraform / ASG\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003egolden AMI 流水线的九阶段参考流程。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"真正拉开差距的实践\"\u003e真正拉开差距的实践\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e绝不要用 ID 写死基础 AMI\u003c/strong\u003e：按所有者与名称动态查找，才能始终继承最新的补丁。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e给镜像做版本管理\u003c/strong\u003e，采用清晰的方案（例如 \u003ccode\u003eapp-2026.07.1\u003c/code\u003e），并把 Git 提交号写进 AMI 标签。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e封存前先清理\u003c/strong\u003e：删除日志、shell 历史、临时 SSH 密钥与软件包缓存，避免机密外泄。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e务必扫描\u003c/strong\u003e：集成 Trivy 或 Amazon Inspector，别把已知 CVE 发布出去。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e加密快照\u003c/strong\u003e：从第一分钟起就用你自己的 KMS 密钥。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e自动化淘汰\u003c/strong\u003e：把旧版本标记为弃用并删除，以控制成本。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"packer-还是-ec2-image-builder该选哪个\"\u003ePacker 还是 EC2 Image Builder，该选哪个？\u003c/h2\u003e\n\u003cp\u003e如果你只在 AWS 上工作，看重与 Inspector 的原生集成、托管的 CIS 组件，以及零维护基础设施，\n\u003cstrong\u003eEC2 Image Builder\u003c/strong\u003e 是一个稳妥且无许可成本的选择。如果你需要从同一份模板为多朵云构建，\n或者已经在用 HashiCorp 生态（Terraform、Vault），\u003cstrong\u003ePacker\u003c/strong\u003e 会带来更强的可移植性。两者并不\n互斥：许多团队用 Packer 处理多云逻辑，用 Image Builder 跑内部的 AWS 流水线。\u003c/p\u003e\n\u003ch2 id=\"常见问题\"\u003e常见问题\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eGolden AMI 该多久重建一次？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e至少跟随操作系统的补丁周期（每月通常是不错的节奏），并在你的技术栈出现关键 CVE 时立即重建。\n有了自动化流水线，按需重建只需几分钟。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e同一份 Packer 模板能同时用于 AWS 和 Azure 吗？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e可以。Packer 支持在一次构建中使用多个 builder。你共享 provisioner，只需替换每朵云的 source\n块，就能并行产出 AMI、Managed Image 与 Custom Image。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGolden AMI 还是容器？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这不是二选一。Golden AMI 适合宿主机层以及尚未容器化的负载；容器则跑在它之上。事实上，一份\n加固过的 golden AMI，正是 Kubernetes 节点的绝佳基线。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e在 imaxe.cloud，我们构建并维护加固且保持更新的基础镜像，让你的流水线从可靠的地基起步。\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-06-02T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/golden-ami-packer%E6%B5%81%E6%B0%B4%E7%BA%BF/","image":"https://www.imaxe.cloud/blog-covers/golden-ami-packer-pipeline_hu_cdeb95d898f689f8.webp","language":"zh-Hans","summary":"一份构建良好的 golden AMI，决定了你是几秒钟内胸有成竹地上线，还是跟一堆永远不一样的服务器缠斗。本篇技术指南带你搭起一条可复现、可上生产的 Packer 流水线。","tags":["指南","packer","golden ami","aws","ci/cd","不可变基础设施"],"title":"用 Packer 打造 Golden AMI：一步步搭出可复现的流水线","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/golden-ami-packer%E6%B5%81%E6%B0%B4%E7%BA%BF/"},{"authors":[{"name":"imaxe 团队","url":"https://www.imaxe.cloud/"}],"banner_image":"https://www.imaxe.cloud/blog-covers/zabbix-7-lts_hu_a2d5ca0fc6cd5b29.webp","content_html":"\u003cp\u003e\u003cimg src=\"https://www.imaxe.cloud/blog-covers/zabbix-7-lts_hu_a2d5ca0fc6cd5b29.webp\" alt=\"控制室里的诊断监视器\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e","date_modified":"2026-08-22T15:25:49Z","date_published":"2026-05-28T00:00:00Z","id":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/zabbix-7-lts/","image":"https://www.imaxe.cloud/blog-covers/zabbix-7-lts_hu_a2d5ca0fc6cd5b29.webp","language":"zh-Hans","summary":"焕新的前端、SLA 小组件和重写的 SQS 读取器。我们梳理新 LTS 线的新特性，以及如何从 6.0 迁移而不丢失历史数据。","tags":["动态"],"title":"Zabbix 7.0 LTS 现已上线：我们的 AMI 有何变化","url":"https://www.imaxe.cloud/zh/%E5%8D%9A%E5%AE%A2/zabbix-7-lts/"}],"language":"zh-Hans","title":"imaxe.cloud · 博客","version":"https://jsonfeed.org/version/1.1"}