This guide provides an overview of how SAP NetWeaver works on Google Cloud Platform (GCP), and provides details that you can use when planning the migration of your existing SAP NetWeaver system, or when implementing a new system. GCP is certified for running SAP NetWeaver application servers ABAP and Java, and SAP products based on these application server stacks.
This guide does not cover the specifics of deploying the SAP NetWeaver system. To learn how to plan for your deployment of SAP NetWeaver, see the SAP NetWeaver Master Guide.
GCP consists of many cloud-based services and products. When running SAP products on GCP, you mainly use the IaaS-based services offered through Compute Engine and Cloud Storage, as well as some platform-wide features, such as tools.
See the GCP platform overview for important concepts and terminology. This guide duplicates some information from the overview for convenience and context.
For an overview of considerations that enterprise-scale organizations should take into account when running on GCP, see best practices for enterprise organizations.
Interacting with GCP
GCP offers three main ways to interact with the platform, and your resources, in the cloud:
- The Google Cloud Platform Console, which is a web-based user interface.
gcloudcommand-line tool, which provides a superset of the functionality that GCP Console offers.
- Client libraries, which provide APIs for accessing services and management of resources. Client libraries are useful when building your own tools.
Pricing and quotas
GCP resources are subject to quotas. If you plan to use high-CPU or high-memory machines, you might need to request additional quota. For more information, see Compute Engine resource quotas.
Overview of SAP NetWeaver on GCP
In many ways, running SAP NetWeaver on GCP is similar to running it in your own data center. You still need to think about computing resources, storage, and networking considerations. You also still need to think through how to handle backups and disaster recovery for your database.
Here are some of the differences that you should understand:
- You interact with the various infrastructure components through services, which are abstractions of the hardware you normally use. For example, computers are always virtual machines (VMs), and components such as networks, firewalls, and mass storage are managed as abstractions.
- GCP services offer particular features and introduce certain limitations.
- GCP services work together in particular ways.
- SAP NetWeaver and the GCP services work together in particular ways.
The following diagram provides a high-level overview of SAP NetWeaver running on GCP:
Here are some important things to notice in the diagram:
- The system uses some number of VMs and persistent disk drives. These components host the software, including the main database system.
- The SAP NetWeaver system consists of its usual application components plus a Host Agent component.
- The SAP Host Agent/SAPOSCOL component collects monitoring metadata from a monitoring agent component provided by Google. Google's monitoring agent aggregates metrics from Stackdriver Monitoring, which is GCP's monitoring solution.
- All communication between GCP components and external components pass through a networking layer. This layer provides security features, including firewalls, routes and internet gateways, VPN, and so on.
The following diagram shows some details of a 2-tier architecture running on Compute Engine.
In this architecture, all the components run on a single VM. The VM has 5 attached disk drives, and each drive serves a specific role. These roles include:
- Root disk: Contains the operating system for the VM.
- Swap disk: Contains the operating system's paging file.
- SAP NetWeaver: Contains the NetWeaver installation and the profile files.
- Data volume: Contains the database files.
- Logs volume: Contains the database-system logs used for maintaining data consistency, backup, and recovery operations.
The required disk drives for the database server might be different than those shown in the preceding figure depending on which database server you are using.
For example, for a SAP HANA deployment:
- The disk marked "Data volume" contains the data files.
- The disk marked "Logs" contains the HANA log files.
- The HANA binaries and shared files can be hosted on the disk labeled "NetWeaver".
- You need an additional volume for storing database backups.
See the HANA Planning Guide for more information about the deployment architecture for SAP HANA on GCP.
For a list of the disk drives required for SAP ASE, see the SAP ASE Planning Guide.
For a list of the disk drives required for SAP MaxDB, see the SAP MaxDB Planning Guide.
For a deployment of IBM Db2 for Linux, UNIX and Windows (IBM Db2), more disk drives are required than those shown in the preceding figure. For a list of the required disk drives, see the IBM Db2 for SAP Planning Guide.
For information about Microsoft SQL Server on GCP, see Windows on Compute Engine .
In upcoming sections, you learn about details and recommendations for these components.
The following diagram shows some details of a 3-tier architecture running on Compute Engine.
In this architecture, the SAP NetWeaver system distributes work across multiple NetWeaver Application Servers (AS) hosted on multiple VMs. All the NetWeaver AS nodes share the same database, which is hosted on a separate VM. All the NetWeaver AS nodes mount and access a shared file system that hosts the SAP NetWeaver profiles. This shared file system is contained on a persistent disk that is attached to VM 1, along with the SAP central services.
GCP provides computing resources as VMs, also called VM instances, through Compute Engine. When you run SAP NetWeaver on GCP, you use Compute Engine VMs to:
- Run operating systems.
- Host SAP central services.
- Host SAP AS.
- Host database servers.
As you plan your SAP implementation, consider the following:
- The number of VMs your implementation architecture requires. This number can range from one VM for a development, training, or small production system, to many VMs for a scale-out production system.
- Particular machine types, which determine processing power—CPU types, number of cores, and so on—and available volatile memory.
- Image types, which determine the operating system, and the database type if you choose to use SQL Server.
- The location of the VMs. Compute Engine resources run in Google's data centers worldwide, and these data centers are organized by region and zone. You learn more in Planning regions and zones.
The following sections provide further details.
You can use any of the following standard and high-memory machine types. Standard machine types provide 3.75 GB of RAM per vCPU, and high-memory machine types provide 6.50 GB of RAM per virtual CPU.
The database can impact the network, which can in turn affect latency. The bandwidth of the network is based on the number of virtual CPUs, so if you expect high network traffic, you should choose a machine type with at least 8 virtual CPUs. For more information on GCP machine types and performance of SAP, see SAP Note 2456432: SAP Applications on Google Cloud Platform: Supported Products and Google VM types.
|Machine Name||Virtual CPUs||Memory (GB)||Max number of persistent disks (PDs)||Max total PD size (TB)|
||8||30||16 (64 in beta)||64|
||16||60||16 (64 in beta)||64|
||32||120||16 (64 in beta)||64|
||64||240||16 (64 in beta)||64|
||2||13||16 (64 in beta)||64|
||4||26||16 (64 in beta)||64|
||8||52||16 (128 in beta)||64|
||16||104||16 (128 in beta)||64|
||32||208||16 (128 in beta)||64|
||64||416||16 (128 in beta)||64|
|Custom machine typesNote||1 or any even number up to 96||3.75 GB per vCPU for standard memory usage or 6.5 GB per vCPU for high memory usage.||16 (128 in Beta)||64|
When you create a Compute Engine VM, you use an image that contains the base components you require. For example, an image can contain a Microsoft Windows Server operating system with a SQL Server installation. There are several ways you can specify an image for your VMs. You can:
- Use the Cloud Deployment Manager script, provided by Google, that is designed to make setting up SAP NetWeaver easier. For details about how to use the Cloud Deployment Manager script, see the SAP NetWeaver on GCP Deployment Guide for your operating system.
- Use a public image. Google provides a variety of public images. You must choose an image that contains components that are supported for SAP NetWeaver.
- Create your own custom image. You might want to set up your own base system from scratch and create a custom image that you can reuse. You can also create an image by importing an existing boot disk to Compute Engine.
Deployment Manager templates
Cloud Deployment Manager provides a way to declare a set of GCP resources and then deploy those resources in a consistent, repeatable fashion. For SAP NetWeaver, Google provides Deployment Manager templates that makes it easier for you to set up a SAP-certified SAP NetWeaver architecture on GCP.
The provided templates instantiate the following resources:
- VM type of your choice.
- Windows Server 2012 R2, SUSE Linux Enterprise Server (SLES) 12.1 premium OS, or Red Hat Enterprise Linux (RHEL) 7.
- Persistent disks for SAP NetWeaver.
- For Linux, the template instantiates the XFS file system.
Supported public images
You can use public images from the following image families.
Red Hat Linux
These image families contain supported RHEL images:
These image families contain supported SLES images:
These image families contain supported Windows Server images:
SQL Server Enterprise
These image families contain supported Windows Server with SQL Server Enterprise images:
For more information about the support status of an operating system version, see Operating system support for SAP NetWeaver on GCP: track-type="userGuide" track-name="internalLink" track-metadata-position="body" }.
Planning for image management
After your system is up and running, you can create custom images. Create custom images when you modify the state of your root persistent disk so you can easily restore the new state if needed. Plan for the management of the custom images you create. For more information, see Image Management Best Practices.
Planning regions and zones
When you deploy a VM, you must choose a region and zone. A region is a specific geographical location where you can run your resources, and corresponds to a data center location. Each region has one or more zones.
Global resources, such as preconfigured disk images and disk snapshots, can be accessed across regions and zones. Regional resources, such as static external IP addresses, can only be accessed by resources that are in the same region. Zonal resources, such as VMs and disks, can only be accessed by resources that are located in the same zone.
When you are choosing a region and zone for your VMs, consider:
- The location of your users and your internal resources, such as your data center or corporate network. To decrease latency, select a location that is in close proximity to your users and resources.
The CPU platforms that are available for that region and zone. SAP NetWeaver on GCP is supported for Intel's Broadwell, Haswell, and Skylake processors, for production workloads.
- For more information, see SAP Note 2456432: SAP Applications on Google Cloud Platform: Supported Products and Google VM types.
- For details about which regions the Haswell, Broadwell, and Skylake processors are available for use with Compute Engine, see Regions and Zones.
That your SAP AS and your database must be in the same region.
You can use the standard GCP methods to deploy your VMs on Compute Engine: the
GCP Console web UI, the
gcloud command-line tool,
Deployment Manager, and the REST API.
The following pages provide generally useful information about how to deploy
For detailed information and instructions about deploying your SAP NetWeaver system on Compute engine, see the NetWeaver Deployment Guide for your operating system:
The creator of a VM has full root-privileges.
- On a Linux-based VM, the creator has SSH capability and can use the GCP Console to grant SSH capability to other users.
- On a Windows-based VM, the creator can use the GCP Console to generate a username and password; after that, anyone who knows the username and password can connect to the VM using RDP.
After a user with administrative privileges has connected to an instance through SSH or RDP, they can add other system users with standard Linux commands or Windows user-account management. The following pages provide generally useful information about connecting to Compute Engine VMs:
If you use Linux instances, you need to plan for how you will use SSH keys. In general, Compute Engine manages SSH keys for you. You can decide to manage your own SSH keys, but you need to understand the associated risks. For details, see SSH Keys.
For details and instructions about how to connect to Compute Engine VMs in your SAP NetWeaver deployment, see the SAP NetWeaver Deployment Guide for your operating system:
You can use the following database management systems with SAP NetWeaver on GCP:
- SAP HANA on Linux
- SAP ASE on Linux or Windows
- SAP MaxDB on Linux or Windows
- IBM Db2 on Linux or Windows
- Microsoft SQL Server Enterprise on Windows
SAP HANA is certified to run in GCP on the following Linux operating systems:
- Red Hat Enterprise Linux (RHEL) for SAP HANA 7.3 and 7.4
- SUSE Linux Enterprise Server (SLES) 12 SP1 and SP2
- SUSE Linux Enterprise Server (SLES) for SAP 12 SP1 and SP2
For more information on supported VM types and operating systems, see the SAP HANA planning guide.
To determine the sizing guidelines and recommendations for SAP HANA, see the SAP sizing calculator.
SAP ASE on GCP is supported on the following operating systems:
For more information on supported VM types and operating systems, see the SAP ASE planning guide.
To deploy SAP ASE on GCP, see the ASE Deployment Guide for your operating system:
For more information about SAP ASE, see the SAP documentation.
SAP MaxDB on Google Cloud Platform is supported on the following operating systems:
For more information on supported VM types and operating systems, see the SAP MaxDB planning guide. To deploy SAP MaxDB on GCP, see the SAP MaxDB deployment guide for your operating system:
For more information about SAP MaxDB, see the SAP MaxDB Library.
IBM Db2 for Linux, UNIX and Windows
IBM Db2 is supported for SLES 12 SP2, RHEL 7.4, and Windows Server 2012 R2 and later. For more information on supported VM types and operating systems, see the IBM Db2 for SAP Planning Guide. To deploy IBM Db2 on GCP, see the IBM Db2 for SAP Deployment Guide.
For more information about IBM Db2, see SAP on IBM Db2 for Linux, UNIX and Windows.
Microsoft SQL Server
You can install SQL Server in several ways:
- You can use a public image provided by Google with SQL Server Enterprise. The SQL Server in Windows Server image is a premium image, which means that the image cost is bundled with the machine type cost.
- You can download the SQL Server DVD from SAP, and use the SAP-specific script
SQL4SAP.batthat installs SQL Server with the correct settings.
- You can download the SQL Server DVD either from SAP or Microsoft and use the
setup.exeto install SQL Server so that you can customize your setup.
If you use SQL Server as your database, you must ensure that SQL Server is
configured to use the SAP
SQL_Latin1_General_CP850_BIN2, for compatibility with SAP systems.
You can confirm the collation of your SQL Server in your server properties:
If you have already configured your SQL Server, you can update the collation, but you will need to recreate the databases afterwards. For more details on how to specify or change the collation, see the SAP NetWeaver on Windows Deployment Guide.
Database backup and recovery
You must have a plan for how to restore your system to operating condition if the worst happens. For general guidance about how to plan for disaster recovery using GCP, see:
For information about SAP HANA backup and recovery, see the SAP HANA on GCP Operations Guide.
For information about SAP ASE backup and recovery, see SAP ASE Performance and Tuning Series: Physical Database Tuning.
For information about SAP MaxDB backup and recovery, see SAP MaxDB Database Administration.
For information about IBM Db2 backup and recovery, see Backup and Recovery.
For information about creating an SQL Server backup and recovery plan, see Building a Microsoft SQL Server Disaster Recovery Plan on Compute Engine.
By default, each Compute Engine VM has a small root persistent disk that contains the operating system. You can add additional disks to your VMs to act as storage for the different components of your system.
Persistent disks are durable storage devices that function similarly to the physical disks in a desktop or a server. Google manages the hardware behind these devices to ensure data redundancy and to optimize performance. Persistent disks are available as either standard hard disk drives (HDD) or solid-state drives (SSD). Standard HDD persistent disks are efficient and economical for handling sequential read-write operations, but are not optimized to handle high rates of random input-output operations per second (IOPS).
Persistent disks are located independently from your VMs, so you can detach or move persistent disks to keep your data, even after you delete your VMs. Persistent disk performance scales automatically with size, so you can resize your existing persistent disks or add more persistent disks to a VM to meet your performance and storage space requirements.
Add a persistent disk to your instance when you need reliable and affordable storage with consistent performance characteristics.
If you use an SSD with at least 1.7 terabytes for your database data, you can attain the following maximum sustained throughput:
|Virtual CPUs||Reads (MB/s)||Writes (MB/s)|
|32 (see note)||800||400|
Local SSD (non-persistent)
GCP offers local SSD disk drives. Although local SSDs can offer some advantages over persistent disks, don't use them as part of an SAP NetWeaver system. VM instances with local SSDs attached cannot be stopped and then restarted.
Using Cloud Storage for object storage
Cloud Storage is an object store for files of any type or format; it has virtually unlimited storage, and you do not have to worry about provisioning it or adding more capacity. An object in Cloud Storage contains file data and its associated metadata, and can be up to 5 terabytes in size. A Cloud Storage bucket can store any number of objects.
It's common practice to use Cloud Storage to store backup files for nearly any purpose. For example, for SAP HANA backups, Cloud Storage is a good place to store the files. For database backup planning, refer to the resources in Database backup and recovery. You can also use Cloud Storage as part of a migration process.
Choose your Cloud Storage option based on how frequently you need to access the data. For frequent access multiple times a month, select Multi-Regional or Regional storage classes. For infrequent access, select Nearline or Coldline storage.
When you plan your storage options, start with the frequently accessed tier and age your backup data to the infrequent access tiers, because backups are rarely used as they become older. The probability of needing a backup that is 3 years old is extremely low, and you can age this backup into the Coldline tier to optimize costs.
Networking and security
Consider the information in the following sections when planning networking and security.
Minimum privilege model
One of your first lines of defense is to restrict who can reach your network and
your VMs by using
By default, all traffic to VMs, even from other VMs, is blocked by the firewall
unless you create rules to allow access. The exception is the
that is created automatically with each project and has default
By creating firewall rules, you can restrict all traffic on a given set of ports to specific source IP addresses. Follow the minimum privilege model in order to restrict access to the specific IP addresses, protocols, and ports that need access. For example, always set up a bastion host and allow SSH into your SAP NetWeaver system only from that host.
Understanding how access management works on GCP is key to planning your implementation. You need to make decisions about:
- How to organize your resources on GCP.
- Which team members can access and work with resources.
- Exactly which permissions each team member can have.
- Which services and applications need to use which service accounts, and what level of permissions to grant in each case.
Start by understanding the Cloud Platform Resource Hierarchy. It's important that you understand what the various resource containers are, how they relate to each other, and where the access boundaries are created.
Cloud Identity and Access Management (Cloud IAM) provides unified control over permissions for GCP resources. You can manage access control by defining who has what access to resources. For example, you can control who can perform control-plane operations on your SAP instances, such as creating and modifying VMs, persistent disks, and networking.
For more details about Cloud IAM, see the Overview of Cloud IAM.
For an overview of Cloud IAM in Compute Engine, see Access Control Options.
Cloud IAM roles are key to granting permissions to users. For a reference about roles and which permissions they provide, see Identity and Access Management Roles.
GCP's service accounts provide a way for you to give permissions to applications and services. It's important to understand how service accounts work in Compute Engine. For details, see Service Accounts.
Custom networks and firewall rules
You can use a network to define a gateway IP and the network range for the VMs attached to that network. All Compute Engine networks use the IPv4 protocol. Every GCP project is provided with a default network with preset configurations and firewall rules, but you should add a custom subnetwork and add firewall rules based on a minimum privilege model. By default, a newly created network has no firewall rules and hence no network access.
You might want to add more than one subnetwork, if you want to isolate parts of your network, and depending on your requirements. For more information, see Subnetworks.
The firewall rules apply to the entire network and all the VMs in the network. You can add a firewall rule that allows traffic between VMs in the same network and across subnetworks. You can also configure firewalls to apply to specific target VMs by using the tagging mechanism.
SAP requires access to certain ports, so add firewall rules to allow access to the ports outlined by SAP.
Routes are global resources attached to a single network. User-created routes apply to all VMs in a network. This means you can add a route that forwards traffic from VM to VM within the same network and across subnetworks without requiring external IP addresses.
For external access to internet resources, launch a VM with no external IP address and configure another virtual machine as a NAT gateway. This configuration requires you to add your NAT gateway as a route for your SAP instance.
Using bastion hosts and NAT gateways
If your security policy requires truly internal VMs, you need to set up a NAT proxy manually on your network and a corresponding route so that VMs can reach the internet. It is important to note that you cannot connect to a fully internal VM instance directly by using SSH. To connect to such internal machines, you must set up a bastion instance that has an external IP address and then tunnel through it. When VMs do not have external IP addresses, they can only be reached by other VMs on the network, or through a managed VPN gateway. You can provision VMs in your network to act as trusted relays for inbound connections, called bastion hosts, or network egress, called NAT gateways. For more transparent connectivity without setting up such connections, you can use a managed VPN gateway resource.
Using bastion hosts for inbound connections
Bastion hosts provide an external facing point of entry into a network containing private-network VMs. This host can provide a single point of fortification or audit and can be started and stopped to enable or disable inbound SSH communication from the internet.
SSH access to VMs that do not have an external IP address can be achieved by first connecting to a bastion host. A complete hardening of a bastion host is outside the scope of this article, but some initial steps taken can include:
- Limit the CIDR range of source IPs that can communicate with the bastion.
- Configure firewall rules to allow SSH traffic to private VMs from only the bastion host.
By default, SSH on VMs is configured to use private keys for authentication. When using a bastion host, you log into the bastion host first, and then into your target private VM. Due to this two-step login, you should use SSH-agent forwarding to reach the target VM instead of storing the target VM's private key on the bastion host. You must do this even if you are using the same key-pair for both bastion and target VMs, as the bastion has direct access only to the public half of the key-pair.
Using NAT gateways for traffic egress
When a VM does not have an assigned, external IP address, it cannot make direct connections to external services, including other GCP services. To allow these VMs to reach services on the internet, you can set up and configure a NAT gateway. The NAT gateway is a VM that can route traffic on behalf of any other VM on the network. Use one NAT gateway per network. A single-VM NAT gateway is not highly available and cannot support high traffic throughput for multiple VMs. For instructions on how to set up a VM to act as a NAT gateway, see the NetWeaver Deployment Guide for your operating system:
You can securely connect your existing network to GCP through a VPN connection that uses IPsec by using Cloud VPN. Traffic traveling between the two networks is encrypted by one VPN gateway, then decrypted by the other VPN gateway. This protects your data as it travels over the internet. You can dynamically control which VMs can send traffic down the VPN using instance tags on routes. Cloud VPN tunnels are billed at a static monthly rate plus standard egress charges. Note that connecting two networks in the same project still incurs standard egress charges. For more information, see:
Securing a Cloud Storage bucket
If you use Cloud Storage to host your backups for your data and log, make sure you use TLS (HTTPS) while sending data to Cloud Storage from your VMs to protect data in transit. Cloud Storage automatically encrypts data at rest. You can specify your own encryption keys if you have your own key-management system.
For security best practices, see Cloud Storage Security.
To help protect your systems and Google's from abuse, GCP enforces limitations for sending email from Compute Engine. For more information, see Sending email from an instance.
Related security documents
Refer to the following additional security resources for your SAP environment on GCP:
- Securely Connecting to VM Instances
- Security Center
- Compliance in the Google Cloud
- Google Cloud security whitepaper
- Google Infrastructure security design
Monitoring SAP NetWeaver on GCP
To help you perform tasks such as analyzing system performance and detecting and diagnosing problems early, SAP NetWeaver provides a central monitoring system that collects data about the components and activities system-wide. GCP provides its own monitoring system, Stackdriver Monitoring, to collect metrics, events, and metadata. As you implement and operate SAP NetWeaver on GCP, dealing with two disconnected systems and trying to figure out where the real issues exist can become challenging for support personnel. To make things easier, Google and SAP have worked together to create a monitoring agent for SAP NetWeaver running on GCP.
Google's monitoring agent provides data to the SAP monitoring system. The monitoring agent provides metrics about:
- CPU, for example, CPU utilization.
- Storage, for example, disk throughput and latency.
- Memory, for example, memory consumption.
- Networks, for example, network bandwidth.
- Configuration, for example, VM information.
Google's monitoring agent is available for installation alongside SAP NetWeaver on GCP. For details and instructions about how to install Google's monitoring agent, see the NetWeaver Deployment Guide for your operating system:
For details about the monitoring lifecycle and operations, see the SAP NetWeaver on GCP Operations Guide.
Scale-out of SAP NetWeaver application servers
SAP supports a scale-out architecture that uses multiple application servers, which supports a higher workload.
If you are using Windows Server as your operating system, you can use Active Directory running on a VM as a domain controller. For more information, see Setting up Active Directory on Google Compute Engine. Alternatively, you can connect Compute Engine VMs to your on-premises Active Directory domain controller using VPN.
In scale-out configuration, nodes must access a shared file system. For Windows
Server, specify where the shared file system is mounted during installation
through the SAP installer. For Linux, use the Network File System (NFS) as your
fileshare on the NetWeaver binaries/profiles disk of the central system
[SID] is the system ID). See
the SAP documentation
Migrating an existing SAP NetWeaver system
By migrating an existing SAP NetWeaver landscape, you can leverage your investment in your existing setup in the cloud. Migrating a system of any significant scale requires careful planning and step-by-step migration, to avoid losing consistency between the system components.
For migrations, follow SAP standard migration practices. SAP recommends following their best practices for copying components from your source system to a newly created target system. When the source and target systems use the same OS and database system, use homogeneous system copy, and when the source and target systems use a different OS or database system, use heterogeneous system copy.
This section provides information about licensing requirements.
Running SAP on GCP requires you to bring your own license (BYOL).
See the following SAP Notes:
- 2446441 - Linux on Google Cloud Platform (IaaS): Adaption of your SAP License
- 2456953 - Windows on Google Cloud Platform (IaaS): Adaption of your SAP License
For more information from SAP about managing your SAP NetWeaver licenses, see SAP Licensing Procedure.
Microsoft Windows Server and SQL Server
In Compute Engine, there are two ways to license Microsoft software:
With pay-as-you-go licensing, your Compute Engine VM hourly cost includes licensing. Google manages the licensing logistics with Microsoft. Your hourly costs are higher, but you have complete flexibility to increase and decrease your costs, as needed. This is the licensing model used for GCP public images that include Windows Server, with or without SQL Server.
With BYOL, your Compute Engine VM costs are lower because the licensing isn't included. You must migrate an existing license or purchase your own license, which means paying up front, and you have less flexibility. However, with very stable usage needs, or with no-charge or discounted licensing through Microsoft licensing agreements, this approach might be less expensive.
Microsoft's terms for migrating licenses are different for Windows Server and SQL Server. For full details about BYOL on GCP, see Using Existing Microsoft Application Licenses.
For information about SAP license restrictions for SQL Server, see SAP Note 2139358.
In Compute Engine, there are two ways to license SLES or RHEL:
With pay-as-you-go licensing, your Compute Engine VM hourly cost includes licensing. Google manages the licensing logistics. Your hourly costs are higher, but you have complete flexibility to increase and decrease your costs, as needed. This is the licensing model used for GCP public images that include SLES or RHEL.
With BYOL, your Compute Engine VM costs are lower because the licensing isn't included. You must migrate an existing license or purchase your own license, which means paying up front, and you have less flexibility.
Google Cloud Platform customers either with a Production Support Role or with Enterprise Support can request assistance with the provisioning and configuration of the GCP resources that are required for SAP systems. GCP Production-level support or Enterprise support is required for support of SAP systems in production environments.
For more information about GCP support options, see Google Cloud Platform Support.
For SAP product-related issues, log your support request with SAP support. SAP evaluates the support ticket and, if it appears to be a GCP infrastructure issue, transfers the ticket to the GCP queue.