imaxe.cloud · Blog

ARM64 by default: why we build our AMIs on Graviton

2026-08-04T00:00:00Z

Every AMI is built for one specific CPU architecture: x86_64 (Intel or AMD) or ARM64 (aarch64, the one behind AWS Graviton and its equivalents). There is no image that “works for both”: they are different binaries. So when we put our catalogue together, we had to decide which one would be the default.

We looked at cost, performance, efficiency, ecosystem maturity and where the market is heading. The conclusion was clear: ARM64 is today the best bet for most workloads. And that is how we build our images.

Why ARM64 wins for most people

1. Better price-performance

This is the decisive argument. ARM (Graviton) instances consistently deliver more performance per euro than their x86 equivalents across a wide range of workloads: web, APIs, microservices, containers, databases and queues. In practice, moving to ARM usually translates into savings in the order of 20 % to 40 % on compute cost. In a cloud that keeps getting more expensive, that margin is too big to ignore.

2. More efficiency, less energy

ARM processors were born optimising power consumption. That means more work per watt, lower energy cost and a smaller carbon footprint per unit of compute. If sustainability is part of your goals —or your customers’— ARM plays in your favour.

3. The ecosystem is already mature

A few years ago, “will it have an ARM version?” was a legitimate question. Today the vast majority of server software —operating systems, languages, runtimes, databases, popular container images— has first-class ARM64 support. Compatibility stopped being the exception and became the norm.

4. Same security, same operating model

Changing architecture does not change how you work: configuration, hardening, cloud-init, your provisioning scripts and your pipeline are all the same. ARM64 does not ask you to give up anything in your operations or your security posture.

The comparison, in one table

Criterion	ARM64 (Graviton)	x86_64 (Intel/AMD)
Price-performance	Superior on most workloads	Good, but pricier per unit
Energy efficiency	Very high	Lower
Software compatibility	Excellent and broad today	Maximum, universal
Legacy proprietary binaries	Sometimes no ARM build	Full support
Market direction	Growing and strategic	Consolidated
Typical cost	Lower: between 20 % and 40 %	Higher

For modern workloads, ARM64 wins where it matters most: cost, efficiency and future.

When x86_64 still makes sense

Being honest is part of choosing well. There are cases where x86_64 is still the right call, and we do not want anyone forcing a migration that makes life harder:

Proprietary software or binaries that only exist compiled for x86.
Native dependencies —compiled extensions— with no ARM build available.
Legacy tools or third-party integrations tied to x86.
Very specific workloads hand-optimised for x86 instructions.

Our decision: ARM64 by default, x86_64 on request

For all of the above, our AMIs are built on ARM64 by default. We believe that is what brings most value to most people: you pay less for the same work, you consume less energy and you ride the architecture that is setting the cloud’s direction.

But we know not every workload fits. That is why, if you need x86_64, all you have to do is ask: we will prepare a custom image with the same configuration, the same hardening and the same quality, built for x86_64. Same product, same base, the architecture your case requires.

How to decide in 30 seconds

Modern stack —web, API, containers, interpreted languages, common databases—: ARM64, no hesitation.
Do you have a proprietary binary or a dependency that only runs on x86? Ask us for the x86_64 variant.
Not sure? Start on ARM64 and try it; if something does not fit, we build the x86_64 one and that is that.

Frequently asked questions

Are your AMIs ARM64 or x86_64?

By default we build them on ARM64 (Graviton), because it offers the best price-performance for most workloads. If you need x86_64, we prepare a custom one with the same configuration and quality.

Do I have to change my application to use ARM64?

In most cases, no. Interpreted languages and modern software run on ARM unchanged. There is only friction with proprietary binaries or native dependencies with no ARM version; in those cases we offer you the x86_64 variant.

How do I request a custom x86_64 image?

Just ask. We start from the same base and the same hardening and build the image for x86_64, so you get exactly the same product on the architecture you need.

Am I really going to save with ARM64?

For suitable workloads, savings of 20 % to 40 % on compute cost are common, on top of lower energy consumption. The way to confirm it for your specific case is to run your workload and compare.

At imaxe.cloud we bet on ARM64 because we believe it is best for your bill, your performance and the planet. And if you need x86_64, all you have to do is ask: we build you a custom one.

Shrink the size and boot time of your AMIs

2026-07-31T00:00:00Z

An image’s size and boot time look like technical details, but they hit three things the business does care about: autoscaling speed —how long you take to answer a spike—, cost —storage and idle compute waiting for boot— and security: less software means less attack surface.

A slim, fast image is almost always a better image.

Slimming the image: less is more

Start from a minimal base: use minimal variants of the operating system rather than full installs.
Install only what you need: every extra package is weight, maintenance and attack surface.
Clean up after building: delete package caches (dnf clean all, apt-get clean), logs, documentation and temporary files before sealing.
Remove build tools: if you compiled something, strip out compilers and development dependencies.
Review the volume size: do not drag a 100 GB disk around if your software takes 8.

Speeding up boot

Bake, do not install at boot: everything you install in user-data is boot time; move it into the image.
Minimal services at start: disable whatever you do not need on the first boot.
Preload dependencies: drivers, runtimes and base containers already present avoid initial downloads.
Optimise cloud-init: a small, idempotent user-data boots sooner.
Snapshots and provisioning: use the cloud’s options to hydrate volumes faster.

The impact, in numbers

Lever	Effect on autoscaling	Effect on cost and security
Smaller image	Faster copies and launches	Lower snapshot cost, fewer CVEs
Faster boot	You answer spikes sooner	Less compute paid without serving
Fewer packages	Less to load and initialise	Reduced attack surface

Optimising the image improves performance, cost and security at the same time.

Do not overshoot

Optimising is not amputating. Cutting too much can break subtle dependencies or make debugging harder. The right discipline: measure size and boot time as part of your pipeline, trim with judgement, always validate in staging, and document what you removed and why. Treat these metrics as image quality indicators, not as an obsession.

Optimisation checklist

Minimal operating system base.
Only the indispensable packages.
Cleanup of caches, logs and temporary files before sealing.
No build tools in the final image.
Small user-data; the heavy lifting baked in.
Volume size matched to reality.
Size and boot metrics in the pipeline.

Frequently asked questions

How much faster can boot get by optimising the image?

It depends on the starting point, but moving installations out of user-data and into the image, plus reducing initial services, usually cuts boot time noticeably, which directly improves how quickly your autoscaling responds.

Is a smaller image more secure?

Generally yes: less installed software means fewer potential vulnerabilities and a smaller attack surface, plus it is easier to audit.

Is a minimal OS worth it?

For most server workloads, yes: it boots sooner, takes less space and is more secure. Just avoid minimising so far that you hamper diagnostics or break dependencies you genuinely need.

At imaxe.cloud we make sure our images are light, quick to boot and easy to maintain.

Machine images for AI and GPUs in 2026: what changes when GPUs enter the picture

2026-07-28T00:00:00Z

With AI in production as the big theme of 2026, more and more teams are launching GPU instances to train and run inference on models. But a GPU does not work on its own: it needs a very specific software stack —NVIDIA driver, CUDA, cuDNN, frameworks— with versions that must line up with each other. Preparing all of that by hand on every instance is slow and fragile.

Hence the value of a GPU-ready image: it encapsulates that validated stack once and boots ready to work.

What an AI AMI should carry

NVIDIA driver compatible with the target GPU, for instance those in the accelerated instance families.
CUDA and cuDNN in versions aligned with the frameworks you plan to use.
Frameworks such as PyTorch or TensorFlow or, better still, the NVIDIA Container Toolkit to run them in containers.
MLOps tooling and GPU monitoring, for example DCGM, preinstalled.
Boot optimisation: preloaded drivers so you do not lose minutes —and GPU money— on every launch.

