AlmaLinux 10 on AWS: From First Boot to Year Three with the ProComputers Images

Most articles about cloud images stop at the moment the instance turns green in the EC2 console. That is the easy part. The real questions show up later: what happens when a critical OpenSSL advisory lands the morning you scale out, when the database disk fills up on a Friday night, or when an auditor asks why one server in the fleet behaves differently from the others.

This guide takes a different route through the three AlmaLinux 10 images that ProComputers publishes on AWS Marketplace. Instead of describing each image in isolation, it follows a server through its life: the decision before launch (Day 0), the first boot and configuration (Day 1), and the long stretch of patching, scaling and storage growth that follows (Day 2 and beyond). At each stage you will see which of the three images fits best, and why.

The three images are:

• AlmaLinux 10: the hardened, general-purpose baseline.
• AlmaLinux 10 Latest: the same base, but it installs all pending security updates during its first boot.
• AlmaLinux 10 LVM: the same base, with the root disk built on LVM (Logical Volume Manager) so storage can grow while the server keeps running.

Why AlmaLinux 10 deserves a fresh look

If you ran AlmaLinux 8 or 9, it is tempting to treat version 10 as "the same thing, newer." In practice, AlmaLinux 10 is the release where the project started to show its own personality while keeping its promise of compatibility with Red Hat Enterprise Linux.

AlmaLinux is governed by the nonprofit AlmaLinux OS Foundation and built to stay ABI (Application Binary Interface) compatible with RHEL 10. Software certified or packaged for RHEL 10 runs on it without changes, and the same dnf, systemd, SELinux and firewalld tooling applies. The 10.x series is built on the Linux 6.12 kernel, and the most recent minor release, AlmaLinux 10.2 "Lavender Lion," shipped in May 2026 with Python 3.14, PostgreSQL 18, MariaDB 11.8, PHP 8.4 and Ruby 4.0 available from the repositories.

Where AlmaLinux 10 differs from RHEL 10 is in a set of deliberate additions:

• x86-64-v2 support. RHEL 10 requires x86-64-v3 CPUs. AlmaLinux ships an extra x86-64-v2 build, which matters for on-premises hardware and some virtualization hosts. On modern EC2 instance types this is rarely a concern, but it is a sign of how the project thinks about long-lived infrastructure.
• Frame pointers enabled. AlmaLinux builds with frame pointers on, which makes system-wide profiling with tools such as perf far more useful. If you have ever tried to read a flame graph full of broken stacks, you will appreciate this on performance-sensitive EC2 workloads.
• CRB enabled by default (10.2). The CodeReady Builder repository, which many EPEL packages depend on, is switched on out of the box, removing one of the most common setup steps.

The practical takeaway for AWS users: you get a RHEL 10 compatible system with a long support horizon, plus a few engineering choices that make troubleshooting and package availability easier. AlmaLinux 10 is expected to receive security updates well into the next decade, which is exactly what you want under servers that may live for years.

What all three images share

Before comparing the images, it helps to know what does not change between them. ProComputers builds all three from the same hardened base and refreshes them as upstream publishes fixes. Each one:

• Runs SELinux in enforcing mode. Services are confined from the first boot, not after someone remembers to flip a setting.
• Uses SSH key authentication only. You log in as ec2-user with the key pair chosen at launch. Password logins and direct root logins are disabled. AWS documents the connection process, including from Windows, in its guide to connecting to Linux instances over SSH.
• Ships with cloud-init. User data runs on first boot, SSH keys are injected, and the hostname is set automatically.
• Has ENA networking enabled. The Elastic Network Adapter is active, so current Nitro-based instance types get the throughput and low latency they are designed for.
• Supports the EC2 instance metadata service without extra configuration.
• Keeps a minimal package set. Fewer packages mean a smaller attack surface, fewer CVEs to triage and fewer findings in vulnerability scans.
• Pulls updates from the official AlmaLinux repositories. Errata arrive on the upstream timeline through ordinary dnf updates. There is no private mirror sitting between you and the fixes.

Each release is validated by ProComputers across several instance families before it is published. That shared foundation is the reason you can mix the three images in one environment without creating three different operating models.

Day 0: Choosing the image before you launch

The choice between the three images comes down to two questions: how do you want patching to work at launch, and how do you expect storage to change over time?

Question 1: Should the server patch itself at first boot?

The standard AlmaLinux 10 image boots exactly the package set that was tested and published. That is what you want when reproducibility matters more than freshness: a regulated environment where every change goes through a ticket, a golden-image pipeline where you run your own dnf update and bake the result, or a test suite that must run against a known state.

AlmaLinux 10 Latest takes the opposite stance. During its first boot it installs every pending security update from the official repositories, so a server launched today is patched to today's level, not to the date the image was built. That is ideal when instances come and go often: Auto Scaling groups, short-lived CI runners, spot fleets and any setup where nobody will log in to run updates by hand.

Question 2: Will the disk need to grow?

If the server's data footprint is predictable, or if data lives elsewhere (S3, RDS, EFS), a standard partition layout is perfectly fine. Both AlmaLinux 10 and AlmaLinux 10 Latest cover that case.

