RHEL for SAP HANA, priced against the memory.

The RHEL for SAP HANA subscription is the Red Hat certified RHEL line that the SAP HANA support matrix accepts for the HANA database tier. The subscription delivers the operating system, the cluster stack required for HANA system replication, the extended life cycle that aligns with the HANA release cadence, and the supported configurations that the SAP HANA hardware certification programme expects. The subscription is sold per host and is priced against the memory configuration of the certified hardware on most catalogue terms, with tier breaks at the memory points that the HANA hardware certification recognises.1

The memory tier pricing is the structural feature that most distinguishes the HANA line from the broader SAP Applications line discussed in RHEL for SAP Applications licensing. A HANA host carrying a memory configuration in the lower tier carries a different per host price than a HANA host in the upper tier; the procurement register should reflect the right tier for each host. The most common drift on the HANA reading is the host that has been memory upgraded across a fiscal year while the procurement register continues to carry the old tier; the reading is exposure for the period of the upgraded memory configuration on the lower priced line.

The cluster stack bundling parallels the SAP Applications bundle. A HANA host running HANA system replication carries the certified HANA line and does not require a parallel High Availability add on; the cluster stack is included. The structural reading parallels the one in the High Availability add on note and the broader bundled SAP Applications treatment. A parallel add on line on a HANA host is overpayment, not redundancy.

HANA estates run in two structurally different topologies, and the procurement register should reflect the topology, not the buyer's narrative about the topology.

The first topology is scale up. A single HANA host carries the entire HANA database, with memory scaled vertically against the certified hardware list. The procurement register carries one HANA line per host, priced against the memory tier of the host. A HANA system replication pair under scale up runs as two single host HANA databases, each carrying its own line; the primary and the secondary each count, and the procurement register reflects two lines.

The second topology is scale out. The HANA database is distributed across multiple hosts, each of which contributes memory and compute to the total database; the cluster manager arbitrates the worker and master roles across the host pool. The procurement register carries one HANA line per cluster member host, sized to the memory tier of each host. A scale out HANA system with eight worker hosts and one master carries nine HANA lines. The standby host on a scale out cluster also counts; the standby is a registered member of the cluster regardless of whether it carries an active worker assignment at any moment.2

The drift on the scale out topology is the standby host that the buyer's procurement register omitted. The reading is exposure for the period of cluster membership; the remediation is to attach the HANA line going forward. The pattern is structurally similar to the silent cluster member reading walked in the High Availability note; the HANA topology is more expensive per host and the finding therefore weighs heavier in the settlement reading.

The two SAP certified lines run on different tiers of the same estate. The SAP Applications line covers the NetWeaver and S/4HANA application server hosts; the HANA line covers the database hosts; a healthy procurement register carries both lines on different host inventories and no overlap. The drift is the host that runs both an application server component and a HANA database on the same physical host, which is rare in production but recurs on smaller landscapes and on consolidated development environments.

The reading on the dual purpose host is procedurally awkward. The SAP support matrix expects the host to carry the HANA line where HANA is the dominant workload; the procurement register frequently carries the SAP Applications line because the host first arrived as an application server. The remediation is to attach the HANA line going forward and to retire the SAP Applications line on the host, or to split the workload across separate hosts on the next provisioning cycle. The reading sits inside the broader treatment of aligning subscription to deployment.

The reading also interacts with the broader treatment of HANA on certified hardware platforms. HANA on IBM Power runs on the certified Power platform with its own RHEL line, discussed in RHEL on IBM Power licensing. HANA on Intel hosts carries the standard HANA line. HANA in a public cloud carries the cloud variant of the line, with the cloud provider's certified hardware as the basis. The cross industry reading on HANA audit posture in healthcare sits in healthcare audit considerations.3

The audit reading on the HANA line walks four data sources. The HANA Basis host inventory, the memory configuration on each host, the cluster manager configuration showing each cluster member, and the procurement register of HANA lines by host. The reading is internally consistent when every HANA cluster member carries a HANA line, the memory tier on each line matches the actual memory configuration on the host, and no parallel SAP Applications or High Availability lines overlap on the HANA hosts.

Three inconsistencies recur. The first is the memory tier drift. A host has been memory upgraded across a fiscal year; the procurement register carries the old tier. The reading is exposure on the differential, and the remediation is the tier upgrade at the next renewal. The pattern is the single most expensive finding on HANA readings in the practice's observation; the differentials at the upper tier breaks are significant and the period of operation on the wrong tier compounds the finding.

The second is the silent cluster member. A scale out cluster has been expanded across a fiscal year; the procurement register has not caught up; the new worker carries no HANA line. The reading is exposure for the period of cluster membership. The remediation is the attach at the next renewal. The cluster manager configuration is the audit ready artifact, not the buyer's documentation. The narrative the buyer provides about which hosts are in the cluster is not authoritative; the cluster manager is.4

The third is the retired host. A scale out cluster has shrunk across a fiscal year; the procurement register continues to carry the lines for the retired worker. The reading is overpayment; the remediation is the retirement at the renewal cycle. The pattern is structurally identical to the orphan line walked in the broader add on note, and the savings frequently fund the tier upgrade or the cluster member attach on the same estate.

The renewal posture on RHEL for SAP HANA has three habits. The list is short by design; the same three habits, applied honestly, retire the recurring drift on most HANA estates within a single renewal cycle.

The first habit is the HANA topology of record. A short artifact, owned by the HANA Basis team and reviewed by the procurement team, that names every HANA host, the memory configuration on each host, the cluster role each host plays, and the line that covers it. The artifact is reviewed quarterly. The artifact sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the memory tier reconciliation at each renewal. The procurement register is read against the memory configuration on each HANA host; the tier breaks are reset where the memory has crossed them; the procurement register is updated before the next renewal cycle closes. The pattern overlaps with the broader treatment of recoverable over entitlement cost on the downward direction and with under entitlement audit exposure on the upward direction.

The third habit is the scale out cluster reconciliation. The cluster manager configuration is read against the procurement register; new workers are attached; retired workers are detached; the procurement register reflects the cluster member count at the renewal. The broader treatment of renewal cycle discipline sits in renewal negotiation; the sibling treatment of the IBM Power variant in RHEL on IBM Power uses a different counting unit and warrants its own reading.

For the RHEL practice hub, see the RHEL practice. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.