Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Public Cloud Guide / Public cloud images
Applies to SUSE Linux Enterprise

2 Public cloud images

SUSE offers a variety of different product images for different use cases in partner cloud provider frameworks. Learn how to find the image that meets your use case.

2.1 Image lifecycle

All SUSE public cloud images follow a refresh cycle up to the point of deletion. The refresh cycle follows a 'rolling' three month time frame. What this means:

  • Images in an active state are refreshed every three months. Replaced images are moved to the deprecated state.

  • If a critical security vulnerability occurs, images in active and inactive states are updated as soon as possible once the fix for the affected code is available. For images in active state the three month timer restarts with this forced replacement.

    SUSE is committed to address all security vulnerabilities disclosed through the Common Vulnerabilities and Exposures process (CVE) and a score of 9.0 or greater in the Common Vulnerability Scoring System (CVSS). For more information about the effects and rating of CVEs, refer to the SUSE CVE database.

The life cycle of an image consists of four different states:

SUSE public cloud image states

Active images are fully supported and refreshed at least every three months. The duration lasts until the image is replaced by a newer image version.


Inactive images are supported following the rules of LTSS or ESPOS and will only get refreshed for critical security updates. The duration term is defined by the product. For more information, refer to https://www.suse.com/de-de/support/policy-products/#cloud


Deprecated images may no longer be supported. The status of support depends on the support status of the product in the image. Deprecated images are not made available in regions added after an image has been set to deprecated and images do no longer get refreshed. At the end of the six month deprecation period, images are subject to deletion. It is strongly discouraged to use deprecated images to create new instances.


Deleted images are no longer supported or available for instance creation.

Important: Only use active images for new instances

It is strongly recommended to only use active images to launch instances for new deployments.

2.2 Naming scheme

Names for SUSE's public cloud images consist of multiple parts that contain information about the product, its version, a time stamp indicating the release date of the image, and more. The general naming scheme for SUSE's public cloud images is as follows:


Not all components of this naming scheme are used in all frameworks.

SUSE public cloud image naming scheme

Abbreviated name of the product in lower case letters, e.g. suse-sles-15-sp3 or suse-manager-4-1-proxy. This part may also be search-optimized per cloud framework. For example the prefix suse- helps when searching for SUSE in the general catalog in Amazon Web Services.


Images can have different flavors such as chost or byos. If it is the default image of a product, this part will be omitted. Multiple FLAVOR attributes may be combined in an image name. For example sles-15-sp3-chost-byos is an image build based on SUSE Linux Enterprise Server 15 SP3 build as a container host using a BYOS (Bring Your Own Subscription) billing model. Images without byos in the name are set up the image is set up for PAYG (Pay As You Go) billing. For more information about the different billing models, refer to Section 1.3, “Plans”.

SUSE Linux Enterprise flavors
  • byos: Bring your own subscription (BYOS) image

  • chost: Minimal container host image

  • hardened: Pre-hardened images, see Section 2.5, “Hardened Images”

  • hpc: SUSE Linux Enterprise High Performance Computing image

  • sap: SUSE Linux Enterprise Server for SAP Applications image

  • sapcal: SAP Cloud Application Library image

Not all flavors are available for all could frameworks; some are provider-specific.

Amazon Web Services flavors
  • ecs: Amazon Elastic Container Service image

Microsoft Azure flavors
  • basic: PAYG image that only includes updates but no support

  • standard: Fully supported PAYG image


Upload date of the image in the format vYYYYMMDD (ISO 8601).


SUSE no longer supports or publishes para-virtualized images. The virtualization type was encoded as pv (para-virtualized) or hvm (hardware-assisted virtual machine). The hvm part of the image name has been retained in an effort to not break backward compatibility.


SUSE no longer publishes images that are based on hard disk (magnetic) backed storage. This used to be encoded as mag. All published images are backed by SSD. The ssd part of the image name has been retained in an effort to not break backward compatibility.


Either x86_64 or arm64. SUSE no longer supports or publishes 32 bit x86 images. Images with the i386 identifier are visible in Public Cloud Information Tracker data.

GENERATION (Microsoft Azure-only)

appended as gen2 for 2nd Generation VMs.

2.3 Public Cloud Information Tracker