Build or use a ready-made image

Option	Advantage	Trade-off
Official GPU image (NVIDIA GPU-Optimized, Deep Learning)	Validated, maintained stack	Less control over versions
Custom image	Full control of versions and hardening	Maintenance on you
GPU containers on a base AMI	Portability and reproducibility	Needs the toolkit and driver-equipped nodes

Choose according to how much version control and maintenance you want to take on.

Cost rules: the GPU is expensive

GPU time is the most expensive resource on your AI bill, and reducing idle GPU is one of 2026’s priorities. The image directly influences this:

Fast boot: an image with drivers and dependencies already in place avoids minutes of paid GPU doing nothing.
GPU containers: package the model environment to reproduce it instantly on any driver-equipped node.
Edge inference: lightweight images to bring models close to the data and cut latency and cost.
Scaling and spot: combine ready images with spot instances to cheapen interruption-tolerant workloads.

Best practices

Pin and document the versions of driver, CUDA and framework: compatibility is brittle.
Keep the image up to date with driver and operating system security patches.
Separate the platform layer —driver, toolkit— from the model layer —the container— so you can iterate fast.
Measure the cost per inference and tune image and instance accordingly.

Frequently asked questions

Should I use an official Deep Learning AMI or build my own?

Official GPU images save an enormous amount of time and come with a validated stack. Build your own if you need specific versions, particular hardening or strict compliance.

Why does fast boot matter so much on GPUs?

Because the GPU is the most expensive resource: every minute a GPU instance spends booting and installing drivers is money paid for nothing. An image with everything preinstalled cuts that waste.

Containers or direct installation for GPU AI?

GPU containers, with the NVIDIA Container Toolkit, bring reproducibility and portability, and are the recommended practice. They need the node to carry the driver, which a good base AMI solves.

At imaxe.cloud we follow the evolution of AI workloads closely so our images spare you driver hell and slow boots.

ARM and Graviton: migrate your images and cut your cloud bill

2026-07-24T00:00:00Z

ARM-based processors, such as the AWS Graviton family, have become a first-class option for production workloads. Their pitch is simple and powerful: better price-performance than traditional x86 alternatives for many workloads, with lower power consumption.

In a cloud landscape that keeps getting more expensive —one of the big trends of 2026— migrating to ARM is one of the most effective savings levers inside a FinOps strategy.

How much can you save

The numbers vary by workload, but the industry consistently reports meaningful savings when moving to Graviton, in the order of 20 % to 40 % on compute cost for suitable workloads, thanks to a better price per vCPU and greater efficiency. It is not magic: you have to validate it with your real workload, but the potential is large and it is often money left on the table.

What migrates well and what needs care

Migrates well	Needs validation
Interpreted languages: Python, Node, Java, Go	Binaries compiled for x86 only
Containers with multi-architecture images	Native dependencies with no ARM build
Web, APIs and microservices	Proprietary software with no ARM version
Common databases and caches	Specific drivers or extensions

Most modern workloads migrate without drama; watch out for native dependencies.

The role of multi-architecture images

The key to a clean migration is building your images for both architectures, x86_64 and arm64. In the container world, multi-arch images let the same tag work on either one. In the AMI world, it pays to have your pipeline —Packer or EC2 Image Builder— ready to produce the arm64 image alongside the x86 one, reusing the same provisioners.

A five-step migration plan

Inventory your workloads and spot dependencies that may have no ARM version.
Build arm64 images in your pipeline, in parallel with the x86 ones.
Test in staging: performance, compatibility and functional results.
Migrate in phases with canary or blue/green, measuring real cost and performance.
Optimise: match the Graviton instance type to the workload profile.

ARM on Azure and GCP too

The trend is not AWS-only. Azure offers ARM-based machines —Cobalt and partner ones— and Google Cloud has ARM instances such as Axion and Tau T2A. If you design your images as code and for multiple architectures, you earn the freedom to chase the best price-performance on any cloud.

Frequently asked questions

Exactly how much will I save with Graviton?

It depends on your workload, but savings of 20 % to 40 % on compute cost are common for suitable workloads. The only way to know for sure is to run your real workload on ARM instances and compare.

Do I have to rewrite my application for ARM?

Rarely. Interpreted languages and most modern software run on ARM unchanged. The work shows up with binaries compiled for x86 only or native dependencies with no ARM build.

Can I have images that work on x86 and ARM at the same time?

Yes: with multi-architecture container images and AMI pipelines that produce both variants. That way you migrate gradually and never get stuck.

At imaxe.cloud we design our images to make the most of each architecture and help you optimise cost and performance.

How to migrate to a new AMI without service interruptions

2026-07-21T00:00:00Z

Changing the AMI your instances use is like changing the foundation of your service while it keeps running. Done badly it means outages; done well it is nearly invisible to the user. The good news: there are proven patterns that make this migration safe and reversible.

The common basis is not to edit live instances, but to launch new instances with the new AMI and shift traffic in a controlled way.

Before migrating: prepare the ground

Test the new AMI in a staging environment identical to production.
Reliable health checks: define checks that confirm a new instance is genuinely healthy.
Rollback plan: have the previous version and the procedure to return to it ready.
Observability: metrics and alerts to spot regressions instantly.

Zero-downtime migration strategies

Strategy	How it works	Ideal for
Rolling update	Replaces instances in batches, little by little	Services in an Auto Scaling Group
Blue/Green	You stand up a new environment and switch traffic at once	Migrations with instant rollback
Canary	You send a small percentage of traffic to the new version	Validating in production at low risk

Three patterns for changing AMIs without interrupting the service.

Rolling update

You update the Launch Template with the new AMI and the Auto Scaling Group replaces instances in waves: it launches new ones, waits for them to pass the health check and retires the old ones. Simple and with no extra infrastructure, although both versions coexist for a while.

Blue/Green

You stand up a parallel environment (green) with the new AMI while the current one (blue) keeps serving. Once green is validated, you redirect traffic at the load balancer or in DNS. If anything fails, you are back on blue in seconds. It is the pattern with the fastest rollback, at the cost of temporarily duplicating resources.

Canary

You send a small fraction of traffic to instances with the new AMI and observe. If the metrics hold, you raise the percentage progressively up to 100 %. It minimises the blast radius of an unexpected problem.

After migrating

Watch metrics and logs for a reasonable period before declaring the migration good.
Mark the old AMI as deprecated so it is not relaunched by mistake.
Document the deployed version and the reason for the change.
Do not delete the previous image immediately: keep it in case you need a rollback.

Frequently asked questions

Which strategy is best for zero downtime?

Blue/Green offers the fastest rollback; rolling update is simpler and cheaper; canary minimises risk by validating in production. The choice depends on your risk tolerance and your infrastructure budget.

Do I need to duplicate the infrastructure to migrate?

Only with blue/green, and temporarily. With rolling update or canary you reuse the same group and replace instances as you go, without duplicating the whole environment.

How do I guarantee I can go back?

Keep the previous AMI and its Launch Template, define reliable health checks and have the rollback procedure tested before starting the migration.

At imaxe.cloud we version our images so that migrating between versions is predictable and reversible.

BYOL vs hourly pricing: understand the licensing and cost of your AMIs

2026-07-17T00:00:00Z

When you launch an instance from an AMI, on top of the compute cost —the EC2 instance— there may be a cost attached to the image’s software. That cost is structured mainly in three models: free (open source), hourly pricing bundled with the instance, and BYOL (bring your own licence).

Understanding the difference avoids surprises on the bill and licence compliance headaches.

