{"authors":[{"name":"imaxe team","url":"https://www.imaxe.cloud/"}],"description":"Engineering notes, catalog news and practical guides from the imaxe.cloud team.","favicon":"https://www.imaxe.cloud/favicon.ico","feed_url":"https://www.imaxe.cloud/en/blog/feed.json","home_page_url":"https://www.imaxe.cloud/en/blog/","icon":"https://www.imaxe.cloud/assets/icon-512.png","items":[{"authors":[{"name":"imaxe team","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=\"Microscopic detail of a processor's silicon\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eEvery AMI is built for one specific CPU architecture: x86_64 (Intel or AMD) or ARM64\n(aarch64, the one behind AWS Graviton and its equivalents). There is no image that\n\u0026ldquo;works for both\u0026rdquo;: they are different binaries. So when we put our catalogue together, we\nhad to decide which one would be the default.\u003c/p\u003e\n\u003cp\u003eWe looked at cost, performance, efficiency, ecosystem maturity and where the market is\nheading. The conclusion was clear: \u003cstrong\u003eARM64 is today the best bet for most workloads.\u003c/strong\u003e\nAnd that is how we build our images.\u003c/p\u003e\n\u003ch2 id=\"why-arm64-wins-for-most-people\"\u003eWhy ARM64 wins for most people\u003c/h2\u003e\n\u003ch3 id=\"1-better-price-performance\"\u003e1. Better price-performance\u003c/h3\u003e\n\u003cp\u003eThis is the decisive argument. ARM (Graviton) instances consistently deliver \u003cstrong\u003emore\nperformance per euro\u003c/strong\u003e than their x86 equivalents across a wide range of workloads: web,\nAPIs, microservices, containers, databases and queues. In practice, moving to ARM\nusually translates into savings in the order of \u003cstrong\u003e20 % to 40 %\u003c/strong\u003e on compute cost. In a\ncloud that keeps getting more expensive, that margin is too big to ignore.\u003c/p\u003e\n\u003ch3 id=\"2-more-efficiency-less-energy\"\u003e2. More efficiency, less energy\u003c/h3\u003e\n\u003cp\u003eARM processors were born optimising power consumption. That means more work per watt,\nlower energy cost and a \u003cstrong\u003esmaller carbon footprint\u003c/strong\u003e per unit of compute. If\nsustainability is part of your goals —or your customers\u0026rsquo;— ARM plays in your favour.\u003c/p\u003e\n\u003ch3 id=\"3-the-ecosystem-is-already-mature\"\u003e3. The ecosystem is already mature\u003c/h3\u003e\n\u003cp\u003eA few years ago, \u0026ldquo;will it have an ARM version?\u0026rdquo; was a legitimate question. Today the\nvast majority of server software —operating systems, languages, runtimes, databases,\npopular container images— has first-class ARM64 support. Compatibility stopped being the\nexception and became the norm.\u003c/p\u003e\n\u003ch3 id=\"4-same-security-same-operating-model\"\u003e4. Same security, same operating model\u003c/h3\u003e\n\u003cp\u003eChanging architecture does not change how you work: configuration, hardening, cloud-init,\nyour provisioning scripts and your pipeline are all the same. ARM64 does not ask you to\ngive up anything in your operations or your security posture.\u003c/p\u003e\n\u003ch2 id=\"the-comparison-in-one-table\"\u003eThe comparison, in one table\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eCriterion\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\u003ePrice-performance\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSuperior on most workloads\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGood, but pricier per unit\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eEnergy efficiency\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVery high\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLower\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSoftware compatibility\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eExcellent and broad today\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMaximum, universal\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eLegacy proprietary binaries\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSometimes no ARM build\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFull support\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eMarket direction\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGrowing and strategic\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eConsolidated\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eTypical cost\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLower: between 20 % and 40 %\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHigher\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eFor modern workloads, ARM64 wins where it matters most: cost, efficiency and future.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"when-x86_64-still-makes-sense\"\u003eWhen x86_64 still makes sense\u003c/h2\u003e\n\u003cp\u003eBeing honest is part of choosing well. There are cases where x86_64 is still the right\ncall, and we do not want anyone forcing a migration that makes life harder:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eProprietary software or binaries\u003c/strong\u003e that only exist compiled for x86.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNative dependencies\u003c/strong\u003e —compiled extensions— with no ARM build available.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLegacy tools\u003c/strong\u003e or third-party integrations tied to x86.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVery specific workloads\u003c/strong\u003e hand-optimised for x86 instructions.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"our-decision-arm64-by-default-x86_64-on-request\"\u003eOur decision: ARM64 by default, x86_64 on request\u003c/h2\u003e\n\u003cp\u003eFor all of the above, \u003cstrong\u003eour AMIs are built on ARM64 by default.\u003c/strong\u003e We believe that is what\nbrings most value to most people: you pay less for the same work, you consume less energy\nand you ride the architecture that is setting the cloud\u0026rsquo;s direction.\u003c/p\u003e\n\u003cp\u003eBut we know not every workload fits. That is why, \u003cstrong\u003eif you need x86_64, all you have to\ndo is ask: we will prepare a custom image\u003c/strong\u003e with the same configuration, the same\nhardening and the same quality, built for x86_64. Same product, same base, the\narchitecture your case requires.\u003c/p\u003e\n\u003ch2 id=\"how-to-decide-in-30-seconds\"\u003eHow to decide in 30 seconds\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eModern stack —web, API, containers, interpreted languages, common databases—:\n\u003cstrong\u003eARM64\u003c/strong\u003e, no hesitation.\u003c/li\u003e\n\u003cli\u003eDo you have a proprietary binary or a dependency that only runs on x86? \u003cstrong\u003eAsk us for\nthe x86_64 variant.\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eNot sure? Start on ARM64 and try it; if something does not fit, we build the x86_64\none and that is that.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eAre your AMIs ARM64 or x86_64?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBy default we build them on ARM64 (Graviton), because it offers the best\nprice-performance for most workloads. If you need x86_64, we prepare a custom one with\nthe same configuration and quality.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDo I have to change my application to use ARM64?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIn most cases, no. Interpreted languages and modern software run on ARM unchanged. There\nis only friction with proprietary binaries or native dependencies with no ARM version;\nin those cases we offer you the x86_64 variant.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow do I request a custom x86_64 image?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eJust ask. We start from the same base and the same hardening and build the image for\nx86_64, so you get exactly the same product on the architecture you need.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAm I really going to save with ARM64?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eFor suitable workloads, savings of 20 % to 40 % on compute cost are common, on top of\nlower energy consumption. The way to confirm it for your specific case is to run your\nworkload and compare.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we bet on ARM64 because we believe it is best for your bill, your\nperformance and the planet. And if you need x86_64, all you have to do is ask: we build\nyou a custom one.\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/en/blog/arm64-by-default/","image":"https://www.imaxe.cloud/blog-covers/arm64-por-defecto_hu_99c180b1a81b7f6a.webp","language":"en","summary":"When we designed our images we had to pick a default architecture. We thought it through, measured, and settled on ARM64. Here is why we believe it is the best option for most people, and why —if you need x86_64— all you have to do is ask.","tags":["news","arm64","graviton","x86_64","architecture","custom"],"title":"ARM64 by default: why we build our AMIs on Graviton","url":"https://www.imaxe.cloud/en/blog/arm64-by-default/"},{"authors":[{"name":"imaxe team","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=\"Pocket stopwatch on a black background\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eAn image\u0026rsquo;s size and boot time look like technical details, but they hit three things the\nbusiness does care about: \u003cstrong\u003eautoscaling speed\u003c/strong\u003e —how long you take to answer a spike—,\n\u003cstrong\u003ecost\u003c/strong\u003e —storage and idle compute waiting for boot— and \u003cstrong\u003esecurity\u003c/strong\u003e: less software\nmeans less attack surface.\u003c/p\u003e\n\u003cp\u003eA slim, fast image is almost always a better image.\u003c/p\u003e\n\u003ch2 id=\"slimming-the-image-less-is-more\"\u003eSlimming the image: less is more\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eStart from a minimal base\u003c/strong\u003e: use \u003cem\u003eminimal\u003c/em\u003e variants of the operating system rather\nthan full installs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInstall only what you need\u003c/strong\u003e: every extra package is weight, maintenance and attack\nsurface.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClean up after building\u003c/strong\u003e: delete package caches (\u003ccode\u003ednf clean all\u003c/code\u003e, \u003ccode\u003eapt-get clean\u003c/code\u003e),\nlogs, documentation and temporary files before sealing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRemove build tools\u003c/strong\u003e: if you compiled something, strip out compilers and development\ndependencies.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReview the volume size\u003c/strong\u003e: do not drag a 100 GB disk around if your software takes 8.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"speeding-up-boot\"\u003eSpeeding up boot\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eBake, do not install at boot\u003c/strong\u003e: everything you install in user-data is boot time;\nmove it into the image.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMinimal services at start\u003c/strong\u003e: disable whatever you do not need on the first boot.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePreload dependencies\u003c/strong\u003e: drivers, runtimes and base containers already present avoid\ninitial downloads.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOptimise cloud-init\u003c/strong\u003e: a small, idempotent user-data boots sooner.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSnapshots and provisioning\u003c/strong\u003e: use the cloud\u0026rsquo;s options to hydrate volumes faster.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"the-impact-in-numbers\"\u003eThe impact, in numbers\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eLever\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eEffect on autoscaling\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eEffect on cost and security\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\u003eSmaller image\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFaster copies and launches\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLower snapshot cost, fewer CVEs\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eFaster boot\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eYou answer spikes sooner\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLess compute paid without serving\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eFewer packages\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLess to load and initialise\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eReduced attack surface\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eOptimising the image improves performance, cost and security at the same time.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"do-not-overshoot\"\u003eDo not overshoot\u003c/h2\u003e\n\u003cp\u003eOptimising is not amputating. Cutting too much can break subtle dependencies or make\ndebugging harder. The right discipline: measure size and boot time as part of your\npipeline, trim with judgement, always validate in staging, and document what you removed\nand why. Treat these metrics as image quality indicators, not as an obsession.\u003c/p\u003e\n\u003ch2 id=\"optimisation-checklist\"\u003eOptimisation checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMinimal operating system base.\u003c/li\u003e\n\u003cli\u003eOnly the indispensable packages.\u003c/li\u003e\n\u003cli\u003eCleanup of caches, logs and temporary files before sealing.\u003c/li\u003e\n\u003cli\u003eNo build tools in the final image.\u003c/li\u003e\n\u003cli\u003eSmall user-data; the heavy lifting baked in.\u003c/li\u003e\n\u003cli\u003eVolume size matched to reality.\u003c/li\u003e\n\u003cli\u003eSize and boot metrics in the pipeline.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eHow much faster can boot get by optimising the image?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt depends on the starting point, but moving installations out of user-data and into the\nimage, plus reducing initial services, usually cuts boot time noticeably, which directly\nimproves how quickly your autoscaling responds.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs a smaller image more secure?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eGenerally yes: less installed software means fewer potential vulnerabilities and a\nsmaller attack surface, plus it is easier to audit.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs a minimal OS worth it?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eFor most server workloads, yes: it boots sooner, takes less space and is more secure.\nJust avoid minimising so far that you hamper diagnostics or break dependencies you\ngenuinely need.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we make sure our images are light, quick to boot and easy to maintain.\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/en/blog/optimize-ami-size-and-boot-time/","image":"https://www.imaxe.cloud/blog-covers/optimizar-tamano-arranque-ami_hu_69b1788d3fbcbc6c.webp","language":"en","summary":"A bloated image boots slowly, costs more to store and widens your attack surface. Slimming your AMIs and speeding up their boot improves your autoscaling, your bill and your security in one move. Here is how.","tags":["operations","performance","boot","cost","autoscaling","minimal image"],"title":"Shrink the size and boot time of your AMIs","url":"https://www.imaxe.cloud/en/blog/optimize-ami-size-and-boot-time/"},{"authors":[{"name":"imaxe team","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=\"Graphics card with its heatsink and fans\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eWith AI in production as the big theme of 2026, more and more teams are launching GPU\ninstances to train and run inference on models. But a GPU does not work on its own: it\nneeds a very specific software stack —\u003cstrong\u003eNVIDIA driver, CUDA, cuDNN, frameworks\u003c/strong\u003e— with\nversions that must line up with each other. Preparing all of that by hand on every\ninstance is slow and fragile.\u003c/p\u003e\n\u003cp\u003eHence the value of a \u003cstrong\u003eGPU-ready image\u003c/strong\u003e: it encapsulates that validated stack once and\nboots ready to work.\u003c/p\u003e\n\u003ch2 id=\"what-an-ai-ami-should-carry\"\u003eWhat an AI AMI should carry\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eNVIDIA driver\u003c/strong\u003e compatible with the target GPU, for instance those in the accelerated\ninstance families.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCUDA and cuDNN\u003c/strong\u003e in versions aligned with the frameworks you plan to use.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFrameworks\u003c/strong\u003e such as PyTorch or TensorFlow or, better still, the \u003cstrong\u003eNVIDIA Container\nToolkit\u003c/strong\u003e to run them in containers.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMLOps tooling\u003c/strong\u003e and GPU monitoring, for example DCGM, preinstalled.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBoot optimisation\u003c/strong\u003e: preloaded drivers so you do not lose minutes —and GPU money— on\nevery launch.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"build-or-use-a-ready-made-image\"\u003eBuild or use a ready-made image\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eOption\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eAdvantage\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eTrade-off\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\u003eOfficial GPU image (NVIDIA GPU-Optimized, Deep Learning)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eValidated, maintained stack\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLess control over versions\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCustom image\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFull control of versions and hardening\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMaintenance on you\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eGPU containers on a base AMI\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePortability and reproducibility\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNeeds the toolkit and driver-equipped nodes\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eChoose according to how much version control and maintenance you want to take on.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"cost-rules-the-gpu-is-expensive\"\u003eCost rules: the GPU is expensive\u003c/h2\u003e\n\u003cp\u003eGPU time is the most expensive resource on your AI bill, and reducing \u003cstrong\u003eidle GPU\u003c/strong\u003e is one\nof 2026\u0026rsquo;s priorities. The image directly influences this:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFast boot\u003c/strong\u003e: an image with drivers and dependencies already in place avoids minutes\nof paid GPU doing nothing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGPU containers\u003c/strong\u003e: package the model environment to reproduce it instantly on any\ndriver-equipped node.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEdge inference\u003c/strong\u003e: lightweight images to bring models close to the data and cut\nlatency and cost.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eScaling and spot\u003c/strong\u003e: combine ready images with spot instances to cheapen\ninterruption-tolerant workloads.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"best-practices\"\u003eBest practices\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePin and document the \u003cstrong\u003eversions\u003c/strong\u003e of driver, CUDA and framework: compatibility is\nbrittle.\u003c/li\u003e\n\u003cli\u003eKeep the image \u003cstrong\u003eup to date\u003c/strong\u003e with driver and operating system security patches.\u003c/li\u003e\n\u003cli\u003eSeparate the \u003cstrong\u003eplatform layer\u003c/strong\u003e —driver, toolkit— from the \u003cstrong\u003emodel layer\u003c/strong\u003e —the\ncontainer— so you can iterate fast.\u003c/li\u003e\n\u003cli\u003eMeasure the \u003cstrong\u003ecost per inference\u003c/strong\u003e and tune image and instance accordingly.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eShould I use an official Deep Learning AMI or build my own?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eOfficial GPU images save an enormous amount of time and come with a validated stack.\nBuild your own if you need specific versions, particular hardening or strict compliance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhy does fast boot matter so much on GPUs?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBecause the GPU is the most expensive resource: every minute a GPU instance spends\nbooting and installing drivers is money paid for nothing. An image with everything\npreinstalled cuts that waste.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eContainers or direct installation for GPU AI?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eGPU containers, with the NVIDIA Container Toolkit, bring reproducibility and portability,\nand are the recommended practice. They need the node to carry the driver, which a good\nbase AMI solves.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we follow the evolution of AI workloads closely so our images spare you\ndriver hell and slow boots.\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/en/blog/ai-gpu-images-2026/","image":"https://www.imaxe.cloud/blog-covers/imagenes-ia-gpu-2026_hu_57244b43363ee40d.webp","language":"en","summary":"Assembling a GPU-based AI environment by hand is a festival of drivers, CUDA versions and frameworks that refuse to line up. A well-prepared GPU image saves you days of pain. Here is what an AI AMI should carry in 2026.","tags":["news","ai","gpu","nvidia","cuda","mlops"],"title":"Machine images for AI and GPUs in 2026: what changes when GPUs enter the picture","url":"https://www.imaxe.cloud/en/blog/ai-gpu-images-2026/"},{"authors":[{"name":"imaxe team","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 chip mounted on a motherboard\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eARM-based processors, such as the \u003cstrong\u003eAWS Graviton\u003c/strong\u003e family, have become a first-class\noption for production workloads. Their pitch is simple and powerful: \u003cstrong\u003ebetter\nprice-performance\u003c/strong\u003e than traditional x86 alternatives for many workloads, with lower\npower consumption.\u003c/p\u003e\n\u003cp\u003eIn a cloud landscape that keeps getting more expensive —one of the big trends of 2026—\nmigrating to ARM is one of the most effective savings levers inside a FinOps strategy.\u003c/p\u003e\n\u003ch2 id=\"how-much-can-you-save\"\u003eHow much can you save\u003c/h2\u003e\n\u003cp\u003eThe numbers vary by workload, but the industry consistently reports meaningful savings\nwhen moving to Graviton, in the order of \u003cstrong\u003e20 % to 40 %\u003c/strong\u003e on compute cost for suitable\nworkloads, thanks to a better price per vCPU and greater efficiency. It is not magic:\nyou have to validate it with your real workload, but the potential is large and it is\noften money left on the table.\u003c/p\u003e\n\u003ch2 id=\"what-migrates-well-and-what-needs-care\"\u003eWhat migrates well and what needs care\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eMigrates well\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eNeeds validation\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\u003eInterpreted languages: Python, Node, Java, Go\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eBinaries compiled for x86 only\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eContainers with multi-architecture images\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNative dependencies with no ARM build\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eWeb, APIs and microservices\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eProprietary software with no ARM version\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCommon databases and caches\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSpecific drivers or extensions\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eMost modern workloads migrate without drama; watch out for native dependencies.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"the-role-of-multi-architecture-images\"\u003eThe role of multi-architecture images\u003c/h2\u003e\n\u003cp\u003eThe key to a clean migration is building your images for \u003cstrong\u003eboth architectures\u003c/strong\u003e, x86_64\nand arm64. In the container world, \u003cem\u003emulti-arch\u003c/em\u003e images let the same tag work on either\none. In the AMI world, it pays to have your pipeline —Packer or EC2 Image Builder—\nready to produce the arm64 image alongside the x86 one, reusing the same provisioners.\u003c/p\u003e\n\u003ch2 id=\"a-five-step-migration-plan\"\u003eA five-step migration plan\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInventory\u003c/strong\u003e your workloads and spot dependencies that may have no ARM version.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBuild arm64 images\u003c/strong\u003e in your pipeline, in parallel with the x86 ones.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTest\u003c/strong\u003e in staging: performance, compatibility and functional results.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMigrate in phases\u003c/strong\u003e with canary or blue/green, measuring real cost and performance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOptimise\u003c/strong\u003e: match the Graviton instance type to the workload profile.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"arm-on-azure-and-gcp-too\"\u003eARM on Azure and GCP too\u003c/h2\u003e\n\u003cp\u003eThe trend is not AWS-only. Azure offers ARM-based machines —Cobalt and partner ones—\nand Google Cloud has ARM instances such as Axion and Tau T2A. If you design your images\nas code and for multiple architectures, you earn the freedom to chase the best\nprice-performance on any cloud.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eExactly how much will I save with Graviton?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt depends on your workload, but savings of 20 % to 40 % on compute cost are common for\nsuitable workloads. The only way to know for sure is to run your real workload on ARM\ninstances and compare.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDo I have to rewrite my application for ARM?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eRarely. Interpreted languages and most modern software run on ARM unchanged. The work\nshows up with binaries compiled for x86 only or native dependencies with no ARM build.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCan I have images that work on x86 and ARM at the same time?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYes: with multi-architecture container images and AMI pipelines that produce both\nvariants. That way you migrate gradually and never get stuck.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we design our images to make the most of each architecture and help you\noptimise cost and performance.\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/en/blog/arm-graviton-savings/","image":"https://www.imaxe.cloud/blog-covers/arm-graviton-ahorro_hu_564873198e07c9a3.webp","language":"en","summary":"ARM stopped being a phone thing a long time ago: today it powers a huge share of the cloud and offers a price-performance ratio that is hard to ignore. Migrating your images to Graviton can trim your bill noticeably. Here is how, and with what care.","tags":["guides","arm","graviton","arm64","finops","multi-architecture"],"title":"ARM and Graviton: migrate your images and cut your cloud bill","url":"https://www.imaxe.cloud/en/blog/arm-graviton-savings/"},{"authors":[{"name":"imaxe team","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=\"Point lever beside a railway track\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eChanging the AMI your instances use is like changing the foundation of your service while\nit keeps running. Done badly it means outages; done well it is nearly invisible to the\nuser. The good news: there are proven patterns that make this migration safe and\nreversible.\u003c/p\u003e\n\u003cp\u003eThe common basis is not to edit live instances, but to \u003cstrong\u003elaunch new instances with the\nnew AMI\u003c/strong\u003e and shift traffic in a controlled way.\u003c/p\u003e\n\u003ch2 id=\"before-migrating-prepare-the-ground\"\u003eBefore migrating: prepare the ground\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eTest the new AMI\u003c/strong\u003e in a staging environment identical to production.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReliable health checks\u003c/strong\u003e: define checks that confirm a new instance is genuinely\nhealthy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRollback plan\u003c/strong\u003e: have the previous version and the procedure to return to it ready.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eObservability\u003c/strong\u003e: metrics and alerts to spot regressions instantly.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"zero-downtime-migration-strategies\"\u003eZero-downtime migration strategies\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eStrategy\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eHow it works\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eIdeal for\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\u003eRolling update\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eReplaces instances in batches, little by little\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eServices in an 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\u003eBlue/Green\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eYou stand up a new environment and switch traffic at once\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMigrations with instant rollback\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCanary\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eYou send a small percentage of traffic to the new version\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eValidating in production at low risk\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eThree patterns for changing AMIs without interrupting the service.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"rolling-update\"\u003eRolling update\u003c/h3\u003e\n\u003cp\u003eYou update the Launch Template with the new AMI and the Auto Scaling Group replaces\ninstances in waves: it launches new ones, waits for them to pass the health check and\nretires the old ones. Simple and with no extra infrastructure, although both versions\ncoexist for a while.\u003c/p\u003e\n\u003ch3 id=\"bluegreen\"\u003eBlue/Green\u003c/h3\u003e\n\u003cp\u003eYou stand up a parallel environment (\u003cem\u003egreen\u003c/em\u003e) with the new AMI while the current one\n(\u003cem\u003eblue\u003c/em\u003e) keeps serving. Once green is validated, you redirect traffic at the load\nbalancer or in DNS. If anything fails, you are back on blue in seconds. It is the pattern\nwith the fastest rollback, at the cost of temporarily duplicating resources.\u003c/p\u003e\n\u003ch3 id=\"canary\"\u003eCanary\u003c/h3\u003e\n\u003cp\u003eYou send a small fraction of traffic to instances with the new AMI and observe. If the\nmetrics hold, you raise the percentage progressively up to 100 %. It minimises the blast\nradius of an unexpected problem.\u003c/p\u003e\n\u003ch2 id=\"after-migrating\"\u003eAfter migrating\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eWatch metrics and logs for a reasonable period before declaring the migration good.\u003c/li\u003e\n\u003cli\u003eMark the old AMI as \u003cstrong\u003edeprecated\u003c/strong\u003e so it is not relaunched by mistake.\u003c/li\u003e\n\u003cli\u003eDocument the deployed version and the reason for the change.\u003c/li\u003e\n\u003cli\u003eDo not delete the previous image immediately: keep it in case you need a rollback.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eWhich strategy is best for zero downtime?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBlue/Green offers the fastest rollback; rolling update is simpler and cheaper; canary\nminimises risk by validating in production. The choice depends on your risk tolerance and\nyour infrastructure budget.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDo I need to duplicate the infrastructure to migrate?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eOnly with blue/green, and temporarily. With rolling update or canary you reuse the same\ngroup and replace instances as you go, without duplicating the whole environment.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow do I guarantee I can go back?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eKeep the previous AMI and its Launch Template, define reliable health checks and have the\nrollback procedure tested before starting the migration.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we version our images so that migrating between versions is predictable\nand reversible.\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/en/blog/migrate-ami-without-downtime/","image":"https://www.imaxe.cloud/blog-covers/migrar-ami-sin-downtime_hu_1ed2f0ccb833f256.webp","language":"en","summary":"Updating the image that holds up your service does not have to mean a sleepless night or a maintenance page. With the right strategy you switch AMIs with zero downtime and a reverse gear always within reach.","tags":["operations","blue/green","rolling update","canary","auto scaling","deployment"],"title":"How to migrate to a new AMI without service interruptions","url":"https://www.imaxe.cloud/en/blog/migrate-ami-without-downtime/"},{"authors":[{"name":"imaxe team","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=\"Euro coins and banknotes on a table\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eWhen you launch an instance from an AMI, on top of the compute cost —the EC2 instance—\nthere may be a cost attached to the image\u0026rsquo;s \u003cstrong\u003esoftware\u003c/strong\u003e. That cost is structured mainly\nin three models: free (open source), hourly pricing bundled with the instance, and BYOL\n(bring your own licence).\u003c/p\u003e\n\u003cp\u003eUnderstanding the difference avoids surprises on the bill and licence compliance\nheadaches.\u003c/p\u003e\n\u003ch2 id=\"the-models-clearly\"\u003eThe models, clearly\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eModel\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eHow you pay\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eMain advantage\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\u003eFree or open source\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eYou only pay for the instance\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMinimum cost, no software licence\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eHourly pricing (PAYG)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eThe software is billed per hour of use\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNo commitment: scale up and shut down\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\u003eYou reuse a licence you already own\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eYou leverage prior investment and keep control\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eThe three software cost models in a machine image.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"hourly-pricing-flexibility-above-all\"\u003eHourly pricing: flexibility above all\u003c/h2\u003e\n\u003cp\u003eIn the pay-as-you-go model, the software cost is added to the instance cost and billed\nper hour or second of use. It is ideal when your workload is variable or unpredictable:\nno upfront commitment, you scale when you need to and stop paying when you shut down. The\ntrade-off is that with intensive, constant usage it can end up pricier in the long run\nthan amortising your own licence.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFor\u003c/strong\u003e: zero upfront investment, full elasticity, maintenance and support often\nincluded.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgainst\u003c/strong\u003e: an hourly cost that, added up 24/7, can exceed an amortised licence.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"byol-make-the-most-of-what-you-already-have\"\u003eBYOL: make the most of what you already have\u003c/h2\u003e\n\u003cp\u003eWith \u003cstrong\u003eBring Your Own License\u003c/strong\u003e you reuse a licence you already own —for instance, from\nan enterprise agreement— on a cloud image. It can cut costs if you have already invested\nin licences, but it comes with responsibilities: you must comply with the vendor\u0026rsquo;s terms,\nwatch the licence\u0026rsquo;s portability to the cloud and manage compliance yourself.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFor\u003c/strong\u003e: leverages prior investment, possible savings with constant usage, continuity\nwith your vendor.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgainst\u003c/strong\u003e: compliance complexity, vendor audit risk and management on your side.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"hidden-costs-you-should-watch\"\u003eHidden costs you should watch\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eStorage\u003c/strong\u003e: the image\u0026rsquo;s EBS snapshots cost money, even if the software is free.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData transfer\u003c/strong\u003e between regions or out to the internet.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSupport\u003c/strong\u003e: is it included in the hourly price or does it go separately?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInstance type\u003c/strong\u003e: the software may require larger instances, pushing compute cost up.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLicence portability\u003c/strong\u003e: some BYOL licences require dedicated tenancy, which is more\nexpensive.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"how-to-decide\"\u003eHow to decide\u003c/h2\u003e\n\u003cp\u003eThe rule of thumb: for \u003cstrong\u003evariable or short-lived\u003c/strong\u003e workloads, hourly pricing usually wins\non flexibility. For \u003cstrong\u003econstant 24/7, long-lived\u003c/strong\u003e workloads, amortising a licence or\nreserving capacity can reduce total cost. Run the numbers with your real usage profile\n—not the worst case— and remember to include the hidden costs.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eWhich is cheaper, BYOL or hourly pricing?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt depends on your usage. Hourly pricing wins with variable or intermittent workloads;\nBYOL can pay off with constant 24/7 usage if you already have licences to amortise.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDoes free software in an AMI mean zero cost?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNot quite: even if the software is open source, you still pay for the instance, the\nsnapshot storage and data transfer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat legal risks does BYOL carry?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYou must comply with the vendor\u0026rsquo;s terms on cloud usage and licence portability. A breach\ncan surface in an audit, so it pays to review the conditions carefully.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we help you understand each image\u0026rsquo;s cost model so you can choose with the\nnumbers clear.\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/en/blog/byol-vs-hourly-pricing/","image":"https://www.imaxe.cloud/blog-covers/byol-vs-pago-por-hora_hu_5e9a1e84b468f504.webp","language":"en","summary":"Do you bring your own licence or pay by the hour when you use an image? The answer changes your bill, your flexibility and your legal obligations. This guide helps you pick the model that actually suits you.","tags":["guides","byol","licensing","costs","marketplace","finops"],"title":"BYOL vs hourly pricing: understand the licensing and cost of your AMIs","url":"https://www.imaxe.cloud/en/blog/byol-vs-hourly-pricing/"},{"authors":[{"name":"imaxe team","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=\"Armoured door of a bank vault\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eWhen you embed a credential in an AMI, that credential travels with every copy of the\nimage, stays etched into the snapshots and can end up in accounts or regions you never\nimagined. All it takes is somebody with read access to the image extracting it. And since\nimages are kept by version, the secret can survive long after you believed you had\nrotated it.\u003c/p\u003e\n\u003cp\u003eThe golden rule: \u003cstrong\u003ethe image defines the machine; secrets are delivered at runtime\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"where-secrets-should-live\"\u003eWhere secrets should live\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eService\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eCloud or environment\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eIdeal for\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\u003eRotatable credentials, native integration\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\u003eSimple parameters and secrets, low cost\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\u003eMulticloud\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDynamic secrets and fine-grained control\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\u003eNative equivalents on each cloud\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eKeep secrets in a dedicated manager, never in the image nor in plaintext user-data.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"the-right-pattern-identity-not-passwords\"\u003eThe right pattern: identity, not passwords\u003c/h2\u003e\n\u003cp\u003eThe safest way for an instance to reach resources is not to give it a password, but to\ngive it an \u003cstrong\u003eidentity\u003c/strong\u003e. On AWS, an \u003cstrong\u003eIAM role\u003c/strong\u003e attached to the instance lets it obtain\ntemporary, automatically rotated credentials, without any key travelling in the image.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eInstance IAM roles\u003c/strong\u003e: the instance assumes a role and gets temporary credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIRSA on Kubernetes\u003c/strong\u003e: per-pod identity, with no shared keys on the node.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDynamic secrets with Vault\u003c/strong\u003e: short-lived credentials generated on demand.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRuntime injection\u003c/strong\u003e: the application reads the secret from the manager at start-up,\nnot from a baked file.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"protect-the-metadata-imdsv2\"\u003eProtect the metadata: IMDSv2\u003c/h2\u003e\n\u003cp\u003eThe role\u0026rsquo;s temporary credentials are obtained through the instance metadata service. An\nattacker exploiting an SSRF flaw could try to steal them. \u003cstrong\u003eIMDSv2\u003c/strong\u003e requires a session\ntoken and mitigates that class of attack: make it mandatory on your launches.\u003c/p\u003e\n\u003ch2 id=\"hygiene-leave-no-traces-in-the-image\"\u003eHygiene: leave no traces in the image\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eBefore sealing the AMI, \u003cstrong\u003edelete\u003c/strong\u003e shell histories, logs containing credentials,\ntemporary SSH keys and configuration files with secrets.\u003c/li\u003e\n\u003cli\u003eScan the image for \u003cstrong\u003esecrets\u003c/strong\u003e with tools like gitleaks or trufflehog adapted to\nfilesystems.\u003c/li\u003e\n\u003cli\u003eDo not leave extra \u003cstrong\u003eauthorised keys\u003c/strong\u003e in \u003ccode\u003e~/.ssh/authorized_keys\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAvoid \u003cstrong\u003epublic AMIs\u003c/strong\u003e with secrets: if you publish, check that you are leaking nothing.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"quick-checklist\"\u003eQuick checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eZero secrets baked into the image.\u003c/li\u003e\n\u003cli\u003eSecrets manager with roles or federated identity.\u003c/li\u003e\n\u003cli\u003eIMDSv2 mandatory.\u003c/li\u003e\n\u003cli\u003eSecret scanning in the pipeline.\u003c/li\u003e\n\u003cli\u003eTraces cleaned up before sealing.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eWhat if my application needs the secret at boot?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eHave it read the secret from the secrets manager at runtime using the instance identity.\nThat way the secret never travels inside the image and can be rotated without rebuilding.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs it safe to use user-data to pass secrets?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNot in plain text: user-data is readable from the metadata. At most, use it to indicate\nwhich secret to pull from the manager, protecting the metadata with IMDSv2.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow do I detect whether an image already has baked-in secrets?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBy scanning it with secret detection tools over its filesystem and reviewing\nconfiguration files, histories and authorised keys before using it.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we build images free of credentials and designed to integrate with\nsecrets managers and federated identity.\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/en/blog/ami-secrets-management/","image":"https://www.imaxe.cloud/blog-covers/gestion-secretos-ami_hu_ed7ffbea445a9c3c.webp","language":"en","summary":"A password inside an image is a leak waiting to happen: it gets copied, shared and stays forever in a snapshot. The rule is simple and admits no exceptions: secrets never go in the image. Here is how to do it right.","tags":["security","secrets","vault","iam","imdsv2","secrets manager"],"title":"Secrets management: never bake credentials into an AMI","url":"https://www.imaxe.cloud/en/blog/ami-secrets-management/"},{"authors":[{"name":"imaxe team","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=\"Warehouse shelving with stacked, inventoried pallets\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eAn \u003cstrong\u003eSBOM\u003c/strong\u003e (\u003cem\u003eSoftware Bill of Materials\u003c/em\u003e) is your software\u0026rsquo;s \u0026ldquo;ingredient list\u0026rdquo;: the\ncomplete inventory of packages, libraries, versions and dependencies an image contains.\nLike a nutrition label, it tells you exactly what is inside.\u003c/p\u003e\n\u003cp\u003eIts value becomes obvious on the day of a critical vulnerability: instead of manually\ntracking dozens of images, you query the SBOM and know in seconds which images contain\nthe affected component and at what version.\u003c/p\u003e\n\u003ch2 id=\"why-it-matters-for-your-images\"\u003eWhy it matters for your images\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFast CVE response\u003c/strong\u003e: you instantly identify whether a new vulnerability affects you.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSupply chain security\u003c/strong\u003e: you know where every component comes from.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCompliance\u003c/strong\u003e: more and more frameworks and customers request it as evidence.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTransparency\u003c/strong\u003e: if you publish images, an SBOM builds trust with whoever uses them.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"standard-formats\"\u003eStandard formats\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eFormat\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eOrigin\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eNotes\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 Foundation / ISO\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eISO standard, widely used in compliance\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\u003eSecurity oriented, rich for vulnerability analysis\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eThe two dominant SBOM formats; many tools export to both.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"how-to-generate-an-image-sbom-step-by-step\"\u003eHow to generate an image SBOM, step by step\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eChoose the tool\u003c/strong\u003e: Syft, from Anchore, is a de facto standard for generating SBOMs\nof images and filesystems; there are cloud-native options too.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGenerate it in the pipeline\u003c/strong\u003e: during the AMI build, scan the filesystem and produce\nthe SBOM, for instance in CycloneDX and SPDX.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnalyse vulnerabilities\u003c/strong\u003e: run the SBOM through Grype or Trivy to cross-reference it\nwith CVE databases.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSign and archive\u003c/strong\u003e: sign the SBOM —with cosign, for instance— and store it as an\nartefact tied to the image version.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eQuery it when needed\u003c/strong\u003e: when a new CVE appears, check your archived SBOMs to\nestablish the scope.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"the-regulatory-context-of-2026\"\u003eThe regulatory context of 2026\u003c/h2\u003e\n\u003cp\u003eSBOMs have been gaining weight for years as a supply chain security good practice. The\nregulatory picture, however, is nuanced: in the United States the administration revised\ninherited software attestation mandates in 2026 towards a more risk-based approach, while\nin the European Union rules such as the Cyber Resilience Act push software transparency\nand component inventories. Practical conclusion: regardless of regulatory swings, having\nSBOMs is a defensive and commercial advantage worth adopting.\u003c/p\u003e\n\u003ch2 id=\"best-practices\"\u003eBest practices\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eGenerate the SBOM \u003cstrong\u003eautomatically\u003c/strong\u003e on every build, not by hand.\u003c/li\u003e\n\u003cli\u003eStore it \u003cstrong\u003eversioned\u003c/strong\u003e alongside the image it belongs to.\u003c/li\u003e\n\u003cli\u003eCombine it with \u003cstrong\u003evulnerability scanning\u003c/strong\u003e so it is actionable.\u003c/li\u003e\n\u003cli\u003eSign it to guarantee its \u003cstrong\u003eintegrity\u003c/strong\u003e and provenance.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eIs an SBOM the same as a vulnerability scan?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo. The SBOM is the component inventory; the scan cross-references that inventory with\nCVE databases to find vulnerabilities. They complement each other: first you know what\nyou have, then whether it is vulnerable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSPDX or CycloneDX?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eSPDX is an ISO standard widely used in compliance; CycloneDX is more security oriented.\nMany tools export to both, so you do not have to pick just one.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDo I need an SBOM if I only consume third-party images?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYes. Requesting or generating the SBOM for the images you use lets you assess their risk\nand respond quickly to vulnerabilities, even if you did not build them.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we bet on traceability: inventorying and documenting the software in our\nimages is part of building them well.\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/en/blog/sbom-machine-images/","image":"https://www.imaxe.cloud/blog-covers/sbom-imagenes-de-maquina_hu_ffc36a1f6a89fff9.webp","language":"en","summary":"When the next critical vulnerability lands, the question will be: \"am I affected?\". Without an SBOM the answer takes days of manual searching. With one, seconds. Here is what it is and how to generate it for your images.","tags":["security","sbom","spdx","cyclonedx","syft","supply chain"],"title":"SBOM for machine images: inventory and traceability for your software","url":"https://www.imaxe.cloud/en/blog/sbom-machine-images/"},{"authors":[{"name":"imaxe team","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=\"Laptop showing a system update in a terminal\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ecloud-init\u003c/strong\u003e is the de facto standard for initialising cloud instances during their\nfirst boot. When you launch an instance and pass it a \u003cstrong\u003euser-data\u003c/strong\u003e script, it is\ncloud-init that interprets and runs it: it creates users, writes files, installs\npackages, mounts disks or starts services.\u003c/p\u003e\n\u003cp\u003eThe ideal combination is clear: the \u003cstrong\u003egolden AMI\u003c/strong\u003e holds what does not change —operating\nsystem, runtime, hardening— and \u003cstrong\u003euser-data\u003c/strong\u003e supplies what varies by environment or\ninstance: configuration, injected secrets, role. That way you reuse a single image across\nmany contexts.\u003c/p\u003e\n\u003ch2 id=\"two-ways-to-write-user-data\"\u003eTwo ways to write user-data\u003c/h2\u003e\n\u003cp\u003euser-data accepts several formats; the two most common are the shell script and\ncloud-config.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eShell script\u003c/strong\u003e: starts with \u003ccode\u003e#!/bin/bash\u003c/code\u003e. Simple and direct for quick tasks.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ecloud-config\u003c/strong\u003e: starts with \u003ccode\u003e#cloud-config\u003c/code\u003e and uses declarative YAML. Cleaner, more\nreadable and more idempotent for configuring users, packages, files and commands.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"a-cloud-config-example\"\u003eA cloud-config example\u003c/h3\u003e\n\u003cp\u003eA typical \u003ccode\u003e#cloud-config\u003c/code\u003e declares sections such as \u003ccode\u003epackages:\u003c/code\u003e (packages to install),\n\u003ccode\u003ewrite_files:\u003c/code\u003e (configuration files), \u003ccode\u003eruncmd:\u003c/code\u003e (final commands) and \u003ccode\u003eusers:\u003c/code\u003e (accounts\nand keys). Being declarative, it is easier to review and maintain than a long script.\u003c/p\u003e\n\u003ch2 id=\"best-practices\"\u003eBest practices\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eKeep user-data small\u003c/strong\u003e: if it grows too much, that probably belongs baked into the\nAMI.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIdempotence\u003c/strong\u003e: design the commands so that re-running them breaks nothing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNever put secrets in the clear\u003c/strong\u003e in user-data: it is readable from the instance\nmetadata. Inject them from Secrets Manager, Parameter Store or Vault at runtime.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProtect metadata access\u003c/strong\u003e: use IMDSv2 to mitigate credential theft via SSRF.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLog and debug\u003c/strong\u003e: the cloud-init logs (\u003ccode\u003e/var/log/cloud-init-output.log\u003c/code\u003e) are your best\nfriend when something fails.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"baking-or-booting-where-each-thing-goes\"\u003eBaking or booting: where each thing goes\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eGoes in the AMI (baking)\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eGoes in user-data (booting)\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\u003eOperating system and patches\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEnvironment-specific configuration\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eRuntime, agents and hardening\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePer-instance variables and parameters\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eStable, heavy software\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCluster registration and discovery\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAnything slow to install\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRuntime secret injection\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eGolden rule: what is stable and slow gets baked; what is variable and light goes at\nboot.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"common-mistakes-that-cost-hours\"\u003eCommon mistakes that cost hours\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePutting into user-data what should be in the image, which yields slow, fragile boots.\u003c/li\u003e\n\u003cli\u003eExposing secrets in plain text in the metadata.\u003c/li\u003e\n\u003cli\u003eAssuming user-data re-runs on every boot: by default it only runs on the first one.\u003c/li\u003e\n\u003cli\u003eNot checking cloud-init logs when the instance \u0026ldquo;does not do what it should\u0026rdquo;.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eDoes user-data run on every reboot?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBy default, only on the first boot. You can configure cloud-init to run certain parts on\nevery boot, but do it deliberately and idempotently.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs it safe to pass passwords in user-data?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo. user-data is readable from the instance metadata. Use a secrets manager and inject\nthem at runtime, and protect the metadata with IMDSv2.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDoes cloud-init only work on AWS?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo. cloud-init is cross-platform and works on AWS, Azure, GCP and others, which makes it\nideal for automating boot in a portable way.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we design images meant to be combined with cloud-init, so that a single\nAMI serves you across many scenarios.\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/en/blog/cloud-init-user-data/","image":"https://www.imaxe.cloud/blog-covers/cloud-init-user-data_hu_6c8986f026962556.webp","language":"en","summary":"A golden AMI handles what is stable; cloud-init handles what changes. Mastering user-data and cloud-init is what lets you use one image in a thousand scenarios without rebaking it. Here is the practical guide.","tags":["guides","cloud-init","user-data","ec2","bootstrapping","imdsv2"],"title":"cloud-init and user-data: configure your instances at boot like a pro","url":"https://www.imaxe.cloud/en/blog/cloud-init-user-data/"},{"authors":[{"name":"imaxe team","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=\"Aerial view of the Bremerhaven container terminal\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eIt is easy to assume that once you work with containers, host security stops mattering.\nThe truth is the opposite: every Kubernetes node is a machine that boots from an image,\nand a breach on the host compromises every pod it hosts. The \u003cstrong\u003enode AMI\u003c/strong\u003e is therefore a\ncritical piece of your security posture.\u003c/p\u003e\n\u003cp\u003eYou have three paths: use the official optimised AMIs as they come, use them as a base\nand customise them, or build your own. For serious production workloads, customising or\nbuilding on a hardened base is the recommended route.\u003c/p\u003e\n\u003ch2 id=\"what-a-good-node-ami-should-carry\"\u003eWhat a good node AMI should carry\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAn optimised base\u003c/strong\u003e for the container runtime, with containerd and the kubelet\ncorrectly configured.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCIS hardening\u003c/strong\u003e of the operating system and, where it applies, of the CIS Benchmark\nfor Kubernetes itself.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUp-to-date patching\u003c/strong\u003e of the kernel and components, with periodic rebuilds.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe agents you need\u003c/strong\u003e —logs, metrics, security— preinstalled for a fast boot.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNo baked-in secrets or credentials\u003c/strong\u003e; identity via IAM Roles for Service Accounts\n(IRSA) or an equivalent.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMinimal configuration\u003c/strong\u003e: strip out packages and services a node does not need.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"image-options-for-eks\"\u003eImage options for EKS\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eOption\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eAdvantage\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eWhen to choose it\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 optimised AMI (AL2023)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eOfficial, maintained by AWS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGeneral starting point\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\u003eMinimal container-oriented OS, immutable\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMaximum security and smallest surface\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCustom AMI\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFull control over hardening and agents\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eStrict compliance requirements\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003ePick your node base according to your balance between control and convenience.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"bottlerocket-containers-first\"\u003eBottlerocket: containers first\u003c/h2\u003e\n\u003cp\u003eBottlerocket is a minimalist operating system from AWS designed exclusively to run\ncontainers. Its attack surface is tiny, it is immutable and it updates by image —not by\nhot patching— which fits the immutable infrastructure philosophy beautifully. If your\npriority is node security with the least maintenance effort, it deserves a serious\nevaluation.\u003c/p\u003e\n\u003ch2 id=\"upgrading-nodes-without-pain\"\u003eUpgrading nodes without pain\u003c/h2\u003e\n\u003cp\u003eA hardened node AMI is only useful if you keep the nodes current. The immutable pattern\nshines here:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eReplace, do not patch\u003c/strong\u003e: publish a new AMI version and rotate the nodes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRolling update of the node group\u003c/strong\u003e: drain with \u003cem\u003ecordon\u003c/em\u003e and \u003cem\u003edrain\u003c/em\u003e and replace node\nby node.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eManaged Node Groups\u003c/strong\u003e or Karpenter to automate the replacement with new AMIs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePodDisruptionBudgets\u003c/strong\u003e so that rotation does not affect the availability of your\nservices.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"common-mistakes\"\u003eCommon mistakes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eRunning the default optimised AMI for months without updating it.\u003c/li\u003e\n\u003cli\u003eBaking cluster credentials into the image instead of using federated identity.\u003c/li\u003e\n\u003cli\u003eForgetting to harden the kubelet itself and the filesystem permissions.\u003c/li\u003e\n\u003cli\u003eNot restricting SSH access to nodes: ideally, zero SSH and access only via SSM.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eDo I need a custom AMI or is the EKS optimised one enough?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eTo get started, the official optimised AMI is a good point of departure. If you have\nstrict compliance or security requirements, customise it or build your own with your own\nhardening and agents.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDoes Bottlerocket replace a normal Linux AMI?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eFor nodes that only run containers, yes: it offers a smaller attack surface and\nimmutable updates. It is not suitable for workloads that need a general-purpose OS.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow do I upgrade nodes when I publish a new AMI?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eWith a rolling update of the node group: nodes are drained and replaced progressively,\nrespecting PodDisruptionBudgets so the service is not affected.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we design hardened base images that make an ideal foundation for your\nKubernetes nodes.\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/en/blog/hardened-ami-kubernetes/","image":"https://www.imaxe.cloud/blog-covers/ami-endurecida-kubernetes_hu_448c2b0b32cba86a.webp","language":"en","summary":"Kubernetes is only as secure as the nodes it runs on. A hardened, patched and tuned node AMI is the foundation many teams overlook. Here is how to build the ideal base image for EKS and self-managed clusters.","tags":["guides","kubernetes","eks","bottlerocket","hardening","nodes"],"title":"Hardened AMIs for Kubernetes nodes: the secure foundation of your cluster","url":"https://www.imaxe.cloud/en/blog/hardened-ami-kubernetes/"},{"authors":[{"name":"imaxe team","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=\"Fire alarm call point with its red light\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eBetween a critical vulnerability being published and you fixing it across every instance\nlies the \u003cstrong\u003eexposure window\u003c/strong\u003e. The longer it lasts, the more time an attacker has to\nexploit it. In the traditional server-by-server patching model, that window is measured\nin days or weeks. In a well-automated immutable image model, in hours.\u003c/p\u003e\n\u003cp\u003eThe key is to treat CVE response as a reproducible engineering process, not as a\nlast-minute manual scramble.\u003c/p\u003e\n\u003ch2 id=\"automated-response-architecture\"\u003eAutomated response architecture\u003c/h2\u003e\n\u003cp\u003eThe goal is that, when a critical CVE affects you, a new patched image is born, validated\nand ready to deploy with minimal human intervention. The circuit has four pieces.\u003c/p\u003e\n\u003ch3 id=\"1-detection\"\u003e1. Detection\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eContinuous scanning\u003c/strong\u003e of your current images with Amazon Inspector, Trivy or Grype.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerability feeds\u003c/strong\u003e —NVD, operating system vendor advisories— feeding alerts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSBOM\u003c/strong\u003e for each image so you know in seconds whether the vulnerable component is\npresent.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2-trigger\"\u003e2. Trigger\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eA critical or high severity alert triggers the rebuild pipeline, for instance via\nEventBridge into CodeBuild, or with a webhook to your CI.\u003c/li\u003e\n\u003cli\u003eYou can require human approval for production while keeping build and validation fully\nautomatic.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-rebuild-and-validation\"\u003e3. Rebuild and validation\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eThe pipeline —Packer or EC2 Image Builder— rebuilds the image from the updated base,\napplying \u003ccode\u003ednf\u003c/code\u003e/\u003ccode\u003eapt update\u003c/code\u003e and the usual hardening.\u003c/li\u003e\n\u003cli\u003eThe new image is \u003cstrong\u003erescanned\u003c/strong\u003e: there is no point publishing if the CVE is still there.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTests\u003c/strong\u003e are run: boot, smoke tests, InSpec, so nothing breaks.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"4-distribution-and-deployment\"\u003e4. Distribution and deployment\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eThe new AMI is \u003cstrong\u003eversioned\u003c/strong\u003e, copied to the necessary regions and the pointer in SSM\nParameter Store is updated.\u003c/li\u003e\n\u003cli\u003eThe \u003cstrong\u003eLaunch Template\u003c/strong\u003e is updated and the Auto Scaling Group performs a \u003cem\u003erolling\nupdate\u003c/em\u003e or a blue/green deployment.\u003c/li\u003e\n\u003cli\u003eVulnerable images are marked \u003cstrong\u003edeprecated\u003c/strong\u003e so nobody launches them by mistake.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"the-key-metric-patch-mttr\"\u003eThe key metric: patch MTTR\u003c/h2\u003e\n\u003cp\u003eMeasure the \u003cstrong\u003eaverage time from a critical CVE being published to your fleet running the\nfixed image\u003c/strong\u003e. It is the indicator that sums up your maturity. Bringing it down from\nweeks to hours is one of the biggest returns of investing in an image pipeline.\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eMaturity level\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eTypical MTTR\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eHow patching happens\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\u003eManual\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDays or weeks\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSSH server by server\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSemi-automated\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHours to a day or two\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eManual rebuild and rolling\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAutomated\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHours\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eTrigger, rebuild and deploy\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003ePipeline automation dramatically shrinks the exposure window.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"best-practices\"\u003eBest practices\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRun the drill\u003c/strong\u003e: test the circuit with a simulated CVE before you really need it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProgressive deployment\u003c/strong\u003e: canary or rolling to catch regressions without taking the\nservice down.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRollback ready\u003c/strong\u003e: keep the previous version and have an immediate reversion plan.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCommunication\u003c/strong\u003e: record which CVE motivated each rebuild; it is compliance evidence.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eShould I rebuild for any CVE?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo. Prioritise by severity and exploitability, and by whether the affected component is\nactually in your image: the SBOM is key here. Critical and exploitable high ones justify\nan urgent rebuild; the rest can wait for the regular cycle.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow do I avoid breaking production when deploying the new image?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eWith automated validation —smoke tests, InSpec— before publishing, and progressive\ndeployments: canary, rolling or blue/green, with rollback ready.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCan I automate this outside AWS?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYes. The pattern —detect, trigger, rebuild, deploy— holds on Azure and GCP with their\nequivalents; Packer brings portability to the build phase.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we rebuild and rescan our images quickly in the face of new\nvulnerabilities so you start from an up-to-date base.\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/en/blog/rebuild-ami-after-cve/","image":"https://www.imaxe.cloud/blog-covers/reconstruir-ami-ante-cve_hu_920b537b3bf25409.webp","language":"en","summary":"When the next Log4Shell lands, the clock is running. Organisations that rebuild and redistribute their image within hours sleep soundly; those that patch by hand do not. This is the architecture for responding to a critical CVE automatically.","tags":["security","cve","vulnerabilities","pipeline","inspector","mttr"],"title":"Rebuilding AMIs on a critical CVE: automate your vulnerability response","url":"https://www.imaxe.cloud/en/blog/rebuild-ami-after-cve/"},{"authors":[{"name":"imaxe team","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=\"Patch panels and Ethernet switches in a 19-inch rack\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eThe three big clouds solve the same problem —having a reusable template to launch\nidentical machines— with their own approaches and naming. Knowing the equivalences is the\nfirst step to designing a frictionless multicloud strategy.\u003c/p\u003e\n\u003cp\u003eOn AWS it is called an \u003cstrong\u003eAMI\u003c/strong\u003e (Amazon Machine Image); on Azure, a \u003cstrong\u003eManaged Image\u003c/strong\u003e and,\nabove all, the \u003cstrong\u003eAzure Compute Gallery\u003c/strong\u003e (formerly Shared Image Gallery); on Google\nCloud, a \u003cstrong\u003eCustom Image\u003c/strong\u003e. They all encapsulate a preconfigured boot disk, but they\ndiffer in how they are versioned, shared and distributed.\u003c/p\u003e\n\u003ch2 id=\"equivalences-at-a-glance\"\u003eEquivalences at a glance\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eConcept\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\u003eMachine image\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\u003eCatalogue or gallery\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNone native: tags and 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\u003eManaged versioning\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eManual, by name and tags\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNative in the Gallery\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eImage Family: latest per family\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eMulti-region distribution\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAMI copy\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eReplicas in the Gallery\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGlobal images by default\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eUnderlying store\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEBS snapshots\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\u003eEncryption\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eKMS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePlatform or customer keys\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGoogle-managed or CMEK\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eFunctional equivalences of machine images across the three big clouds.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"aws-ami-the-de-facto-standard\"\u003eAWS AMI: the de facto standard\u003c/h2\u003e\n\u003cp\u003eThe AMI is probably the best-known image format and the one with the largest ecosystem.\nIts strength is maturity: a huge catalogue, integration with EC2 Image Builder,\nMarketplace and an immense community. Its historical weak spot is the absence of a native\nimage gallery with managed versioning: versioning and multi-region distribution are\nsolved with naming conventions, tags, SSM Parameter Store and explicit copies across\nregions.\u003c/p\u003e\n\u003ch2 id=\"azure-compute-gallery-versioning-and-replicas-out-of-the-box\"\u003eAzure Compute Gallery: versioning and replicas out of the box\u003c/h2\u003e\n\u003cp\u003eAzure has bet heavily on image governance. The \u003cstrong\u003eCompute Gallery\u003c/strong\u003e natively offers image\ndefinitions, versions and automatic replicas to several regions, plus granular access\ncontrol. For large organisations that need to distribute images in an orderly way across\nteams and regions, it is a very comfortable model. The trade-off is a slightly steeper\nconceptual learning curve.\u003c/p\u003e\n\u003ch2 id=\"gcp-custom-image-global-simplicity\"\u003eGCP Custom Image: global simplicity\u003c/h2\u003e\n\u003cp\u003eGoogle Cloud stands out for its simplicity. Its images are \u003cstrong\u003eglobal\u003c/strong\u003e by default —you do\nnot have to copy them region by region— and the \u003cstrong\u003eImage Family\u003c/strong\u003e concept solves\nversioning elegantly: you point at the family and always get the latest non-deprecated\nimage. It is a minimalist model that reduces friction, especially attractive for teams\nthat value operational simplicity.\u003c/p\u003e\n\u003ch2 id=\"the-multicloud-strategy-one-template-three-images\"\u003eThe multicloud strategy: one template, three images\u003c/h2\u003e\n\u003cp\u003eIf you publish or deploy across several clouds, maintaining three separate build\nprocesses is painful. The industry\u0026rsquo;s answer is \u003cstrong\u003ePacker\u003c/strong\u003e: a single template with shared\nprovisioners and one source block per cloud, able to generate the AMI, the Managed Image\nand the Custom Image in parallel from the same definition.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eReuse\u003c/strong\u003e the same installation and hardening scripts across the three clouds.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReduce\u003c/strong\u003e drift between environments: the same configuration, three destinations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVersion\u003c/strong\u003e coherently with a common naming and metadata scheme.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAutomate\u003c/strong\u003e publication to each gallery: Gallery, Image Family, tags and SSM.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"which-one-should-you-choose\"\u003eWhich one should you choose?\u003c/h2\u003e\n\u003cp\u003eThere is no absolute winner; it depends on your context. If you want ecosystem and\nmaturity, AWS. If you need enterprise image governance with native versioning and\nreplicas, Azure\u0026rsquo;s Compute Gallery shines. If you value simplicity and global reach with\nno copies, GCP. And if you live across several clouds, the answer is not a platform but a\n\u003cstrong\u003epractice\u003c/strong\u003e: describe your images as code and build them portably.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eCan I move an AWS AMI to Azure or GCP directly?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNot directly: the formats and underlying stores differ. The usual approach is to rebuild\nthe image on each cloud from a common template, for instance with Packer, or to import\nthe disk using each provider\u0026rsquo;s import process.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhich cloud has the best image versioning?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAzure Compute Gallery offers the most complete managed versioning out of the box; GCP\nsolves it elegantly with Image Families; AWS requires more of your own conventions,\nalthough it is very flexible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs a multicloud image strategy worth it?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIf you operate across several clouds for data sovereignty, resilience or to avoid vendor\nlock-in, yes. The key is to use images as code so you do not multiply the maintenance\neffort.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we think about portability from the design stage so your deployments do\nnot depend on a single 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/en/blog/aws-azure-gcp-images/","image":"https://www.imaxe.cloud/blog-covers/aws-azure-gcp-imagenes_hu_4cc3e453ad41116a.webp","language":"en","summary":"AMI, Managed Image, Custom Image: every cloud has its own name and its own rules for the same thing, a template to boot machines from. If you work across several clouds, understanding the differences saves you surprises.","tags":["guides","aws","azure","gcp","multicloud","packer"],"title":"AWS vs Azure vs GCP: comparing machine images across clouds","url":"https://www.imaxe.cloud/en/blog/aws-azure-gcp-images/"},{"authors":[{"name":"imaxe team","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=\"Server aisle in the CERN data centre\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eThe first big news of 2026 is uncomfortable: the era of continuous price cuts is over.\nEnergy cost pressure, massive AI investment and GPU demand are pushing rates up. Discounts\nbecome the exception, not the norm.\u003c/p\u003e\n\u003cp\u003eThat underlying shift shapes everything else. When the cloud was cheap, waste was\ntolerated; when it gets expensive, efficiency becomes a board-level priority. Hence this\nyear\u0026rsquo;s trends revolve around doing more with less and automating with judgement.\u003c/p\u003e\n\u003ch2 id=\"1-immutable-infrastructure-as-the-standard\"\u003e1. Immutable infrastructure as the standard\u003c/h2\u003e\n\u003cp\u003eThe \u0026ldquo;build an image and replace\u0026rdquo; model is consolidating as the default practice. Instead\nof patching live servers, teams bake versioned images and deploy by replacing instances.\nIt brings predictable deployments, clean rollbacks and a smaller attack surface. \u003cstrong\u003eGolden\nAMIs\u003c/strong\u003e and well-governed machine images are the centrepiece of this approach.\u003c/p\u003e\n\u003ch2 id=\"2-finops-moves-up-to-the-board\"\u003e2. FinOps moves up to the board\u003c/h2\u003e\n\u003cp\u003eCloud cost management stops being a technical team\u0026rsquo;s concern and becomes a business\npriority. The levers most in use this year:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eTagging and visibility\u003c/strong\u003e for every workload, so you know who spends what.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReserved and spot instances\u003c/strong\u003e to work on unit cost.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImage optimisation\u003c/strong\u003e: light images, fast boots and cleanup of orphaned snapshots, a\nclassic hidden cost.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eContinuous rightsizing\u003c/strong\u003e and shutting down idle resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eARM and Graviton adoption\u003c/strong\u003e for their better price-performance.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"3-ai-from-experimenting-to-monetising\"\u003e3. AI: from experimenting to monetising\u003c/h2\u003e\n\u003cp\u003eAfter the initial fever, 2026 is the year of squeezing the return out of AI. The focus\nshifts to reducing idle GPU time, optimising inference and taking models to the edge. A\npattern is also emerging: \u003cstrong\u003eAI agent meshes\u003c/strong\u003e, hubs that govern communication between\nagents, apply cost control and route requests to the cheapest model that can solve the\ntask.\u003c/p\u003e\n\u003ch2 id=\"4-multicloud-and-edge-with-feet-on-the-ground\"\u003e4. Multicloud and edge, with feet on the ground\u003c/h2\u003e\n\u003cp\u003eMulticloud is going mainstream, but pragmatically: not as a fashion, but to avoid vendor\nlock-in, meet data sovereignty requirements and take the best of each cloud. Machine\nimage portability —one template producing images for several clouds— gains value. In\nparallel, the \u003cstrong\u003eedge\u003c/strong\u003e grows to bring compute closer to the data, driven by AI and IoT.\u003c/p\u003e\n\u003ch2 id=\"5-regulation-the-year-of-compliance\"\u003e5. Regulation: the year of compliance\u003c/h2\u003e\n\u003cp\u003eThe regulatory framework is tightening. In 2026 relevant stages of European AI regulation\nand new liability directives come into force, and cloud governance requirements are being\nstrengthened in several jurisdictions. The direct consequence for infrastructure:\ntraceability —what software you run, how you secure it, how you prove it— becomes\nmandatory. Auditable image chains and SBOMs stop being a luxury.\u003c/p\u003e\n\u003ch2 id=\"what-this-means-for-your-infrastructure\"\u003eWhat this means for your infrastructure\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eTrend\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003ePractical implication\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eRecommended action\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\u003ePricier cloud\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEvery resource counts\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFinOps and efficient images\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eImmutability\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLess drift, more control\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGolden AMI pipelines\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eAI in production\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eOptimise inference and cost\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eShared GPU, edge, agents\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eMulticloud\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAvoid lock-in\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePortable images with Packer\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eRegulation\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMandatory traceability\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSBOMs and auditable chains\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eFrom the trend to the concrete action in your day to day.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eIs the price of the cloud really going up in 2026?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAnalysts point to upward pressure from energy and GPU costs, with discounts becoming the\nexception. That is why FinOps and resource efficiency carry so much weight this year.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat is an AI agent mesh?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt is an architecture where a central hub governs communication between AI agents,\napplying security, cost control and routing of requests to the most suitable and\neconomical model.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhy is immutability a trend if it is not new?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBecause the context makes it nearly mandatory: rising costs, demanding regulation and the\nneed for auditable deployments push the versioned-image-and-replace model into the\nstandard.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we follow these trends closely so our images fit the cloud that is coming:\nefficient, portable and auditable.\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/en/blog/cloud-trends-2026/","image":"https://www.imaxe.cloud/blog-covers/tendencias-cloud-2026_hu_c649ca0919e5a33f.webp","language":"en","summary":"2026 arrives with a cloud that is pricier, more regulated and more intelligent. For those who build and deploy infrastructure, three currents —immutability, cost control and AI-driven automation— define where to put the focus this year.","tags":["news","finops","trends","multicloud","edge","regulation"],"title":"Cloud trends 2026: immutable images, FinOps and AI set the pace","url":"https://www.imaxe.cloud/en/blog/cloud-trends-2026/"},{"authors":[{"name":"imaxe team","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=\"Shipping containers stacked at the port of Rotterdam\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eAn \u003cstrong\u003eAMI\u003c/strong\u003e packages a complete operating system plus your software: it is the template\nfor an entire virtual machine. A \u003cstrong\u003econtainer\u003c/strong\u003e packages only your application and its\ndependencies, sharing the host kernel. The difference in size and isolation model\nexplains almost everything else.\u003c/p\u003e\n\u003cp\u003eIt is not a battle: in practice, containers run \u003cstrong\u003eon top of\u003c/strong\u003e virtual machines that boot\nfrom an AMI. The useful question is not which one wins, but which layer each one solves.\u003c/p\u003e\n\u003ch2 id=\"head-to-head-comparison\"\u003eHead-to-head comparison\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eDimension\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eAMI (virtual machine)\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eContainer\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\u003eWhat it includes\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFull OS plus software\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eApp and dependencies\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eIsolation\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eStrong, via hypervisor\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eProcess level, shared kernel\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSize\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGigabytes\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMegabytes\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eBoot\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSeconds to minutes\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMilliseconds to seconds\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eDensity\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLower: one VM per instance\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHigh: many per host\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ePortability\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eTied to the cloud or hypervisor\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVery high: any host with a runtime\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eOS maintenance\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eYou manage it\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eInherited from the host or base image\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eIdeal case\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMonoliths, hosts, dedicated VMs\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMicroservices, fast scaling\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eAMIs and containers solve different problems at different layers.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"when-to-choose-an-ami\"\u003eWhen to choose an AMI\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eStrong isolation is mandatory\u003c/strong\u003e: multi-tenant workloads or strict regulatory\nrequirements where hypervisor isolation is a hard requirement.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSoftware that expects a full machine\u003c/strong\u003e: databases, legacy applications, network or\nsecurity appliances.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFull control of the operating system\u003c/strong\u003e: when you need kernel modules, specific\ndrivers or fine-grained OS tuning.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe base of your nodes\u003c/strong\u003e: even in a container world, your Kubernetes nodes boot from\nan AMI.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"when-to-choose-containers\"\u003eWhen to choose containers\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eMicroservices\u003c/strong\u003e that scale and deploy independently.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFast deployment cycles\u003c/strong\u003e with continuous integration and delivery.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHigh density\u003c/strong\u003e to squeeze the hardware with many small workloads.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePortability\u003c/strong\u003e across development, testing and several clouds.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"the-mature-answer-combine-them\"\u003eThe mature answer: combine them\u003c/h2\u003e\n\u003cp\u003eAdvanced teams do not pick one or the other, they layer. They build a \u003cstrong\u003ehardened golden\nAMI\u003c/strong\u003e as the host base —patched, CIS hardened, with security agents— and run their\ncontainers on top of it. That gives them the best of both worlds: host security and\ncontrol at the machine image level, and container agility and density at the application\nlevel.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eKubernetes or ECS nodes based on a hardened, versioned AMI.\u003c/li\u003e\n\u003cli\u003eHost updates by AMI replacement (immutable), not by hot patching.\u003c/li\u003e\n\u003cli\u003eContainers for the fast lifecycle of the application.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"microvms-the-boundary-blurs\"\u003eMicroVMs: the boundary blurs\u003c/h2\u003e\n\u003cp\u003eTechnologies like Firecracker —the one behind AWS Lambda and Fargate— create\n\u003cstrong\u003emicroVMs\u003c/strong\u003e: the strong isolation of a virtual machine with millisecond boot times,\nalmost like a container. It is the sign that the future is not \u0026ldquo;VM or container\u0026rdquo;, but a\ncontinuum where you pick the right point between isolation and agility for each\nworkload.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eDo containers make AMIs obsolete?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo. Containers run on machines that boot from images. A hardened AMI is still the ideal\nbase for the nodes that run your containers.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhich is more secure, a VM or a container?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe VM offers stronger isolation by design. Containers share a kernel, so they require\nadditional controls. For very sensitive workloads, combining a VM with a hardened\ncontainer is the usual approach.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCan I migrate from AMIs to containers easily?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt depends on the application. Stateless, modular services migrate well; monoliths\ntightly coupled to the OS take more work. A hybrid, gradual approach is often the right\ncall.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we believe in the right tool for each workload: that is why our images\nserve both as a direct host and as a hardened base for your containers.\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/en/blog/amis-vs-containers/","image":"https://www.imaxe.cloud/blog-covers/amis-vs-contenedores_hu_9942fe419781baec.webp","language":"en","summary":"Machine image or container? The question is framed wrong: they do not compete, they complement each other. Understanding what each one solves saves you from over-engineering and helps you pick the right tool for every workload.","tags":["guides","containers","kubernetes","docker","microvm","architecture"],"title":"AMIs vs containers: when each one fits (and when to combine them)","url":"https://www.imaxe.cloud/en/blog/amis-vs-containers/"},{"authors":[{"name":"imaxe team","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=\"Magnifying glass examining a postage stamp\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eLaunching an instance from an AMI is, in practice, running software packaged by somebody\nelse inside your own account. If the image contains malware, cryptocurrency miners,\nembedded keys or simply unpatched packages, that risk walks straight into your\ninfrastructure. There are documented cases of malicious public images designed for\nexactly that.\u003c/p\u003e\n\u003cp\u003eThe answer is not paranoia but a repeatable \u003cstrong\u003everification process\u003c/strong\u003e. Choosing an AMI\nwell is like hiring somebody: you check identity, references and condition before handing\nover the keys.\u003c/p\u003e\n\u003ch2 id=\"the-five-pillars-of-a-trustworthy-ami\"\u003eThe five pillars of a trustworthy AMI\u003c/h2\u003e\n\u003cp\u003eAssess every candidate image against these five axes. If it fails several, look for\nanother.\u003c/p\u003e\n\u003ch3 id=\"1-provenance-who-publishes-it\"\u003e1. Provenance: who publishes it?\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eVerify the \u003cstrong\u003eowner ID\u003c/strong\u003e of the account publishing the image; be wary of anonymous or\nunknown owners.\u003c/li\u003e\n\u003cli\u003ePrefer images from official vendors, verified partners or publishers with demonstrable\nreputation.\u003c/li\u003e\n\u003cli\u003eCheck that the name and description match a legitimate origin: watch out for\n\u003cem\u003etyposquatting\u003c/em\u003e imitations.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2-security-what-is-inside\"\u003e2. Security: what is inside?\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIs it \u003cstrong\u003ehardened\u003c/strong\u003e (CIS or an equivalent) or an unprotected base?\u003c/li\u003e\n\u003cli\u003eAre the \u003cstrong\u003esnapshots encrypted\u003c/strong\u003e?\u003c/li\u003e\n\u003cli\u003eScan it yourself before production with Inspector, Trivy or similar to find CVEs and\nsecrets.\u003c/li\u003e\n\u003cli\u003eCheck that it has no unknown \u003cstrong\u003eauthorised SSH keys\u003c/strong\u003e or extra users.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-maintenance-is-it-alive\"\u003e3. Maintenance: is it alive?\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eHow \u003cstrong\u003eoften is it updated\u003c/strong\u003e? An image with no new versions in a year is a red flag.\u003c/li\u003e\n\u003cli\u003eDoes the publisher report the \u003cstrong\u003eCVEs fixed\u003c/strong\u003e in each version?\u003c/li\u003e\n\u003cli\u003eIs there clear \u003cstrong\u003edocumentation\u003c/strong\u003e of what it contains and how it is configured?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"4-compatibility-does-it-fit-your-case\"\u003e4. Compatibility: does it fit your case?\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eCorrect architecture (\u003cstrong\u003ex86_64\u003c/strong\u003e versus \u003cstrong\u003eARM/Graviton\u003c/strong\u003e) and virtualisation type.\u003c/li\u003e\n\u003cli\u003eAvailable region and the ability to copy it to yours.\u003c/li\u003e\n\u003cli\u003eSupport for the instance type you need and compatibility with your automation.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"5-cost-and-licensing-what-do-you-pay-and-under-what-terms\"\u003e5. Cost and licensing: what do you pay, and under what terms?\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eCost model: free, hourly or BYOL.\u003c/li\u003e\n\u003cli\u003eLicence of the included software and its obligations.\u003c/li\u003e\n\u003cli\u003eCost of the \u003cstrong\u003esnapshots\u003c/strong\u003e and associated storage.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"quick-verification-checklist\"\u003eQuick verification checklist\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eCheck\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eGood sign\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eRed flag\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\u003eOwner\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVerified, known owner\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAnonymous or newly created account\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eEncryption\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEncrypted snapshots\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNo encryption\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eUpdates\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRecent, frequent versions\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNo changes in over 12 months\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eDocumentation\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRelease notes and CVEs\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNone or non-existent\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eYour own scan\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNo critical CVEs or secrets\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVulnerabilities or embedded keys\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCost\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eClear, predictable model\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHidden storage costs\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eVerify every point before taking an AMI to production.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"good-practice-rebake-on-top-of-what-you-receive\"\u003eGood practice: rebake on top of what you receive\u003c/h2\u003e\n\u003cp\u003eEven a trustworthy image ages. The safest practice is to take a reliable base AMI and\n\u003cstrong\u003erebake it in your own pipeline\u003c/strong\u003e: apply your patches, your hardening and your\nconfiguration, encrypt it with your key and version it. That way you inherit the good\nparts of the source image and add your own quality control and traceability.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eIs it safe to use a public community AMI?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt can be, but you must verify the owner, the content and its condition, and scan it\nbefore use. For production, an image from a trusted publisher —or one you rebake\nyourself— is preferable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow do I know whether an AMI has a backdoor?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo method is foolproof, but scanning the image, reviewing users and authorised keys,\ninspecting scheduled tasks and analysing network traffic on an isolated test instance\ngreatly reduces the risk.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eShould I trust paid images more than free ones?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003ePrice does not guarantee security, but a publisher who maintains and documents their\nimages —paid or not— usually offers more assurance than an abandoned anonymous image.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we build images with clear provenance, encryption and continuous updates\nso you can deploy with confidence.\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/en/blog/choosing-a-trusted-ami/","image":"https://www.imaxe.cloud/blog-covers/elegir-ami-de-confianza_hu_ab14e41f927a6439.webp","language":"en","summary":"Not every public image is safe, and not every safe image fits your case. Before booting an instance on somebody else's AMI, it pays to look under the hood. This is the checklist that discerning teams use.","tags":["guides","ami","security","provenance","checklist","marketplace"],"title":"How to choose a trustworthy AMI before deploying to production","url":"https://www.imaxe.cloud/en/blog/choosing-a-trusted-ami/"},{"authors":[{"name":"imaxe team","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=\"Enigma cipher machine with its keyboard in view\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eOrganisations invest heavily in protecting the network and the applications, but they\noften neglect the \u003cstrong\u003ebase image\u003c/strong\u003e everything boots from. An AMI with outdated packages or\nunencrypted snapshots spreads risk to every instance born from it. The good news:\nprotecting the image is a single, highly cost-effective control point.\u003c/p\u003e\n\u003cp\u003eThe triad that solves it is simple to state and demanding to maintain: \u003cstrong\u003eencryption\u003c/strong\u003e,\n\u003cstrong\u003epatching\u003c/strong\u003e and \u003cstrong\u003edemonstrable compliance\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"1-encryption-protecting-data-at-rest-and-in-transit\"\u003e1. Encryption: protecting data at rest and in transit\u003c/h2\u003e\n\u003cp\u003eEncryption is the line of defence when everything else fails. For machine images it works\nat several levels:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eEncrypted EBS snapshots\u003c/strong\u003e with AWS KMS, or Azure Disk Encryption and Google CMEK on\nother clouds.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCustomer-managed keys (CMK)\u003c/strong\u003e with automatic rotation and minimal access policies.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEncryption by default\u003c/strong\u003e enabled at the account level so no image is ever born\nunencrypted.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecrets managed outside the image\u003c/strong\u003e: never bake passwords or tokens; inject them at\nruntime with Secrets Manager, Vault or Parameter Store.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"2-patching-the-race-against-cves\"\u003e2. Patching: the race against CVEs\u003c/h2\u003e\n\u003cp\u003eVulnerabilities are published every day. An image is secure the day you create it, and a\nlittle less every day after that. Patch management in an immutable world is not about\nupdating live servers, but about \u003cstrong\u003erebaking\u003c/strong\u003e frequently.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRebuild cadence\u003c/strong\u003e: rebuild the base image at least monthly, and urgently on a\ncritical CVE affecting your stack.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eScanning in the pipeline\u003c/strong\u003e: integrate Trivy, Grype or Amazon Inspector to catch CVEs\nbefore publishing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eQuality gate\u003c/strong\u003e: block publication if vulnerabilities appear above a threshold, for\ninstance critical or exploitable high ones.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSBOM\u003c/strong\u003e: generate a \u003cem\u003eSoftware Bill of Materials\u003c/em\u003e to know exactly what each image\ncontains and respond quickly when the next Log4Shell lands.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"3-compliance-prove-it-do-not-just-do-it\"\u003e3. Compliance: prove it, do not just do it\u003c/h2\u003e\n\u003cp\u003eIn an audit, being secure is not enough: you have to prove it with evidence. Well-governed\nimages produce that evidence naturally.\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eFramework\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eWhat it expects from your images\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eEvidence you can provide\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\u003eConsistent, monitored security controls\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHardening reports and build logs\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\u003eVulnerability management and change control\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCVE scans, versioning and 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\u003eSecure configuration and documented patching\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCIS Benchmark and rebuild history\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\u003eEncryption and data minimisation\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eKMS encryption and no personal data in the image\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eHow secure image practices translate into compliance evidence.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"the-new-regulatory-context-of-2026\"\u003eThe new regulatory context of 2026\u003c/h2\u003e\n\u003cp\u003eThe regulatory environment is tightening. In 2026 key stages of the European AI\nregulation and new product liability directives come into force, and several\njurisdictions are strengthening their cloud governance and compliance requirements. The\npractical translation: traceability of what software you run and how you secure it stops\nbeing optional. An auditable image chain is your best insurance.\u003c/p\u003e\n\u003ch2 id=\"image-security-checklist\"\u003eImage security checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEncryption by default enabled and snapshots with a CMK.\u003c/li\u003e\n\u003cli\u003eNo baked-in secrets; external credential management.\u003c/li\u003e\n\u003cli\u003eCVE scanning on every build with a quality gate.\u003c/li\u003e\n\u003cli\u003ePeriodic rebuilds and rebuilds on critical CVEs.\u003c/li\u003e\n\u003cli\u003eCIS Benchmark applied and validated.\u003c/li\u003e\n\u003cli\u003eSBOM and build logs archived as evidence.\u003c/li\u003e\n\u003cli\u003eSafe retirement of obsolete images.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eHow often should an immutable image be patched?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt is not hot patched: it is rebuilt. A monthly cycle is a good minimum, with\nextraordinary rebuilds on critical CVEs affecting your software.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat is an SBOM and why do I need one?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAn SBOM is the inventory of all the software and dependencies in your image. It lets you\nknow in minutes whether a new vulnerability affects you, and it is increasingly required\nfor compliance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDoes encryption affect performance?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eEBS encryption with KMS is transparent and its performance impact is practically\nimperceptible for most workloads.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we apply encryption, scanning and continuous updates to our images so you\nstart from a base you can defend in any audit.\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/en/blog/encryption-patching-cloud-compliance/","image":"https://www.imaxe.cloud/blog-covers/cifrado-parches-cumplimiento-cloud_hu_d680a8e49016fa16.webp","language":"en","summary":"Encrypting the data, keeping patches current and being able to prove it in an audit: three practices that, combined, turn your machine images into a trusted asset instead of a latent risk.","tags":["security","encryption","kms","cve","soc 2","iso 27001","pci dss"],"title":"Encryption, patching and compliance: the security triad of your cloud images","url":"https://www.imaxe.cloud/en/blog/encryption-patching-cloud-compliance/"},{"authors":[{"name":"imaxe team","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=\"Padlock and chain closing a metal gate\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eThe \u003cstrong\u003eCIS Benchmarks\u003c/strong\u003e are secure configuration guides published by the Center for\nInternet Security, drawn up by expert consensus. They cover operating systems —Amazon\nLinux, Ubuntu, RHEL, Windows— with hundreds of concrete recommendations: file\npermissions, kernel parameters, password policies, services that should be disabled or\naudit configuration.\u003c/p\u003e\n\u003cp\u003eApplying hardening to the \u003cstrong\u003eAMI\u003c/strong\u003e —rather than to every already-deployed server— is the\nmost efficient route: you harden once and every instance is born secure. It is the\n\u0026ldquo;secure by default\u0026rdquo; approach demanded by frameworks such as ISO 27001, SOC 2, PCI DSS or\nnational security schemes.\u003c/p\u003e\n\u003ch2 id=\"l1-and-l2-levels-how-far-to-tighten\"\u003eL1 and L2 levels: how far to tighten\u003c/h2\u003e\n\u003cp\u003eCIS defines profiles by level. Choosing well avoids breaking applications through excess\nof zeal.\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eProfile\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eGoal\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eWhen to use it\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\u003eEssential security with no relevant functional impact\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eStarting point for most workloads\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\u003eDefence in depth for sensitive environments\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRegulated data, high risk; may need tuning\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\u003eUS Department of Defense requirements\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGovernment or defence contracts\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eCIS hardening profiles and their scope of application.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"how-to-automate-hardening-in-the-image\"\u003eHow to automate hardening in the image\u003c/h2\u003e\n\u003cp\u003eManual hardening neither scales nor is auditable. These are the three most common ways to\nbring it into the build pipeline:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eEC2 Image Builder with CIS components\u003c/strong\u003e: AWS offers integration with managed CIS\nlevels that apply and validate the benchmark during the build, with the option of CIS\nHardened images in the Marketplace.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnsible with a hardening role\u003c/strong\u003e: reuse CIS-based roles for Linux inside a Packer\nprovisioner; it is portable across clouds.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eYour own idempotent scripts\u003c/strong\u003e: for specific cases, with the advantage of full control\nand the disadvantage of maintenance.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"high-impact-controls-that-must-not-be-missing\"\u003eHigh-impact controls that must not be missing\u003c/h2\u003e\n\u003cp\u003eIf you had to prioritise, these CIS controls deliver the greatest risk reduction at the\nlowest cost:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDisable direct root access over SSH\u003c/strong\u003e and force key-based access, never passwords.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRemove unnecessary packages and services\u003c/strong\u003e to reduce the attack surface.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfigure the host firewall\u003c/strong\u003e (firewalld or nftables) with default deny.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEnable auditing\u003c/strong\u003e (\u003ccode\u003eauditd\u003c/code\u003e) and centralised event logging.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApply secure kernel parameters\u003c/strong\u003e (\u003ccode\u003esysctl\u003c/code\u003e) against spoofing and network attacks.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStrict password policies and account lockout.\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCorrect permissions on critical files\u003c/strong\u003e: \u003ccode\u003e/etc/passwd\u003c/code\u003e, \u003ccode\u003e/etc/shadow\u003c/code\u003e and the boot\ndirectories.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"validate-that-hardening-really-was-applied\"\u003eValidate that hardening really was applied\u003c/h2\u003e\n\u003cp\u003eHardening without verifying is an act of faith. Add an automated validation stage that\nscores the image against the benchmark and fails the build if it misses the threshold.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eCIS-CAT, InSpec or OpenSCAP\u003c/strong\u003e scan the freshly baked instance and generate a\ncompliance report.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePass threshold\u003c/strong\u003e: define, for instance, \u0026ldquo;≥ 95 % of L1 controls passed\u0026rdquo; as a quality\ngate.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAudit evidence\u003c/strong\u003e: keep the report as a build artefact; it will be pure gold at your\nnext SOC 2 or ISO audit.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"the-balance-security-without-breaking-the-application\"\u003eThe balance: security without breaking the application\u003c/h2\u003e\n\u003cp\u003eThe classic mistake is applying L2 blindly and discovering the application no longer\nstarts. The sensible strategy: start from L1, measure and raise L2 controls selectively,\ntesting in a staging environment. Document every justified exception; a control disabled\nwith a recorded reason is acceptable in an audit, one disabled silently is not.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eDoes CIS hardening slow my instances down?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe performance impact of the L1 profile is practically nil. Some intensive L2 auditing\ncontrols can add overhead, which is why they are applied selectively and measured.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDo I need to buy CIS Hardened images or can I do it myself?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYou can harden yourself with Ansible, OpenSCAP or EC2 Image Builder components. The CIS\nHardened images in the Marketplace save work and include validation, but they are not\nindispensable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDoes hardening alone make me ISO 27001 or PCI DSS compliant?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eHardening is an important technical control, but compliance also covers processes,\npolicies and evidence. Hardening your AMIs gets you a long way, but it does not replace\nthe rest of the compliance framework.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we start from images hardened according to industry good practice so you\ndeploy on a secure foundation.\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/en/blog/cis-hardening-ec2-ami/","image":"https://www.imaxe.cloud/blog-covers/hardening-cis-ami-ec2_hu_8c72206698ec85fc.webp","language":"en","summary":"An unhardened image is an open door waiting for someone to walk through. Applying the CIS Benchmarks to your AMIs lifts your security posture in one move and brings you closer to compliance. Here is how to do it without slowing your team down.","tags":["security","cis","hardening","compliance","inspec","security"],"title":"CIS hardening of AMIs: a practical guide to hardening your EC2 images","url":"https://www.imaxe.cloud/en/blog/cis-hardening-ec2-ami/"},{"authors":[{"name":"imaxe team","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=\"Platter and head of an opened hard drive\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eMany teams treat an AMI as something you create once and forget. The problem shows up\nmonths later: dozens of untagged images, EBS snapshots nobody knows whether they can\ndelete, and a bill that grows without explanation. Managing the \u003cstrong\u003elifecycle of an AMI\u003c/strong\u003e\nmeans treating it as a software artefact with a birth, versions, maturity, deprecation\nand retirement.\u003c/p\u003e\n\u003cp\u003eGood image governance cuts costs, improves security —nobody accidentally launches an\nunpatched image from a year ago— and makes compliance audits easier.\u003c/p\u003e\n\u003ch2 id=\"phase-1--versioning-with-meaning\"\u003ePhase 1 — Versioning with meaning\u003c/h2\u003e\n\u003cp\u003eVersioning is the backbone. Without it, \u0026ldquo;the latest good AMI\u0026rdquo; is a hallway conversation,\nnot a fact. We recommend a readable, consistent scheme.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVersioned name\u003c/strong\u003e: for instance \u003ccode\u003eimaxe-ubuntu22-nginx-2026.07.1\u003c/code\u003e, with product, base\nand calendar version.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMandatory tags\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,\n\u003ccode\u003eCISLevel\u003c/code\u003e, \u003ccode\u003eStatus\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImmutable: one version, one artefact.\u003c/strong\u003e Never modify a published AMI; create a new\nversion.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCentral registry\u003c/strong\u003e: use AWS Systems Manager Parameter Store to hold the ID of \u0026ldquo;the\ncurrent production AMI\u0026rdquo; so your Launch Templates read it by reference.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"phase-2--end-to-end-encryption\"\u003ePhase 2 — End-to-end encryption\u003c/h2\u003e\n\u003cp\u003eAn AMI\u0026rsquo;s data lives in EBS snapshots. If they are not encrypted, any poorly governed\ncopy is a potential leak. Encryption should be the norm, not the exception.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eEncryption by default\u003c/strong\u003e: enable \u003cem\u003eEBS encryption by default\u003c/em\u003e at account and region\nlevel.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCustomer-managed keys (CMK)\u003c/strong\u003e: use your own KMS key instead of the AWS default one\nto control permissions and rotation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eA copy is a re-encryption\u003c/strong\u003e: when copying an AMI to another region or account, take\nthe chance to re-encrypt it with the destination key.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eShare with KMS grants\u003c/strong\u003e: if you distribute the AMI to other accounts, grant key\naccess with minimal policies.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"phase-3--deprecation-warn-before-deleting\"\u003ePhase 3 — Deprecation: warn before deleting\u003c/h2\u003e\n\u003cp\u003eAWS lets you mark an AMI as \u003cstrong\u003edeprecated\u003c/strong\u003e with a date. From that moment it stops\nappearing by default in searches, but it still works for anyone referencing it\nexplicitly. It is the civilised middle ground between \u0026ldquo;current\u0026rdquo; and \u0026ldquo;deleted\u0026rdquo;: you warn,\nyou give room to migrate and you avoid breaking deployments.\u003c/p\u003e\n\u003ch2 id=\"phase-4--automated-cleanup-and-the-hidden-cost-of-snapshots\"\u003ePhase 4 — Automated cleanup (and the hidden cost of snapshots)\u003c/h2\u003e\n\u003cp\u003eHere is where the money is. When you delete an AMI, its associated EBS snapshots \u003cstrong\u003eare\nnot removed automatically\u003c/strong\u003e. That is the number-one cause of storage bills that grow\nmysteriously. A retirement policy must deregister the AMI and then delete its orphaned\nsnapshots.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRetention policy\u003c/strong\u003e: keep N recent versions (for example the last three) and retire\nthe rest.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAutomate with the cloud\u003c/strong\u003e: Amazon Data Lifecycle Manager (DLM) can manage image\ncreation and deletion by policy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHunt orphaned snapshots\u003c/strong\u003e: periodically audit snapshots with no associated AMI and\ndelete them.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNever delete blindly\u003c/strong\u003e: check that no active instance or Launch Template depends on\nthe AMI before retiring it.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"lifecycle-summary-table\"\u003eLifecycle summary table\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003ePhase\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eKey action\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eTool or service\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\u003eCreation\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eReproducible build and tagging\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\u003eEncryption\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSnapshots encrypted with a CMK\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAWS KMS + EBS default encryption\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eDistribution\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMulti-region or multi-account copy and re-encryption\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\u003eIn force\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRegistry of the current 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\u003eDeprecation\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMark deprecated with a date\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\u003eRetirement\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDeregister and delete snapshots\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDLM / scheduled scripts\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cem\u003eThe six phases of AMI governance and how to automate them.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"metrics-you-should-watch\"\u003eMetrics you should watch\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAverage age\u003c/strong\u003e of the AMIs in use: the lower, the better patched.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNumber of orphaned snapshots\u003c/strong\u003e and their monthly cost.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePercentage of encrypted AMIs\u003c/strong\u003e, with a target of 100 %.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTime from a critical CVE to the new published image\u003c/strong\u003e, the patch MTTR.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eWhy is my EBS bill rising if I already deleted the AMIs?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBecause deregistering an AMI does not delete its snapshots. You must remove them\nexplicitly. Audit orphaned snapshots regularly; they are usually the biggest hidden cost.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs it safe to share an encrypted AMI with another account?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYes, as long as you grant access to the KMS key with a specific grant and minimal\npermissions. Without that access, the destination account cannot launch the image.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow many versions of an AMI should I keep?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt depends on your rollback and compliance needs, but keeping between two and four recent\nversions is usually a good balance between rollback safety and cost.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we design our images with versioning and encryption from the start, so\ntheir lifecycle is predictable and auditable.\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/en/blog/ami-lifecycle/","image":"https://www.imaxe.cloud/blog-covers/ciclo-de-vida-ami_hu_d04b0e8cea647c79.webp","language":"en","summary":"Creating an AMI is easy; governing it over time is what separates a professional team from a graveyard of orphaned images and inflated bills. This is the complete guide to versioning, encrypting and cleaning up your images painlessly.","tags":["operations","versioning","kms","snapshots","governance","costs"],"title":"AMI lifecycle: versioning, encryption and automated cleanup","url":"https://www.imaxe.cloud/en/blog/ami-lifecycle/"},{"authors":[{"name":"imaxe team","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=\"Server cabinets in a machine room\" width=\"1200\" height=\"675\"\u003e\u003c/p\u003e\u003cp\u003eA \u003cstrong\u003egolden AMI\u003c/strong\u003e is a preconfigured, hardened and validated Amazon Machine Image that\nserves as the single template for launching identical EC2 instances. Instead of booting\nan empty server and installing dependencies by hand every time, you bake everything once\n—patched operating system, agents, runtime, configuration and security controls— and\nreuse it on every deployment.\u003c/p\u003e\n\u003cp\u003eThis approach is the foundation of \u003cstrong\u003eimmutable infrastructure\u003c/strong\u003e: you do not hot-patch\nservers, you build a new image and replace the instances. The result is less\nconfiguration drift, faster boots under autoscaling, and deployments you can audit and\nroll back.\u003c/p\u003e\n\u003ch2 id=\"golden-ami-versus-bootstrapping-at-boot\"\u003eGolden AMI versus bootstrapping at boot\u003c/h2\u003e\n\u003cp\u003eThere are two philosophies. With \u003cstrong\u003ebootstrapping\u003c/strong\u003e, the instance configures itself at\nboot (user-data, Ansible pull, cloud-init). It is flexible but slow and fragile: if a\npackage repository goes down, your autoscaling fails. In the \u003cstrong\u003egolden AMI (baking)\u003c/strong\u003e\nmodel the heavy lifting happens once, in the pipeline; boot is nearly instantaneous and\ndeterministic. Most mature teams combine both: they bake what is stable and leave to boot\nonly the configuration that varies by environment.\u003c/p\u003e\n\u003ch2 id=\"why-packer\"\u003eWhy Packer\u003c/h2\u003e\n\u003cp\u003ePacker, from HashiCorp, is the de facto standard tool for building machine images\nautomatically and across clouds from a single template. You define the image as code\n(HCL2); it launches a temporary instance, applies your provisioners, creates the AMI and\ndestroys the temporary resources. The same template can produce images for AWS, Azure and\nGCP, which makes it ideal if you publish on several clouds.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eReproducible\u003c/strong\u003e: the image is described in a file versioned in Git.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMulticloud\u003c/strong\u003e: a single flow for AMI, Azure Managed Image and GCP Custom Image.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIntegrable\u003c/strong\u003e: it fits into CI/CD (GitHub Actions, GitLab CI, CodePipeline).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuditable\u003c/strong\u003e: every build is recorded, with its manifest and artefacts.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"anatomy-of-a-packer-template-hcl2\"\u003eAnatomy of a Packer template (HCL2)\u003c/h2\u003e\n\u003cp\u003eA modern template is organised in blocks. The \u003cstrong\u003esource\u003c/strong\u003e block defines the builder (for\nexample \u003ccode\u003eamazon-ebs\u003c/code\u003e), the base AMI, the instance type and the region. The \u003cstrong\u003ebuild\u003c/strong\u003e\nblock chains the \u003cstrong\u003eprovisioners\u003c/strong\u003e that install and configure software. The\n\u003cstrong\u003epost-processors\u003c/strong\u003e generate artefacts such as a JSON manifest with the resulting AMI ID.\u003c/p\u003e\n\u003ch3 id=\"a-minimal-annotated-example\"\u003eA minimal annotated example\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003esource \u0026quot;amazon-ebs\u0026quot; \u0026quot;app\u0026quot;\u003c/code\u003e — starts from an official base AMI looked up dynamically with\na \u003ccode\u003edata \u0026quot;amazon-ami\u0026quot;\u003c/code\u003e filtering by owner and name pattern, so you do not pin an ID that\nwill expire.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eprovisioner \u0026quot;shell\u0026quot;\u003c/code\u003e — runs installation and update scripts (\u003ccode\u003ednf update -y\u003c/code\u003e, runtime\ninstallation, CloudWatch agent, SSM agent).\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eprovisioner \u0026quot;ansible\u0026quot;\u003c/code\u003e — if you already have Ansible roles, reuse them to configure the\nimage idempotently.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003epost-processor \u0026quot;manifest\u0026quot;\u003c/code\u003e — writes \u003ccode\u003emanifest.json\u003c/code\u003e with the \u003ccode\u003eartifact_id\u003c/code\u003e, which your\npipeline reads to know which AMI was born.\u003c/p\u003e\n\u003ch2 id=\"the-pipeline-step-by-step\"\u003eThe pipeline step by step\u003c/h2\u003e\n\u003cp\u003eThis is the flow we recommend for taking a golden AMI from commit to production safely\nand repeatably:\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eStep\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eWhat happens\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eTypical tool\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\u003eYou change the template or scripts and push to Git\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGit / PR review\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 check the syntax\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 launches a temporary instance and applies provisioners\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\u003eThe CIS Benchmark is applied and credentials are cleaned\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\u003eVulnerability and secret scanning\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\u003eAn instance is booted and validated\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\u003eThe AMI is tagged (version, commit, date)\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\u003eIt is shared or copied to other regions or accounts\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\u003eThe AMI is referenced in the Launch Template\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\u003eReference flow for a golden AMI pipeline in nine stages.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"best-practices-that-make-the-difference\"\u003eBest practices that make the difference\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eNever pin a base AMI by ID\u003c/strong\u003e: look it up dynamically by owner and name so you always\ninherit the latest patches.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVersion the image\u003c/strong\u003e with a clear scheme (for example \u003ccode\u003eapp-2026.07.1\u003c/code\u003e) and store the\nGit commit in the AMI tags.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClean up before sealing\u003c/strong\u003e: delete logs, shell histories, temporary SSH keys and\npackage caches so you do not leak secrets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAlways scan\u003c/strong\u003e: integrate Trivy or Amazon Inspector so you never publish known CVEs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEncrypt the snapshots\u003c/strong\u003e with your own KMS key from day one.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAutomate expiry\u003c/strong\u003e: mark old versions as deprecated and delete them to keep costs\nunder control.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"packer-or-ec2-image-builder-which-should-i-choose\"\u003ePacker or EC2 Image Builder: which should I choose?\u003c/h2\u003e\n\u003cp\u003eIf you work exclusively on AWS and value native integration with Inspector, managed CIS\ncomponents and zero infrastructure to maintain, \u003cstrong\u003eEC2 Image Builder\u003c/strong\u003e is a solid option\nwith no licence cost. If you need to build for several clouds from the same template, or\nyou already have a HashiCorp ecosystem (Terraform, Vault), \u003cstrong\u003ePacker\u003c/strong\u003e gives you more\nportability. They are not mutually exclusive: many teams use Packer for multicloud logic\nand Image Builder for internal AWS pipelines.\u003c/p\u003e\n\u003ch2 id=\"frequently-asked-questions\"\u003eFrequently asked questions\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eHow often should I rebuild the golden AMI?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAt a minimum with every operating system patch cycle (monthly is usually a good rhythm)\nand whenever a critical CVE is published for your stack. An automated pipeline lets you\nrebuild on demand in minutes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCan I use the same Packer template for AWS and Azure?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYes. Packer supports multiple builders in one build. You share the provisioners and only\nchange each cloud\u0026rsquo;s source block, producing an AMI, a Managed Image and a Custom Image in\nparallel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGolden AMI or containers?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt is not one or the other. Golden AMIs are ideal for the host layer and for\nnon-containerised workloads; containers live on top. In fact, a hardened golden AMI makes\nan excellent base for your Kubernetes nodes.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAt imaxe.cloud we build and maintain hardened, up-to-date base images so your pipeline\nstarts from a reliable foundation.\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/en/blog/golden-ami-packer-pipeline/","image":"https://www.imaxe.cloud/blog-covers/golden-ami-packer-pipeline_hu_cdeb95d898f689f8.webp","language":"en","summary":"A well-built golden AMI is the difference between deploying in seconds with confidence and fighting servers that are never quite the same. In this technical guide we assemble a reproducible Packer pipeline, ready for production.","tags":["guides","packer","golden ami","aws","ci/cd","immutable infrastructure"],"title":"Golden AMI with Packer: how to build a reproducible pipeline step by step","url":"https://www.imaxe.cloud/en/blog/golden-ami-packer-pipeline/"},{"authors":[{"name":"imaxe team","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=\"Diagnostic monitors in a control room\" 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/en/blog/zabbix-7-lts/","image":"https://www.imaxe.cloud/blog-covers/zabbix-7-lts_hu_a2d5ca0fc6cd5b29.webp","language":"en","summary":"Refreshed frontend, SLA widgets and a rewritten SQS reader. We go over what's new in the LTS line and how to migrate from 6.0 without losing history.","tags":["news"],"title":"Zabbix 7.0 LTS now available: what changes in our AMI","url":"https://www.imaxe.cloud/en/blog/zabbix-7-lts/"}],"language":"en","title":"imaxe.cloud · Blog","version":"https://jsonfeed.org/version/1.1"}