The Public Cloud Information Tracker (PINT) provides information about the images SUSE publishes and servers that are part of the SUSE operated update infrastructure. PINT is available at https://pint.suse.com/ and provided as an API and command-line tool with the python3-susepubliccloudinfo package from the Public Cloud Module repository.

Screenshot of the SUSE Public Cloud Information Tracker (PINT)
Figure 2.1: Overview of SUSE Public Cloud Information Tracker (PINT)

Use the drop-down boxes to view images, servers, or both and filter by cloud framework, state, and region. You can also search for strings and adjust the number of results shown per page.

2.3.1 Images view

The following columns are shown in the Images view. Please note columns depend on the the cloud frameworks.

Columns in the Images view

Name of the image. For more information about the image naming scheme, refer to Section 2.2, “Naming scheme”.


State of the image. Can be one of active, inactive, deprecated, or deleted. For more information, refer to Section 2.1, “Image lifecycle”.


Name of the image that replaces another.

Replacement ID

ID of the image that replaces another. Only shown for Amazon, Oracle, and Alibaba; images on Google and Microsoft do not have IDs.

Published Date

Publication date of the image. Displayed in the format YYYYMMDD (ISO 8601).

Deprecated Date

Date the image was deprecated by a newer one. Displayed in the format YYYYMMDD (ISO 8601). Only shown for deprecated or deleted images.


Project of the image. Projects are used to organize Google Cloud Platform resources. Only shown for Google Cloud Platform


Region of the image.


Environment of the image. Only shown for Microsoft Azure.


Unique identifier of the image. While the Name of an image is the same across different regions, the ID is unique.


Uniform Resource Name of an image. While the Name of an image is different across the environments, the URN is the same. Only shown for Microsoft Azure.

Deleted on

Date the image was deleted in the format YYYYMMDD (ISO 8601). Only shown for deleted images.


Link to a detailed changelog that lists image configuration changes, CVE fixes, package version changes, and package changelogs. For more information, refer to Section 2.4, “Change information”

Image changelogs are only available for images that replace others. For initial images of new product versions, refer to the product's release notes.

2.3.2 Servers view

The following columns are displayed in the Servers view:

Columns in the Servers view

Host name of the server. Region servers do not have host names. Host names are not DNS resolvable.


IP address of the server.


Region of the server. For optimal performance SUSE provides servers in most regions of a cloud framework.


One of regionserver or smt. In every framework where SUSE operates an update infrastructure, the regionserver systems are randomly distributed across regions and the smt servers are available in most regions. Every region has smt servers assigned.

2.4 Change information

Whenever a new image gets released, you can review changes compared to the previously released image. Search for an image in PINT and click on its entry in the Changelog column.

Image change information is divided into different categories:

Image configuration changes

This category describes changes in the image setup; for example, if a new service was enabled, kernel parameters were changed, or if packages were added or removed.

CVE fixes

This category lists security fixes in the image. Entries are cross linked to the SUSE CVE database. For more information, refer to Section 2.1, “Image lifecycle”.

Package version changes

This category lists all packages that had version changes compared to the previous image and the version in that image.

Changelog information

This category shows a concatenated changelog of all packages that had changes.

Note: Change information for new product versions

Please note that that image change information is only available for updated images, meaning for images that replace previous images of the same product version.

For initial images of new product versions, refer to the product's release notes at https://www.suse.com/releasenotes.

To allow for automatic retrieval of image change information, all URLs follow the schema:


  • FRAMEWORK is the cloud framework as used in the pint command-line tool; i.e. one of alibaba, amazon, google, microsoft, or oracle.

  • IMAGE is the name of the image as shown by PINT, e.g. suse-sles-15-sp3-byos-v20220127-hvm-ssd-x86_64.

  • CHANGES is the category of the changes, i. e. one of cve_fixes, image_changes, package_changelogs, or package_version_changes. Do not forget the .html extension to complete the URL.

2.5 Hardened Images

To improve overall security, SUSE provides hardened images of some products. The images are hardened using OpenSCAP, a collection of open source tools that implement the Security Content Automation Protocol (SCAP) maintained by the National Institute of Standards and Technology (NIST). OpenSCAP supports automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement.

2.5.1 Pre-hardening