The models, clearly

Model	How you pay	Main advantage
Free or open source	You only pay for the instance	Minimum cost, no software licence
Hourly pricing (PAYG)	The software is billed per hour of use	No commitment: scale up and shut down
BYOL	You reuse a licence you already own	You leverage prior investment and keep control

The three software cost models in a machine image.

Hourly pricing: flexibility above all

In the pay-as-you-go model, the software cost is added to the instance cost and billed per hour or second of use. It is ideal when your workload is variable or unpredictable: no upfront commitment, you scale when you need to and stop paying when you shut down. The trade-off is that with intensive, constant usage it can end up pricier in the long run than amortising your own licence.

For: zero upfront investment, full elasticity, maintenance and support often included.
Against: an hourly cost that, added up 24/7, can exceed an amortised licence.

BYOL: make the most of what you already have

With Bring Your Own License you reuse a licence you already own —for instance, from an enterprise agreement— on a cloud image. It can cut costs if you have already invested in licences, but it comes with responsibilities: you must comply with the vendor’s terms, watch the licence’s portability to the cloud and manage compliance yourself.

For: leverages prior investment, possible savings with constant usage, continuity with your vendor.
Against: compliance complexity, vendor audit risk and management on your side.

Hidden costs you should watch

Storage: the image’s EBS snapshots cost money, even if the software is free.
Data transfer between regions or out to the internet.
Support: is it included in the hourly price or does it go separately?
Instance type: the software may require larger instances, pushing compute cost up.
Licence portability: some BYOL licences require dedicated tenancy, which is more expensive.

How to decide

The rule of thumb: for variable or short-lived workloads, hourly pricing usually wins on flexibility. For constant 24/7, long-lived workloads, amortising a licence or reserving capacity can reduce total cost. Run the numbers with your real usage profile —not the worst case— and remember to include the hidden costs.

Frequently asked questions

Which is cheaper, BYOL or hourly pricing?

It depends on your usage. Hourly pricing wins with variable or intermittent workloads; BYOL can pay off with constant 24/7 usage if you already have licences to amortise.

Does free software in an AMI mean zero cost?

Not quite: even if the software is open source, you still pay for the instance, the snapshot storage and data transfer.

What legal risks does BYOL carry?

You must comply with the vendor’s terms on cloud usage and licence portability. A breach can surface in an audit, so it pays to review the conditions carefully.

At imaxe.cloud we help you understand each image’s cost model so you can choose with the numbers clear.

Secrets management: never bake credentials into an AMI

2026-07-14T00:00:00Z

When you embed a credential in an AMI, that credential travels with every copy of the image, stays etched into the snapshots and can end up in accounts or regions you never imagined. All it takes is somebody with read access to the image extracting it. And since images are kept by version, the secret can survive long after you believed you had rotated it.

The golden rule: the image defines the machine; secrets are delivered at runtime.

Where secrets should live

Service	Cloud or environment	Ideal for
AWS Secrets Manager	AWS	Rotatable credentials, native integration
AWS SSM Parameter Store	AWS	Simple parameters and secrets, low cost
HashiCorp Vault	Multicloud	Dynamic secrets and fine-grained control
Azure Key Vault / Google Secret Manager	Azure / GCP	Native equivalents on each cloud

Keep secrets in a dedicated manager, never in the image nor in plaintext user-data.

The right pattern: identity, not passwords

The safest way for an instance to reach resources is not to give it a password, but to give it an identity. On AWS, an IAM role attached to the instance lets it obtain temporary, automatically rotated credentials, without any key travelling in the image.

Instance IAM roles: the instance assumes a role and gets temporary credentials.
IRSA on Kubernetes: per-pod identity, with no shared keys on the node.
Dynamic secrets with Vault: short-lived credentials generated on demand.
Runtime injection: the application reads the secret from the manager at start-up, not from a baked file.

Protect the metadata: IMDSv2

The role’s temporary credentials are obtained through the instance metadata service. An attacker exploiting an SSRF flaw could try to steal them. IMDSv2 requires a session token and mitigates that class of attack: make it mandatory on your launches.

Hygiene: leave no traces in the image

Before sealing the AMI, delete shell histories, logs containing credentials, temporary SSH keys and configuration files with secrets.
Scan the image for secrets with tools like gitleaks or trufflehog adapted to filesystems.
Do not leave extra authorised keys in ~/.ssh/authorized_keys.
Avoid public AMIs with secrets: if you publish, check that you are leaking nothing.

Quick checklist

Zero secrets baked into the image.
Secrets manager with roles or federated identity.
IMDSv2 mandatory.
Secret scanning in the pipeline.
Traces cleaned up before sealing.

Frequently asked questions

What if my application needs the secret at boot?

Have it read the secret from the secrets manager at runtime using the instance identity. That way the secret never travels inside the image and can be rotated without rebuilding.

Is it safe to use user-data to pass secrets?

Not in plain text: user-data is readable from the metadata. At most, use it to indicate which secret to pull from the manager, protecting the metadata with IMDSv2.

How do I detect whether an image already has baked-in secrets?

By scanning it with secret detection tools over its filesystem and reviewing configuration files, histories and authorised keys before using it.

At imaxe.cloud we build images free of credentials and designed to integrate with secrets managers and federated identity.

SBOM for machine images: inventory and traceability for your software

2026-07-10T00:00:00Z

An SBOM (Software Bill of Materials) is your software’s “ingredient list”: the complete inventory of packages, libraries, versions and dependencies an image contains. Like a nutrition label, it tells you exactly what is inside.

Its value becomes obvious on the day of a critical vulnerability: instead of manually tracking dozens of images, you query the SBOM and know in seconds which images contain the affected component and at what version.

Why it matters for your images

Fast CVE response: you instantly identify whether a new vulnerability affects you.
Supply chain security: you know where every component comes from.
Compliance: more and more frameworks and customers request it as evidence.
Transparency: if you publish images, an SBOM builds trust with whoever uses them.

Standard formats

Format	Origin	Notes
SPDX	Linux Foundation / ISO	ISO standard, widely used in compliance
CycloneDX	OWASP	Security oriented, rich for vulnerability analysis

The two dominant SBOM formats; many tools export to both.

How to generate an image SBOM, step by step

Choose the tool: Syft, from Anchore, is a de facto standard for generating SBOMs of images and filesystems; there are cloud-native options too.
Generate it in the pipeline: during the AMI build, scan the filesystem and produce the SBOM, for instance in CycloneDX and SPDX.
Analyse vulnerabilities: run the SBOM through Grype or Trivy to cross-reference it with CVE databases.
Sign and archive: sign the SBOM —with cosign, for instance— and store it as an artefact tied to the image version.
Query it when needed: when a new CVE appears, check your archived SBOMs to establish the scope.

The regulatory context of 2026

SBOMs have been gaining weight for years as a supply chain security good practice. The regulatory picture, however, is nuanced: in the United States the administration revised inherited software attestation mandates in 2026 towards a more risk-based approach, while in the European Union rules such as the Cyber Resilience Act push software transparency and component inventories. Practical conclusion: regardless of regulatory swings, having SBOMs is a defensive and commercial advantage worth adopting.

Best practices

Generate the SBOM automatically on every build, not by hand.
Store it versioned alongside the image it belongs to.
Combine it with vulnerability scanning so it is actionable.
Sign it to guarantee its integrity and provenance.

Frequently asked questions

Is an SBOM the same as a vulnerability scan?

No. The SBOM is the component inventory; the scan cross-references that inventory with CVE databases to find vulnerabilities. They complement each other: first you know what you have, then whether it is vulnerable.

SPDX or CycloneDX?