If you expect growth that is hard to forecast, such as a self-managed PostgreSQL instance, a file server, a log aggregator or a Git server, the AlmaLinux 10 LVM image makes life easier. Because the root disk sits on logical volumes, you can enlarge an EBS volume and extend the file system online, move space between volumes, or add new EBS volumes into the same volume group. No rebuild, no restore, no maintenance window.

A quick decision guide

Start with storage, because it is the one choice you cannot easily undo later.

Will data grow on the instance itself? If you run a self-managed database, a file share or a log store, the answer is almost certainly yes, and you should pick AlmaLinux 10 LVM. If you also want it patched at launch, add package_upgrade: true to your cloud-init user data and you get both: a fully patched server whose storage can still grow online.

Is the disk size predictable, or does the data live in S3, RDS or EFS? Then the LVM layout adds nothing you need, and the decision moves to patching:

• Do instances come and go often? For Auto Scaling groups, spot fleets, CI runners and other servers nobody logs in to, choose AlmaLinux 10 Latest. Every new instance starts at today's patch level without anyone lifting a finger.
• Does every change go through review? For change-controlled production, golden-image pipelines and test environments that must be reproducible, choose the standard AlmaLinux 10 image. It boots exactly the tested package set, and you decide when updates are applied.

Running a mix of all of the above? That is fine too. The three images share the same hardened base, so a fleet can use Latest for the stateless web tier, LVM for the database and the standard image for anything that runs through a strict release process, without adding a second operating model.

Day 1: First boot and configuration

Launching

All three images are launched the same way. Subscribe on the AWS Marketplace listing, choose a region and instance type, pick a key pair and a security group that allows SSH from your address range, and launch. Because the images are identical in every region, the same Terraform module or CloudFormation template works everywhere; only the AMI ID changes per region.

Once the instance is running:

ssh -i ~/.ssh/my-key.pem ec2-user@<public-ip-or-dns>

Use sudo for administrative tasks. Root login over SSH is intentionally disabled.

Letting cloud-init do the boring work

The most valuable thing you can do on Day 1 is make it unnecessary to log in at all. cloud-init reads the user data you pass at launch, so a small configuration can turn a fresh instance into a working web server with no manual steps:

#cloud-config
hostname: web-01
package_upgrade: false
packages:
  - nginx
runcmd:
  - systemctl enable --now nginx
  - firewall-cmd --permanent --add-service=http --add-service=https || true
  - firewall-cmd --reload || true

A few notes on this example:

• On the AlmaLinux 10 Latest image you can leave package_upgrade off, because the image already patches itself at first boot. On the standard image, set it to true if you want the same behaviour for a particular launch.
• The firewall lines use || true so the script does not fail if firewalld is not running in your configuration. Many teams rely on security groups alone; others prefer defence in depth with both.
• SELinux stays enforcing. Nginx serving content from its default locations works without changes. If you move content elsewhere, label it correctly with semanage fcontext and restorecon rather than disabling SELinux.

From here, hand over to your configuration management tool of choice. A common pattern is for cloud-init to install the Ansible pull agent or register the instance with an existing control node, then let Ansible own everything after that.

Checking what the Latest image did at first boot

If you launched AlmaLinux 10 Latest, it is worth knowing how to confirm what the first boot changed. The first boot takes a little longer than with the standard image because updates are being installed, which is expected.

# Show the most recent package transactions
sudo dnf history

# Check whether a reboot is recommended (for example, after a kernel update)
sudo dnf needs-restarting -r

If a new kernel was installed during that first boot, plan a reboot before putting the instance into service, or handle it in your launch automation. For Auto Scaling groups, the usual approach is to bake this into a lifecycle hook or health check so instances only receive traffic once they are fully patched and running the current kernel.

Day 1 on the LVM image: know your layout

On AlmaLinux 10 LVM, take a minute to look at how the disk is organised. Names can vary between image releases, so read them from the system rather than assuming them:

lsblk
sudo pvs
sudo vgs
sudo lvs
df -hT

Note the physical volume (a partition on the root EBS device, usually something like /dev/nvme0n1pN on Nitro instances), the volume group name and the logical volume that holds /. You will need these on Day 2.

Day 2 and beyond: living with the server

Patching without surprises

All three images pull errata from the official AlmaLinux repositories, so the patching model is the same as any RHEL-compatible system:

# Review available security updates
sudo dnf updateinfo list --security

# Apply only security updates
sudo dnf upgrade --security

# Or apply everything
sudo dnf upgrade

For unattended updates, dnf-automatic is available from the repositories and can be configured to download, apply, or only notify. Many teams combine it with AWS Systems Manager Patch Manager for fleet-wide reporting.

Here is where the choice between the standard and Latest images keeps paying off over time:

• Long-lived servers on either image are patched in place, through your normal maintenance process.
• Short-lived servers on the Latest image never need in-place patching at all. Each replacement instance starts at the current patch level, so your fleet stays fresh simply by cycling instances. This is the "immutable infrastructure" model, and it removes a whole class of patching tickets.