All images are pre-hardened to the extent they can safely be hardened without causing problems in public cloud frameworks. Certain rules can only be applied after instance creation, for example:

  • Rules that require having passwords set up. Passwords would have to be public if configured during image build. This would defeat the purpose of a secret password.

  • Rules that affect the network configuration. Networking is set up during instance creation, therefore it is not possible to limit access during image build.

  • Rules for custom partitioning. SUSE's public cloud images are partitioned to meet the requirements of the framework in which they are released. If your system needs to meet standards that require separate file systems for given directories, we recommend that you build your own images and use LVM or move those directories onto attached disks to get the strictest data separation possible.

  • Rules to remove packages. SUSE's public cloud images cater a wide range of use cases. Even if the number of packages is limited, it is impossible to determine what packages an instance requires.

2.5.2 Avialable OpenSCAP profiles

After instance creation, you can use the installed openscap packages to complete the hardening process using any of the following profiles:

Standard (standard.profile)

Basic OpenSCAP system security standard.

CIS Server Level 2 (cis.profile)

The Center for Internet Security Server Level 2 profile is considered to be defense in depth and is intended for environments where security is paramount. The recommendations associated with this profile can have an adverse effect on your organization if not implemented appropriately or without due care. For more information, refer to https://www.cisecurity.org.

Department of Defense STIG (stig.profile)

The Defense Information Systems Agency publishes Security Technical Implementation Guides (STIGs) for the Department of Defense. The STIG profile replaces the previous CIS Level 3 profile and provides all recommendations that are STIG specific. Overlap of recommendations from other profiles, i.e. CIS Level 1 and Level 2, are present in the STIG profile as applicable. For more information, refer to https://public.cyber.mil/stigs/.

HIPAA Security Rule (hipaa.profile)

In response to the Health Insurance Portability and Accountability Act (HIPAA) of 1996, the U.S. Department of Health and Human Services developed Security Standards for the Protection of Electronic Protected Health Information, commonly known as the HIPAA Security Rule. It establishes national standards to protect individuals' electronic personal health information (e-PHI) that is created, received, used, or maintained by a covered entity. For more information, refer to https://www.hhs.gov/hipaa/for-professionals/security/index.html.

Payment Card Industry Data Security Standard (pci-dss.profile)

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements to guide merchants to protect cardholder data. It is maintained by the PCI Security Standards Council (SSC) that was founded by all five major credit card brands Visa, MasterCard, American Express, Discover, and JCB. For more information, refer to https://www.pcisecuritystandards.org/document_library.

All profile files are available in the ComplianceAsCode repository.

For a complete list of rules that have been applied during pre-hardening, refer to pcs-hardening.profile. This profile is a combination of the STIG and CIS profiles minus rules that can only be applied after instance creation.

Images of SUSE Linux Enterprise Server for SAP Applications are hardened using a modified version of the profile called pcs-hardening-sap.profile. Users may need to make additional modifications to the system configuration depending on individual application needs.

Important: Recommended profiles

SUSE recommends using either the CIS or the STIG profile. You can use other profiles at your own discretion.

2.5.3 Hardening instances with OpenSCAP

To evaluate an instance, you can run:

> sudo oscap xccdf eval \
 --profile stig1 \
 --results /tmp/results.xml2 \
 --report /tmp/report.html3 \
 --stig-viewer /tmp/stigviewer.xml4 \


Specifies the profile to use, e.g. stig or cis.


Saves the results of the evaluation to /tmp/results.xml


Generates a HTML report called /tmp/report.html in addition to the results in XML.


Saves the results to /tmp/stigviewer.xml, which can be imported into the DISA STIG Viewer. Refer to https://pub-lic.cyber.mil/stigs/srg-stig-tools/ for information about DISA STIG Viewer.


Scap Security Guide (SSG) policy file in the datastream (ds) format. Make sure to select the correct version for your instance. To list all available policies, run: ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml.For more information about a particular policy, run oscap info on the file.

The evaluation process usually takes a few minutes, depending on the number of selected rules.

To remediate an instance, add the --remediate parameter:

> sudo oscap xccdf eval --remediate\
 --profile stig \
 --results /tmp/results.xml \
 --report /tmp/report.html \
 --stig-viewer /tmp/stigviewer.xml \

2.5.4 More information

For more information on how to harden your SUSE Linux Enterprise system with OpenSCAP, refer to the article Hardening SUSE Linux Enterprise with OpenSCAP. For general information on OpenSCAP, refer to the SCAP Security Guide.