SPDX is an ISO standard widely used in compliance; CycloneDX is more security oriented. Many tools export to both, so you do not have to pick just one.

Do I need an SBOM if I only consume third-party images?

Yes. Requesting or generating the SBOM for the images you use lets you assess their risk and respond quickly to vulnerabilities, even if you did not build them.

At imaxe.cloud we bet on traceability: inventorying and documenting the software in our images is part of building them well.

cloud-init and user-data: configure your instances at boot like a pro

2026-07-07T00:00:00Z

cloud-init is the de facto standard for initialising cloud instances during their first boot. When you launch an instance and pass it a user-data script, it is cloud-init that interprets and runs it: it creates users, writes files, installs packages, mounts disks or starts services.

The ideal combination is clear: the golden AMI holds what does not change —operating system, runtime, hardening— and user-data supplies what varies by environment or instance: configuration, injected secrets, role. That way you reuse a single image across many contexts.

Two ways to write user-data

user-data accepts several formats; the two most common are the shell script and cloud-config.

Shell script: starts with #!/bin/bash. Simple and direct for quick tasks.
cloud-config: starts with #cloud-config and uses declarative YAML. Cleaner, more readable and more idempotent for configuring users, packages, files and commands.

A cloud-config example

A typical #cloud-config declares sections such as packages: (packages to install), write_files: (configuration files), runcmd: (final commands) and users: (accounts and keys). Being declarative, it is easier to review and maintain than a long script.

Best practices

Keep user-data small: if it grows too much, that probably belongs baked into the AMI.
Idempotence: design the commands so that re-running them breaks nothing.
Never put secrets in the clear in user-data: it is readable from the instance metadata. Inject them from Secrets Manager, Parameter Store or Vault at runtime.
Protect metadata access: use IMDSv2 to mitigate credential theft via SSRF.
Log and debug: the cloud-init logs (/var/log/cloud-init-output.log) are your best friend when something fails.

Baking or booting: where each thing goes

Goes in the AMI (baking)	Goes in user-data (booting)
Operating system and patches	Environment-specific configuration
Runtime, agents and hardening	Per-instance variables and parameters
Stable, heavy software	Cluster registration and discovery
Anything slow to install	Runtime secret injection

Golden rule: what is stable and slow gets baked; what is variable and light goes at boot.

Common mistakes that cost hours

Putting into user-data what should be in the image, which yields slow, fragile boots.
Exposing secrets in plain text in the metadata.
Assuming user-data re-runs on every boot: by default it only runs on the first one.
Not checking cloud-init logs when the instance “does not do what it should”.

Frequently asked questions

Does user-data run on every reboot?

By default, only on the first boot. You can configure cloud-init to run certain parts on every boot, but do it deliberately and idempotently.

Is it safe to pass passwords in user-data?

No. user-data is readable from the instance metadata. Use a secrets manager and inject them at runtime, and protect the metadata with IMDSv2.

Does cloud-init only work on AWS?

No. cloud-init is cross-platform and works on AWS, Azure, GCP and others, which makes it ideal for automating boot in a portable way.

At imaxe.cloud we design images meant to be combined with cloud-init, so that a single AMI serves you across many scenarios.

Hardened AMIs for Kubernetes nodes: the secure foundation of your cluster

2026-07-03T00:00:00Z

It is easy to assume that once you work with containers, host security stops mattering. The truth is the opposite: every Kubernetes node is a machine that boots from an image, and a breach on the host compromises every pod it hosts. The node AMI is therefore a critical piece of your security posture.

You have three paths: use the official optimised AMIs as they come, use them as a base and customise them, or build your own. For serious production workloads, customising or building on a hardened base is the recommended route.

What a good node AMI should carry

An optimised base for the container runtime, with containerd and the kubelet correctly configured.
CIS hardening of the operating system and, where it applies, of the CIS Benchmark for Kubernetes itself.
Up-to-date patching of the kernel and components, with periodic rebuilds.
The agents you need —logs, metrics, security— preinstalled for a fast boot.
No baked-in secrets or credentials; identity via IAM Roles for Service Accounts (IRSA) or an equivalent.
Minimal configuration: strip out packages and services a node does not need.

Image options for EKS

Option	Advantage	When to choose it
EKS optimised AMI (AL2023)	Official, maintained by AWS	General starting point
Bottlerocket	Minimal container-oriented OS, immutable	Maximum security and smallest surface
Custom AMI	Full control over hardening and agents	Strict compliance requirements

Pick your node base according to your balance between control and convenience.

Bottlerocket: containers first

Bottlerocket is a minimalist operating system from AWS designed exclusively to run containers. Its attack surface is tiny, it is immutable and it updates by image —not by hot patching— which fits the immutable infrastructure philosophy beautifully. If your priority is node security with the least maintenance effort, it deserves a serious evaluation.

Upgrading nodes without pain

A hardened node AMI is only useful if you keep the nodes current. The immutable pattern shines here:

Replace, do not patch: publish a new AMI version and rotate the nodes.
Rolling update of the node group: drain with cordon and drain and replace node by node.
Managed Node Groups or Karpenter to automate the replacement with new AMIs.
PodDisruptionBudgets so that rotation does not affect the availability of your services.

Common mistakes

Running the default optimised AMI for months without updating it.
Baking cluster credentials into the image instead of using federated identity.
Forgetting to harden the kubelet itself and the filesystem permissions.
Not restricting SSH access to nodes: ideally, zero SSH and access only via SSM.

Frequently asked questions

Do I need a custom AMI or is the EKS optimised one enough?

To get started, the official optimised AMI is a good point of departure. If you have strict compliance or security requirements, customise it or build your own with your own hardening and agents.

Does Bottlerocket replace a normal Linux AMI?

For nodes that only run containers, yes: it offers a smaller attack surface and immutable updates. It is not suitable for workloads that need a general-purpose OS.

How do I upgrade nodes when I publish a new AMI?

With a rolling update of the node group: nodes are drained and replaced progressively, respecting PodDisruptionBudgets so the service is not affected.

At imaxe.cloud we design hardened base images that make an ideal foundation for your Kubernetes nodes.

Rebuilding AMIs on a critical CVE: automate your vulnerability response

2026-06-30T00:00:00Z

Between a critical vulnerability being published and you fixing it across every instance lies the exposure window. The longer it lasts, the more time an attacker has to exploit it. In the traditional server-by-server patching model, that window is measured in days or weeks. In a well-automated immutable image model, in hours.

The key is to treat CVE response as a reproducible engineering process, not as a last-minute manual scramble.

Automated response architecture

The goal is that, when a critical CVE affects you, a new patched image is born, validated and ready to deploy with minimal human intervention. The circuit has four pieces.

1. Detection

Continuous scanning of your current images with Amazon Inspector, Trivy or Grype.
Vulnerability feeds —NVD, operating system vendor advisories— feeding alerts.
SBOM for each image so you know in seconds whether the vulnerable component is present.

2. Trigger

A critical or high severity alert triggers the rebuild pipeline, for instance via EventBridge into CodeBuild, or with a webhook to your CI.
You can require human approval for production while keeping build and validation fully automatic.

3. Rebuild and validation

The pipeline —Packer or EC2 Image Builder— rebuilds the image from the updated base, applying dnf/apt update and the usual hardening.
The new image is rescanned: there is no point publishing if the CVE is still there.
Tests are run: boot, smoke tests, InSpec, so nothing breaks.

4. Distribution and deployment

The new AMI is versioned, copied to the necessary regions and the pointer in SSM Parameter Store is updated.
The Launch Template is updated and the Auto Scaling Group performs a rolling update or a blue/green deployment.
Vulnerable images are marked deprecated so nobody launches them by mistake.