Because ProComputers rebuilds the images when upstream publishes important fixes, even the standard image does not drift too far from current. The gap between "image built" and "today" stays small, which keeps the first dnf upgrade on a new standard instance short.

Growing storage on the LVM image

This is where AlmaLinux 10 LVM shows why it exists. Suppose a PostgreSQL server has outgrown its root volume. With LVM, the fix is a few commands and no downtime.

Step 1: Enlarge the EBS volume in the EC2 console or with the AWS CLI:

aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --size 200

Step 2: Grow the partition that holds the physical volume. The growpart tool comes from the cloud-utils-growpart package; install it if it is not present:

sudo dnf install -y cloud-utils-growpart   # only if growpart is missing
sudo growpart /dev/nvme0n1 <partition-number>

Step 3: Tell LVM the physical volume is bigger:

sudo pvresize /dev/nvme0n1p<partition-number>

Step 4: Extend the logical volume and its file system in one step:

sudo lvextend -r -l +100%FREE /dev/<vg-name>/<lv-name>

The -r flag resizes the file system along with the logical volume. Check the result with df -hT. The database never stopped.

LVM gives you more than in-place growth:

• Add a second EBS volume and run pvcreate and vgextend to add it to the existing volume group when a single volume is not enough or you want to spread I/O.
• Create dedicated logical volumes for /var/lib/pgsql, /var/log or application data, so a runaway log file cannot fill the root file system.
• Start small. Since growth is cheap and online, you can provision modest EBS volumes at launch and expand only when monitoring shows you need to, instead of paying for headroom you may never use.

Workloads that fit AlmaLinux 10 on EC2

To make the choice concrete, here is how typical workloads map to the three images:

• Web servers and APIs (Nginx, Apache, application runtimes): AlmaLinux 10 Latest behind an Auto Scaling group, so every new node starts patched. SELinux confines each service.
• Self-managed databases (PostgreSQL, MySQL, MariaDB, MongoDB): AlmaLinux 10 LVM, so data volumes can grow online and logs can live on their own logical volume.
• CI/CD and DevOps tooling (Jenkins controllers, GitLab runners, Ansible control nodes): AlmaLinux 10 Latest for disposable runners; AlmaLinux 10 LVM for a Jenkins controller whose workspace and artifact storage keep growing.

Migrating from AlmaLinux 8 or 9, or from other RHEL clones

Many readers will arrive here from an older release. A few practical points:

• Prefer new instances over in-place upgrades. Launch AlmaLinux 10 alongside the existing server, deploy your application with the same automation, test, and switch traffic. It is cleaner and easier to roll back than upgrading a running system across major versions.
• RHEL 10 compatibility works in your favour. If a vendor certifies its software for RHEL 10, it is built for the same ABI that AlmaLinux 10 provides.
• Moving from Rocky Linux or Oracle Linux is mostly a non-event at the application level, since they target the same RHEL 10 base. ProComputers also publishes hardened Rocky Linux 10, Oracle Linux 10 and RHEL 10 images if your organisation standardises on a different distribution for some workloads.

If you need to stay on an older major version for now, hardened AlmaLinux 9 and AlmaLinux 8 images are available too, and the operational model described in this article applies to them as well.

Frequently asked questions

How do I log in?
Use SSH with the ec2-user account and the key pair you selected at launch. Password authentication and direct root login are disabled. See AWS's SSH connection guide for details.

Are these images compatible with RHEL 10?
Yes. AlmaLinux 10 is designed to be ABI compatible with Red Hat Enterprise Linux 10, so RHEL 10 packages and applications run without modification.

Does the Latest image change after launch?
It installs pending security updates during the first boot. After that it behaves like any other AlmaLinux 10 server and is patched through dnf on whatever schedule you choose.

Can I convert a standard instance to LVM later?
Not in place without significant effort. If you think you will need flexible storage, start with the AlmaLinux 10 LVM image.

About ProComputers

ProComputers has been publishing Linux images on AWS for more than a decade. Every image is kept small, hardened and refreshed on a steady schedule, validated across multiple instance families, and tuned for EC2. The goal is simple: let your engineers spend their time on the services your business runs, not on rebuilding the same operating system baseline again and again.

ProComputers is also a proud sponsor of the AlmaLinux OS Foundation and the Rocky Enterprise Software Foundation, supporting the open source projects these images are built on.

Conclusion

AlmaLinux 10 is a strong foundation for EC2 workloads: RHEL 10 compatible, community governed, supported for many years, and improved with practical additions like frame pointers and CRB enabled by default. The three ProComputers images let you match that foundation to how your servers actually live:

• Choose AlmaLinux 10 when you want a reproducible, hardened baseline under your own change control.
• Choose AlmaLinux 10 Latest when instances come and go and every one should start fully patched.
• Choose AlmaLinux 10 LVM when data grows and downtime for storage changes is not an option.

Whichever you pick, you get the same SELinux-enforcing, SSH-key-only, cloud-init-ready, ENA-enabled base, so mixing them across a fleet adds flexibility without adding complexity.

Looking for the Rocky Linux equivalent? Read Rocky Linux 9 on AWS: Three Hardened Images from ProComputers.