The key metric: patch MTTR

Measure the average time from a critical CVE being published to your fleet running the fixed image. It is the indicator that sums up your maturity. Bringing it down from weeks to hours is one of the biggest returns of investing in an image pipeline.

Maturity level	Typical MTTR	How patching happens
Manual	Days or weeks	SSH server by server
Semi-automated	Hours to a day or two	Manual rebuild and rolling
Automated	Hours	Trigger, rebuild and deploy

Pipeline automation dramatically shrinks the exposure window.

Best practices

Run the drill: test the circuit with a simulated CVE before you really need it.
Progressive deployment: canary or rolling to catch regressions without taking the service down.
Rollback ready: keep the previous version and have an immediate reversion plan.
Communication: record which CVE motivated each rebuild; it is compliance evidence.

Frequently asked questions

Should I rebuild for any CVE?

No. Prioritise by severity and exploitability, and by whether the affected component is actually in your image: the SBOM is key here. Critical and exploitable high ones justify an urgent rebuild; the rest can wait for the regular cycle.

How do I avoid breaking production when deploying the new image?

With automated validation —smoke tests, InSpec— before publishing, and progressive deployments: canary, rolling or blue/green, with rollback ready.

Can I automate this outside AWS?

Yes. The pattern —detect, trigger, rebuild, deploy— holds on Azure and GCP with their equivalents; Packer brings portability to the build phase.

At imaxe.cloud we rebuild and rescan our images quickly in the face of new vulnerabilities so you start from an up-to-date base.

AWS vs Azure vs GCP: comparing machine images across clouds

2026-06-26T00:00:00Z

The three big clouds solve the same problem —having a reusable template to launch identical machines— with their own approaches and naming. Knowing the equivalences is the first step to designing a frictionless multicloud strategy.

On AWS it is called an AMI (Amazon Machine Image); on Azure, a Managed Image and, above all, the Azure Compute Gallery (formerly Shared Image Gallery); on Google Cloud, a Custom Image. They all encapsulate a preconfigured boot disk, but they differ in how they are versioned, shared and distributed.

Equivalences at a glance

Concept	AWS	Azure	Google Cloud
Machine image	AMI	Managed Image	Custom Image
Catalogue or gallery	None native: tags and SSM	Azure Compute Gallery	Image Family
Managed versioning	Manual, by name and tags	Native in the Gallery	Image Family: latest per family
Multi-region distribution	AMI copy	Replicas in the Gallery	Global images by default
Underlying store	EBS snapshots	Managed Disks	Persistent Disk
Encryption	KMS	Platform or customer keys	Google-managed or CMEK

Functional equivalences of machine images across the three big clouds.

AWS AMI: the de facto standard

The AMI is probably the best-known image format and the one with the largest ecosystem. Its strength is maturity: a huge catalogue, integration with EC2 Image Builder, Marketplace and an immense community. Its historical weak spot is the absence of a native image gallery with managed versioning: versioning and multi-region distribution are solved with naming conventions, tags, SSM Parameter Store and explicit copies across regions.

Azure Compute Gallery: versioning and replicas out of the box

Azure has bet heavily on image governance. The Compute Gallery natively offers image definitions, versions and automatic replicas to several regions, plus granular access control. For large organisations that need to distribute images in an orderly way across teams and regions, it is a very comfortable model. The trade-off is a slightly steeper conceptual learning curve.

GCP Custom Image: global simplicity

Google Cloud stands out for its simplicity. Its images are global by default —you do not have to copy them region by region— and the Image Family concept solves versioning elegantly: you point at the family and always get the latest non-deprecated image. It is a minimalist model that reduces friction, especially attractive for teams that value operational simplicity.

The multicloud strategy: one template, three images

If you publish or deploy across several clouds, maintaining three separate build processes is painful. The industry’s answer is Packer: a single template with shared provisioners and one source block per cloud, able to generate the AMI, the Managed Image and the Custom Image in parallel from the same definition.

Reuse the same installation and hardening scripts across the three clouds.
Reduce drift between environments: the same configuration, three destinations.
Version coherently with a common naming and metadata scheme.
Automate publication to each gallery: Gallery, Image Family, tags and SSM.

Which one should you choose?

There is no absolute winner; it depends on your context. If you want ecosystem and maturity, AWS. If you need enterprise image governance with native versioning and replicas, Azure’s Compute Gallery shines. If you value simplicity and global reach with no copies, GCP. And if you live across several clouds, the answer is not a platform but a practice: describe your images as code and build them portably.

Frequently asked questions

Can I move an AWS AMI to Azure or GCP directly?

Not directly: the formats and underlying stores differ. The usual approach is to rebuild the image on each cloud from a common template, for instance with Packer, or to import the disk using each provider’s import process.

Which cloud has the best image versioning?

Azure Compute Gallery offers the most complete managed versioning out of the box; GCP solves it elegantly with Image Families; AWS requires more of your own conventions, although it is very flexible.

Is a multicloud image strategy worth it?

If you operate across several clouds for data sovereignty, resilience or to avoid vendor lock-in, yes. The key is to use images as code so you do not multiply the maintenance effort.

At imaxe.cloud we think about portability from the design stage so your deployments do not depend on a single cloud.

Cloud trends 2026: immutable images, FinOps and AI set the pace

2026-06-23T00:00:00Z

The first big news of 2026 is uncomfortable: the era of continuous price cuts is over. Energy cost pressure, massive AI investment and GPU demand are pushing rates up. Discounts become the exception, not the norm.

That underlying shift shapes everything else. When the cloud was cheap, waste was tolerated; when it gets expensive, efficiency becomes a board-level priority. Hence this year’s trends revolve around doing more with less and automating with judgement.

1. Immutable infrastructure as the standard

The “build an image and replace” model is consolidating as the default practice. Instead of patching live servers, teams bake versioned images and deploy by replacing instances. It brings predictable deployments, clean rollbacks and a smaller attack surface. Golden AMIs and well-governed machine images are the centrepiece of this approach.

2. FinOps moves up to the board

Cloud cost management stops being a technical team’s concern and becomes a business priority. The levers most in use this year:

Tagging and visibility for every workload, so you know who spends what.
Reserved and spot instances to work on unit cost.
Image optimisation: light images, fast boots and cleanup of orphaned snapshots, a classic hidden cost.
Continuous rightsizing and shutting down idle resources.
ARM and Graviton adoption for their better price-performance.

3. AI: from experimenting to monetising

After the initial fever, 2026 is the year of squeezing the return out of AI. The focus shifts to reducing idle GPU time, optimising inference and taking models to the edge. A pattern is also emerging: AI agent meshes, hubs that govern communication between agents, apply cost control and route requests to the cheapest model that can solve the task.

4. Multicloud and edge, with feet on the ground

Multicloud is going mainstream, but pragmatically: not as a fashion, but to avoid vendor lock-in, meet data sovereignty requirements and take the best of each cloud. Machine image portability —one template producing images for several clouds— gains value. In parallel, the edge grows to bring compute closer to the data, driven by AI and IoT.

5. Regulation: the year of compliance

The regulatory framework is tightening. In 2026 relevant stages of European AI regulation and new liability directives come into force, and cloud governance requirements are being strengthened in several jurisdictions. The direct consequence for infrastructure: traceability —what software you run, how you secure it, how you prove it— becomes mandatory. Auditable image chains and SBOMs stop being a luxury.

What this means for your infrastructure

Trend	Practical implication	Recommended action
Pricier cloud	Every resource counts	FinOps and efficient images
Immutability	Less drift, more control	Golden AMI pipelines
AI in production	Optimise inference and cost	Shared GPU, edge, agents
Multicloud	Avoid lock-in	Portable images with Packer
Regulation	Mandatory traceability	SBOMs and auditable chains

From the trend to the concrete action in your day to day.

Frequently asked questions

Is the price of the cloud really going up in 2026?

Analysts point to upward pressure from energy and GPU costs, with discounts becoming the exception. That is why FinOps and resource efficiency carry so much weight this year.

What is an AI agent mesh?

It is an architecture where a central hub governs communication between AI agents, applying security, cost control and routing of requests to the most suitable and economical model.

Why is immutability a trend if it is not new?

Because the context makes it nearly mandatory: rising costs, demanding regulation and the need for auditable deployments push the versioned-image-and-replace model into the standard.

At imaxe.cloud we follow these trends closely so our images fit the cloud that is coming: efficient, portable and auditable.

AMIs vs containers: when each one fits (and when to combine them)

2026-06-19T00:00:00Z

An AMI packages a complete operating system plus your software: it is the template for an entire virtual machine. A container packages only your application and its dependencies, sharing the host kernel. The difference in size and isolation model explains almost everything else.

It is not a battle: in practice, containers run on top of virtual machines that boot from an AMI. The useful question is not which one wins, but which layer each one solves.

Head-to-head comparison

Dimension	AMI (virtual machine)	Container
What it includes	Full OS plus software	App and dependencies
Isolation	Strong, via hypervisor	Process level, shared kernel
Size	Gigabytes	Megabytes
Boot	Seconds to minutes	Milliseconds to seconds
Density	Lower: one VM per instance	High: many per host
Portability	Tied to the cloud or hypervisor	Very high: any host with a runtime
OS maintenance	You manage it	Inherited from the host or base image
Ideal case	Monoliths, hosts, dedicated VMs	Microservices, fast scaling

AMIs and containers solve different problems at different layers.

When to choose an AMI

Strong isolation is mandatory: multi-tenant workloads or strict regulatory requirements where hypervisor isolation is a hard requirement.
Software that expects a full machine: databases, legacy applications, network or security appliances.
Full control of the operating system: when you need kernel modules, specific drivers or fine-grained OS tuning.
The base of your nodes: even in a container world, your Kubernetes nodes boot from an AMI.

When to choose containers

Microservices that scale and deploy independently.
Fast deployment cycles with continuous integration and delivery.
High density to squeeze the hardware with many small workloads.
Portability across development, testing and several clouds.

The mature answer: combine them

Advanced teams do not pick one or the other, they layer. They build a hardened golden AMI as the host base —patched, CIS hardened, with security agents— and run their containers on top of it. That gives them the best of both worlds: host security and control at the machine image level, and container agility and density at the application level.

Kubernetes or ECS nodes based on a hardened, versioned AMI.
Host updates by AMI replacement (immutable), not by hot patching.
Containers for the fast lifecycle of the application.

MicroVMs: the boundary blurs

Technologies like Firecracker —the one behind AWS Lambda and Fargate— create microVMs: the strong isolation of a virtual machine with millisecond boot times, almost like a container. It is the sign that the future is not “VM or container”, but a continuum where you pick the right point between isolation and agility for each workload.

Frequently asked questions

Do containers make AMIs obsolete?

No. Containers run on machines that boot from images. A hardened AMI is still the ideal base for the nodes that run your containers.

Which is more secure, a VM or a container?

The VM offers stronger isolation by design. Containers share a kernel, so they require additional controls. For very sensitive workloads, combining a VM with a hardened container is the usual approach.

Can I migrate from AMIs to containers easily?

It depends on the application. Stateless, modular services migrate well; monoliths tightly coupled to the OS take more work. A hybrid, gradual approach is often the right call.

At imaxe.cloud we believe in the right tool for each workload: that is why our images serve both as a direct host and as a hardened base for your containers.

How to choose a trustworthy AMI before deploying to production

2026-06-16T00:00:00Z

Launching an instance from an AMI is, in practice, running software packaged by somebody else inside your own account. If the image contains malware, cryptocurrency miners, embedded keys or simply unpatched packages, that risk walks straight into your infrastructure. There are documented cases of malicious public images designed for exactly that.

The answer is not paranoia but a repeatable verification process. Choosing an AMI well is like hiring somebody: you check identity, references and condition before handing over the keys.

The five pillars of a trustworthy AMI

Assess every candidate image against these five axes. If it fails several, look for another.

1. Provenance: who publishes it?

Verify the owner ID of the account publishing the image; be wary of anonymous or unknown owners.
Prefer images from official vendors, verified partners or publishers with demonstrable reputation.
Check that the name and description match a legitimate origin: watch out for typosquatting imitations.

2. Security: what is inside?

Is it hardened (CIS or an equivalent) or an unprotected base?
Are the snapshots encrypted?
Scan it yourself before production with Inspector, Trivy or similar to find CVEs and secrets.
Check that it has no unknown authorised SSH keys or extra users.

3. Maintenance: is it alive?

How often is it updated? An image with no new versions in a year is a red flag.
Does the publisher report the CVEs fixed in each version?
Is there clear documentation of what it contains and how it is configured?

4. Compatibility: does it fit your case?

Correct architecture (x86_64 versus ARM/Graviton) and virtualisation type.
Available region and the ability to copy it to yours.
Support for the instance type you need and compatibility with your automation.

5. Cost and licensing: what do you pay, and under what terms?

Cost model: free, hourly or BYOL.
Licence of the included software and its obligations.
Cost of the snapshots and associated storage.

Quick verification checklist

Check	Good sign	Red flag
Owner	Verified, known owner	Anonymous or newly created account
Encryption	Encrypted snapshots	No encryption
Updates	Recent, frequent versions	No changes in over 12 months
Documentation	Release notes and CVEs	None or non-existent
Your own scan	No critical CVEs or secrets	Vulnerabilities or embedded keys
Cost	Clear, predictable model	Hidden storage costs

Verify every point before taking an AMI to production.

Good practice: rebake on top of what you receive

Even a trustworthy image ages. The safest practice is to take a reliable base AMI and rebake it in your own pipeline: apply your patches, your hardening and your configuration, encrypt it with your key and version it. That way you inherit the good parts of the source image and add your own quality control and traceability.

Frequently asked questions

Is it safe to use a public community AMI?

It can be, but you must verify the owner, the content and its condition, and scan it before use. For production, an image from a trusted publisher —or one you rebake yourself— is preferable.

How do I know whether an AMI has a backdoor?

No method is foolproof, but scanning the image, reviewing users and authorised keys, inspecting scheduled tasks and analysing network traffic on an isolated test instance greatly reduces the risk.

Should I trust paid images more than free ones?

Price does not guarantee security, but a publisher who maintains and documents their images —paid or not— usually offers more assurance than an abandoned anonymous image.

At imaxe.cloud we build images with clear provenance, encryption and continuous updates so you can deploy with confidence.

Encryption, patching and compliance: the security triad of your cloud images

2026-06-12T00:00:00Z

Organisations invest heavily in protecting the network and the applications, but they often neglect the base image everything boots from. An AMI with outdated packages or unencrypted snapshots spreads risk to every instance born from it. The good news: protecting the image is a single, highly cost-effective control point.

The triad that solves it is simple to state and demanding to maintain: encryption, patching and demonstrable compliance.

1. Encryption: protecting data at rest and in transit

Encryption is the line of defence when everything else fails. For machine images it works at several levels:

Encrypted EBS snapshots with AWS KMS, or Azure Disk Encryption and Google CMEK on other clouds.
Customer-managed keys (CMK) with automatic rotation and minimal access policies.
Encryption by default enabled at the account level so no image is ever born unencrypted.
Secrets managed outside the image: never bake passwords or tokens; inject them at runtime with Secrets Manager, Vault or Parameter Store.

2. Patching: the race against CVEs

Vulnerabilities are published every day. An image is secure the day you create it, and a little less every day after that. Patch management in an immutable world is not about updating live servers, but about rebaking frequently.

Rebuild cadence: rebuild the base image at least monthly, and urgently on a critical CVE affecting your stack.
Scanning in the pipeline: integrate Trivy, Grype or Amazon Inspector to catch CVEs before publishing.
Quality gate: block publication if vulnerabilities appear above a threshold, for instance critical or exploitable high ones.
SBOM: generate a Software Bill of Materials to know exactly what each image contains and respond quickly when the next Log4Shell lands.

3. Compliance: prove it, do not just do it

In an audit, being secure is not enough: you have to prove it with evidence. Well-governed images produce that evidence naturally.

Framework	What it expects from your images	Evidence you can provide
SOC 2	Consistent, monitored security controls	Hardening reports and build logs
ISO 27001	Vulnerability management and change control	CVE scans, versioning and SBOM
PCI DSS	Secure configuration and documented patching	CIS Benchmark and rebuild history
ENS / GDPR	Encryption and data minimisation	KMS encryption and no personal data in the image

How secure image practices translate into compliance evidence.

The new regulatory context of 2026

The regulatory environment is tightening. In 2026 key stages of the European AI regulation and new product liability directives come into force, and several jurisdictions are strengthening their cloud governance and compliance requirements. The practical translation: traceability of what software you run and how you secure it stops being optional. An auditable image chain is your best insurance.

Image security checklist

Encryption by default enabled and snapshots with a CMK.
No baked-in secrets; external credential management.
CVE scanning on every build with a quality gate.
Periodic rebuilds and rebuilds on critical CVEs.
CIS Benchmark applied and validated.
SBOM and build logs archived as evidence.
Safe retirement of obsolete images.

Frequently asked questions

How often should an immutable image be patched?

It is not hot patched: it is rebuilt. A monthly cycle is a good minimum, with extraordinary rebuilds on critical CVEs affecting your software.

What is an SBOM and why do I need one?

An SBOM is the inventory of all the software and dependencies in your image. It lets you know in minutes whether a new vulnerability affects you, and it is increasingly required for compliance.

Does encryption affect performance?

EBS encryption with KMS is transparent and its performance impact is practically imperceptible for most workloads.

At imaxe.cloud we apply encryption, scanning and continuous updates to our images so you start from a base you can defend in any audit.

CIS hardening of AMIs: a practical guide to hardening your EC2 images

2026-06-09T00:00:00Z

The CIS Benchmarks are secure configuration guides published by the Center for Internet Security, drawn up by expert consensus. They cover operating systems —Amazon Linux, Ubuntu, RHEL, Windows— with hundreds of concrete recommendations: file permissions, kernel parameters, password policies, services that should be disabled or audit configuration.

Applying hardening to the AMI —rather than to every already-deployed server— is the most efficient route: you harden once and every instance is born secure. It is the “secure by default” approach demanded by frameworks such as ISO 27001, SOC 2, PCI DSS or national security schemes.

L1 and L2 levels: how far to tighten

CIS defines profiles by level. Choosing well avoids breaking applications through excess of zeal.

Profile	Goal	When to use it
Level 1 (L1)	Essential security with no relevant functional impact	Starting point for most workloads
Level 2 (L2)	Defence in depth for sensitive environments	Regulated data, high risk; may need tuning
STIG	US Department of Defense requirements	Government or defence contracts

CIS hardening profiles and their scope of application.

How to automate hardening in the image

Manual hardening neither scales nor is auditable. These are the three most common ways to bring it into the build pipeline:

EC2 Image Builder with CIS components: AWS offers integration with managed CIS levels that apply and validate the benchmark during the build, with the option of CIS Hardened images in the Marketplace.
Ansible with a hardening role: reuse CIS-based roles for Linux inside a Packer provisioner; it is portable across clouds.
Your own idempotent scripts: for specific cases, with the advantage of full control and the disadvantage of maintenance.

High-impact controls that must not be missing

If you had to prioritise, these CIS controls deliver the greatest risk reduction at the lowest cost:

Disable direct root access over SSH and force key-based access, never passwords.
Remove unnecessary packages and services to reduce the attack surface.
Configure the host firewall (firewalld or nftables) with default deny.
Enable auditing (auditd) and centralised event logging.
Apply secure kernel parameters (sysctl) against spoofing and network attacks.
Strict password policies and account lockout.
Correct permissions on critical files: /etc/passwd, /etc/shadow and the boot directories.

Validate that hardening really was applied

Hardening without verifying is an act of faith. Add an automated validation stage that scores the image against the benchmark and fails the build if it misses the threshold.

CIS-CAT, InSpec or OpenSCAP scan the freshly baked instance and generate a compliance report.
Pass threshold: define, for instance, “≥ 95 % of L1 controls passed” as a quality gate.
Audit evidence: keep the report as a build artefact; it will be pure gold at your next SOC 2 or ISO audit.

The balance: security without breaking the application

The classic mistake is applying L2 blindly and discovering the application no longer starts. The sensible strategy: start from L1, measure and raise L2 controls selectively, testing in a staging environment. Document every justified exception; a control disabled with a recorded reason is acceptable in an audit, one disabled silently is not.

Frequently asked questions

Does CIS hardening slow my instances down?

The performance impact of the L1 profile is practically nil. Some intensive L2 auditing controls can add overhead, which is why they are applied selectively and measured.

Do I need to buy CIS Hardened images or can I do it myself?

You can harden yourself with Ansible, OpenSCAP or EC2 Image Builder components. The CIS Hardened images in the Marketplace save work and include validation, but they are not indispensable.

Does hardening alone make me ISO 27001 or PCI DSS compliant?

Hardening is an important technical control, but compliance also covers processes, policies and evidence. Hardening your AMIs gets you a long way, but it does not replace the rest of the compliance framework.

At imaxe.cloud we start from images hardened according to industry good practice so you deploy on a secure foundation.

AMI lifecycle: versioning, encryption and automated cleanup

2026-06-05T00:00:00Z

Many teams treat an AMI as something you create once and forget. The problem shows up months later: dozens of untagged images, EBS snapshots nobody knows whether they can delete, and a bill that grows without explanation. Managing the lifecycle of an AMI means treating it as a software artefact with a birth, versions, maturity, deprecation and retirement.

Good image governance cuts costs, improves security —nobody accidentally launches an unpatched image from a year ago— and makes compliance audits easier.

Phase 1 — Versioning with meaning

Versioning is the backbone. Without it, “the latest good AMI” is a hallway conversation, not a fact. We recommend a readable, consistent scheme.

Versioned name: for instance imaxe-ubuntu22-nginx-2026.07.1, with product, base and calendar version.
Mandatory tags: Version, GitCommit, BuildDate, Owner, Environment, CISLevel, Status.
Immutable: one version, one artefact. Never modify a published AMI; create a new version.
Central registry: use AWS Systems Manager Parameter Store to hold the ID of “the current production AMI” so your Launch Templates read it by reference.

Phase 2 — End-to-end encryption

An AMI’s data lives in EBS snapshots. If they are not encrypted, any poorly governed copy is a potential leak. Encryption should be the norm, not the exception.

Encryption by default: enable EBS encryption by default at account and region level.
Customer-managed keys (CMK): use your own KMS key instead of the AWS default one to control permissions and rotation.
A copy is a re-encryption: when copying an AMI to another region or account, take the chance to re-encrypt it with the destination key.
Share with KMS grants: if you distribute the AMI to other accounts, grant key access with minimal policies.

Phase 3 — Deprecation: warn before deleting

AWS lets you mark an AMI as deprecated with a date. From that moment it stops appearing by default in searches, but it still works for anyone referencing it explicitly. It is the civilised middle ground between “current” and “deleted”: you warn, you give room to migrate and you avoid breaking deployments.

Phase 4 — Automated cleanup (and the hidden cost of snapshots)

Here is where the money is. When you delete an AMI, its associated EBS snapshots are not removed automatically. That is the number-one cause of storage bills that grow mysteriously. A retirement policy must deregister the AMI and then delete its orphaned snapshots.

Retention policy: keep N recent versions (for example the last three) and retire the rest.
Automate with the cloud: Amazon Data Lifecycle Manager (DLM) can manage image creation and deletion by policy.
Hunt orphaned snapshots: periodically audit snapshots with no associated AMI and delete them.
Never delete blindly: check that no active instance or Launch Template depends on the AMI before retiring it.

Lifecycle summary table

Phase	Key action	Tool or service
Creation	Reproducible build and tagging	Packer / EC2 Image Builder
Encryption	Snapshots encrypted with a CMK	AWS KMS + EBS default encryption
Distribution	Multi-region or multi-account copy and re-encryption	AMI copy / AWS RAM
In force	Registry of the current ID	SSM Parameter Store
Deprecation	Mark deprecated with a date	`ec2 enable-image-deprecation`
Retirement	Deregister and delete snapshots	DLM / scheduled scripts

The six phases of AMI governance and how to automate them.

Metrics you should watch

Average age of the AMIs in use: the lower, the better patched.
Number of orphaned snapshots and their monthly cost.
Percentage of encrypted AMIs, with a target of 100 %.
Time from a critical CVE to the new published image, the patch MTTR.

Frequently asked questions

Why is my EBS bill rising if I already deleted the AMIs?

Because deregistering an AMI does not delete its snapshots. You must remove them explicitly. Audit orphaned snapshots regularly; they are usually the biggest hidden cost.

Is it safe to share an encrypted AMI with another account?

Yes, as long as you grant access to the KMS key with a specific grant and minimal permissions. Without that access, the destination account cannot launch the image.

How many versions of an AMI should I keep?

It depends on your rollback and compliance needs, but keeping between two and four recent versions is usually a good balance between rollback safety and cost.

At imaxe.cloud we design our images with versioning and encryption from the start, so their lifecycle is predictable and auditable.

Golden AMI with Packer: how to build a reproducible pipeline step by step

2026-06-02T00:00:00Z

A golden AMI is a preconfigured, hardened and validated Amazon Machine Image that serves as the single template for launching identical EC2 instances. Instead of booting an empty server and installing dependencies by hand every time, you bake everything once —patched operating system, agents, runtime, configuration and security controls— and reuse it on every deployment.

This approach is the foundation of immutable infrastructure: you do not hot-patch servers, you build a new image and replace the instances. The result is less configuration drift, faster boots under autoscaling, and deployments you can audit and roll back.

Golden AMI versus bootstrapping at boot

There are two philosophies. With bootstrapping, the instance configures itself at boot (user-data, Ansible pull, cloud-init). It is flexible but slow and fragile: if a package repository goes down, your autoscaling fails. In the golden AMI (baking) model the heavy lifting happens once, in the pipeline; boot is nearly instantaneous and deterministic. Most mature teams combine both: they bake what is stable and leave to boot only the configuration that varies by environment.

Why Packer

Packer, from HashiCorp, is the de facto standard tool for building machine images automatically and across clouds from a single template. You define the image as code (HCL2); it launches a temporary instance, applies your provisioners, creates the AMI and destroys the temporary resources. The same template can produce images for AWS, Azure and GCP, which makes it ideal if you publish on several clouds.

Reproducible: the image is described in a file versioned in Git.
Multicloud: a single flow for AMI, Azure Managed Image and GCP Custom Image.
Integrable: it fits into CI/CD (GitHub Actions, GitLab CI, CodePipeline).
Auditable: every build is recorded, with its manifest and artefacts.

Anatomy of a Packer template (HCL2)

A modern template is organised in blocks. The source block defines the builder (for example amazon-ebs), the base AMI, the instance type and the region. The build block chains the provisioners that install and configure software. The post-processors generate artefacts such as a JSON manifest with the resulting AMI ID.

A minimal annotated example

source "amazon-ebs" "app" — starts from an official base AMI looked up dynamically with a data "amazon-ami" filtering by owner and name pattern, so you do not pin an ID that will expire.

provisioner "shell" — runs installation and update scripts (dnf update -y, runtime installation, CloudWatch agent, SSM agent).

provisioner "ansible" — if you already have Ansible roles, reuse them to configure the image idempotently.

post-processor "manifest" — writes manifest.json with the artifact_id, which your pipeline reads to know which AMI was born.

The pipeline step by step

This is the flow we recommend for taking a golden AMI from commit to production safely and repeatably:

Step	What happens	Typical tool
1. Commit	You change the template or scripts and push to Git	Git / PR review
2. Validate	`packer fmt` + `packer validate` check the syntax	Packer, CI
3. Build	Packer launches a temporary instance and applies provisioners	Packer
4. Harden	The CIS Benchmark is applied and credentials are cleaned	Ansible / CIS
5. Scan	Vulnerability and secret scanning	Trivy, Inspector
6. Test	An instance is booted and validated	InSpec / Goss
7. Tag & version	The AMI is tagged (version, commit, date)	AWS CLI
8. Distribute	It is shared or copied to other regions or accounts	AWS RAM / copy
9. Deploy	The AMI is referenced in the Launch Template	Terraform / ASG

Reference flow for a golden AMI pipeline in nine stages.

Best practices that make the difference

Never pin a base AMI by ID: look it up dynamically by owner and name so you always inherit the latest patches.
Version the image with a clear scheme (for example app-2026.07.1) and store the Git commit in the AMI tags.
Clean up before sealing: delete logs, shell histories, temporary SSH keys and package caches so you do not leak secrets.
Always scan: integrate Trivy or Amazon Inspector so you never publish known CVEs.
Encrypt the snapshots with your own KMS key from day one.
Automate expiry: mark old versions as deprecated and delete them to keep costs under control.

Packer or EC2 Image Builder: which should I choose?

If you work exclusively on AWS and value native integration with Inspector, managed CIS components and zero infrastructure to maintain, EC2 Image Builder is a solid option with no licence cost. If you need to build for several clouds from the same template, or you already have a HashiCorp ecosystem (Terraform, Vault), Packer gives you more portability. They are not mutually exclusive: many teams use Packer for multicloud logic and Image Builder for internal AWS pipelines.

Frequently asked questions

How often should I rebuild the golden AMI?

At a minimum with every operating system patch cycle (monthly is usually a good rhythm) and whenever a critical CVE is published for your stack. An automated pipeline lets you rebuild on demand in minutes.

Can I use the same Packer template for AWS and Azure?

Yes. Packer supports multiple builders in one build. You share the provisioners and only change each cloud’s source block, producing an AMI, a Managed Image and a Custom Image in parallel.

Golden AMI or containers?

It is not one or the other. Golden AMIs are ideal for the host layer and for non-containerised workloads; containers live on top. In fact, a hardened golden AMI makes an excellent base for your Kubernetes nodes.

At imaxe.cloud we build and maintain hardened, up-to-date base images so your pipeline starts from a reliable foundation.

Zabbix 7.0 LTS now available: what changes in our AMI

2026-05-28T00:00:00Z