SAP NetWeaver Planning Guide

This guide provides an overview of how SAP NetWeaver works on Google Cloud, and provides details that you can use when planning the migration of your existing SAP NetWeaver system, or when implementing a new system. Google Cloud 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.

Google Cloud basics

Google Cloud consists of many cloud-based services and products. When running SAP products on Google Cloud, 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 Google Cloud 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 Google Cloud, see best practices for enterprise organizations.

Interacting with Google Cloud

Google Cloud offers three main ways to interact with the platform, and your resources, in the cloud:

  • The Google Cloud Console, which is a web-based user interface.
  • The gcloud command-line tool, which provides a superset of the functionality that Cloud 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

You can use the pricing calculator to estimate your usage costs. For more pricing information, see Compute Engine pricing, Cloud Storage pricing, and Google Cloud's operations suite pricing.

Google Cloud 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 Google Cloud

In many ways, running SAP NetWeaver on Google Cloud 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 or virtualizations of the hardware that you would use on premises. For example, some of the virtualized infrastructure services that you use instead of hardware on Google Cloud include Compute Engine virtual machines (VMs) and persistent disks, Virtual Private Cloud networks and firewalls, and Cloud Storage buckets for mass storage.
  • Google Cloud services offer particular features and introduce certain limitations.
  • Google Cloud services work together in particular ways.
  • SAP NetWeaver and the Google Cloud services work together in particular ways.

The following diagram provides a high-level overview of SAP NetWeaver running on Google Cloud:

Overview of SAP NetWeaver on Google Cloud

Here are some important things to notice in the diagram:

  • The system uses some number of Compute Engine VMs and persistent disks. 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 the Google Cloud monitoring agent for SAP NetWeaver, a monitoring agent provided by Google Cloud. The Google Cloud monitoring agent for SAP NetWeaver aggregates metrics from Cloud Monitoring, the Google Cloud monitoring solution.
  • All communication between Google Cloud components and external components pass through a networking layer. This layer provides security features, including firewalls, routes and internet gateways, VPN, and so on.

Two-tier architecture

The following diagram shows some details of a 2-tier architecture running on a Compute Engine VM.

2-tier architecture

In this architecture, all the components run on a single VM. The VM has 5 attached persistent disks, and each persistent disk 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.

Depending on which database server you are using, the data volumes that you need might be different than those shown in the preceding figure.

Up to a limit, the performance of a Compute Engine persistent disk improves as the size of the disk and the number of vCPUs increases. For this reason, create a larger PD volume and logically partition the disk in the guest operating system for multiple file systems. For example, if you use SAP HANA, the recommended configuration is to map the /hana/data, /hana/log, and /hana/shared volumes to a single Compute Engine persistent disk. Using a larger single persistent disk also allows for easier resizing in the VM and simplifies management.

Depending on your application, attaching multiple persistent disk volumes to your VM can have operational benefits. For example, it can simplify the use of persistent disk snapshots for specific volumes.

Striping over multiple persistent disk volumes does not provide a significant performance benefit for SAP on Google Cloud.

For more information, see:

The database server is also likely to require higher performance persistent disks than SAP NetWeaver requires.

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.

For information about SAP HANA on Google Cloud, see:

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 Google Cloud, see Windows on Compute Engine.

In upcoming sections, you learn about details and recommendations for these components.

Three-tier architecture

The following diagram shows some details of a 3-tier architecture running on Compute Engine.

3-tier architecture

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.

Certified machines

Google Cloud provides most computing resources as VMs, also called VM instances, through Compute Engine. Google Cloud provides bare-metal machines through Bare Metal Solution.

All machine types can:

  • 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 machines that 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.
  • Increasing the number of vCPUs in a VM instance increases the network bandwidth for outgoing communications (the egress rate) from the VM up to a limit that can differ depending on the machine type. See VPC resource quotas per instance.
  • 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 Cloud data centers worldwide, and these data centers are organized by region and zone. You learn more in Planning regions and zones.
  • The amount of persistent disk storage and the number of persistent disks. For most VM types, you can attach up to 64 TB of persistent disk storage. Although you can attach up to 128 persistent disks to most VM types, using fewer persistent disks reduces management overhead and can improve performance.

If you expect high network traffic, as is often the case in three-tier architectures that put the database on a separate VM, select a VM instance with enough vCPUs to provide the throughput you need.

For information on Google Cloud machine types and SAPS, see SAP Note 2456432.

The following sections provide further details.

Machine types

Google Cloud offers SAP-certified machines in the following machine-type families:

  • Compute-optimized machine types
  • Memory-optimized machine types
  • General-purpose machine types
  • Custom configurations of the N1-, N2-, or N2D- machine types
  • Bare Metal Solution machine types

For more information about each Compute Engine machine-type family that is certified for SAP applications, see Certified machine types.

The following machine certifications are for SAP NetWeaver. For machine certifications that are specific to SAP HANA, see Certified machine types for SAP HANA.

Before selecting a machine type for use, confirm that it is available in the region and zones that you need.

For more information about each Compute Engine machine type, including its regional and zonal availability, see Machine types.

For the availability of Bare Metal Solution machine types, see Regional availability of SAP-certified Bare Metal Solution machines.

Machine Name Virtual CPUs Memory (GB) Minimum CPU platform SAPS
C2 compute-optimized VM types


4 16 Intel Cascade Lake 6,040


8 32 Intel Cascade Lake 12,080


16 64 Intel Cascade Lake 24,160


30 120 Intel Cascade Lake 45,300


60 240 Intel Cascade Lake 90,600
Custom VMs
N1-based custom VMNote 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. Intel Broadwell
N2-based custom VMNote Any even number up to 32. After 32, the number of vCPUs must be divisible by 4, up to 80 vCPUs. For example, 32, 36, and 40 vCPUs are all valid, but 38 is invalid. 4.0 GB or more per vCPU for standard memory usage or 8.0 GB or more per vCPU for high memory usage. Intel Cascade Lake
N2D-based custom VMNote 2 or any even number of vCPUs that is divisible by 4, up to an SAP-support limit of 32 vCPUs. 4.0 GB per vCPU for standard memory usage or 8.0 GB per vCPU for high memory usage. AMD EPYC Rome
M1 memory-optimized VM types
m1-megamem-96 96 1433 Intel Skylake 105,050


40 961 Intel Broadwell 34,475


80 1922 Intel Broadwell 68,950


160 3,844 Intel Broadwell 137,900
M2 memory-optimized VM types


208 5,888 Intel Cascade Lake 223,325


416 11,776 Intel Cascade Lake 446,650


416 5,888 Intel Cascade Lake 446,650
N1 high-memory, general-purpose VM types


2 13 Intel Broadwell 2,090


4 26 Intel Broadwell 4,180


8 52 Intel Broadwell 8,360


16 104 Intel Broadwell 16,720


32 208 Intel Broadwell 33,440


64 416 Intel Broadwell 66,880


96 624 Intel Skylake 100,320
N1 general-purpose VM types


8 30 Intel Broadwell 8,360


16 60 Intel Broadwell 16,720


32 120 Intel Broadwell 33,440


64 240 Intel Broadwell 66,880


96 360 Intel Skylake 100,320
N2 high-memory, general-purpose VM types


2 16 Intel Cascade Lake 2,688


4 32 Intel Cascade Lake 5,376


8 64 Intel Cascade Lake 10,752


16 128 Intel Cascade Lake 21,504


32 256 Intel Cascade Lake 43,008


48 384 Intel Cascade Lake 64,512


64 512 Intel Cascade Lake 86,016


80 640 Intel Cascade Lake 107,520
N2 general-purpose VM types


2 8 Intel Cascade Lake 2,632


4 16 Intel Cascade Lake 5,263


8 32 Intel Cascade Lake 10,525


16 64 Intel Cascade Lake 21,050


32 128 Intel Cascade Lake 42,100


48 192 Intel Cascade Lake 63,150


64 256 Intel Cascade Lake 84,200


80 320 Intel Cascade Lake 105,250
N2D high-memory, general-purpose VM types


2 16 AMD EPYC Rome 3,111


4 32 AMD EPYC Rome 6,223


8 64 AMD EPYC Rome 12,445


16 128 AMD EPYC Rome 24,890


32 256 AMD EPYC Rome 49,780
n2d-highmem-48 48 384 AMD EPYC Rome 74,438
n2d-highmem-64 64 512 AMD EPYC Rome 99,250
n2d-highmem-80 80 640 AMD EPYC Rome 115,025
n2d-highmem-96 96 768 AMD EPYC Rome 138,030
N2D general-purpose VM types


2 8 AMD EPYC Rome 3,102


4 16 AMD EPYC Rome 6,203


8 32 AMD EPYC Rome 12,406


16 64 AMD EPYC Rome 24,813


32 128 AMD EPYC Rome 49,625
n2d-standard-48 48 192 AMD EPYC Rome 74,438
n2d-standard-64 64 256 AMD EPYC Rome 99,250
n2d-standard-80 80 320 AMD EPYC Rome 115,025
n2d-standard-96 96 384 AMD EPYC Rome 138,030
O2 Bare Metal Solution machine types
o2-standard-16-metal 16 192 GiB Intel Cascade Lake 28,320
o2-standard-32-metal 32 384 GiB Intel Xeon Gold 51,570
o2-standard-48-metal 48 768 GiB Intel Xeon Gold 74,970
o2-standard-112-metal 112 1,532 GiB Intel Xeon Platinum 133,620
o2-highmem-224-metal 224 3 TiB Intel Xeon Platinum 276,179

Regional availability of SAP-certified Bare Metal Solution machines

The Bare Metal Solution machines that are certified for SAP applications are available only in Bare Metal Solution region extensions, which are not available for every Google Cloud region. For the full list of regions that have a Bare Metal Solution region extension, see Bare Metal Solution regional availability.

For the availability of Bare Metal Solution machines that are certified for SAP HANA, see Regional availability of Bare Metal Solution machines for SAP HANA.


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.

When you order a Bare Metal Solution machine, you also specify the operating system that you need. The machine becomes available with the operating system already installed.

For VMs, there are several ways that you can specify an image. 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 Google Cloud 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.

Supported public images

Compute Engine provides public images for supported operating system versions in image families.

To see the available versions in each image family, see the operating system details:

For more information about the support status of the operating system versions that are certified for SAP, see OS support for SAP NetWeaver on Google Cloud.

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.

Google Cloud regions and zones

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 Google Cloud is supported for Intel's Broadwell, Haswell, and Skylake processors, for production workloads.

  • That your SAP AS and your database must be in the same region.

Deploying VMs

You can use the standard Google Cloud methods to deploy your VMs on Compute Engine: the Cloud 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 VMs:

For detailed information and instructions about deploying your SAP NetWeaver system on Compute engine, see the NetWeaver Deployment Guide for your operating system:

Deployment Manager templates

Cloud Deployment Manager provides a way to declare a set of Google Cloud resources and then deploy those resources in a consistent, repeatable fashion. For SAP NetWeaver, Google Cloud provides Deployment Manager templates that makes it easier for you to set up a SAP-certified SAP NetWeaver architecture on Google Cloud.

The provided templates instantiate the following resources for SAP NetWeaver:

  • VM type of your choice.
  • Your choice of the following operating systems:
    • Red Hat Enterprise Linux (RHEL)
    • SUSE Linux Enterprise Server (SLES)
    • Windows Server
  • Compute Engine standard persistent disks.
  • For Linux, the template instantiates the XFS file system.

Accessing VMs

The creator of a VM has full root-privileges.

  • On a Linux-based VM, the creator has SSH capability and can use the Cloud Console to grant SSH capability to other users.
  • On a Windows-based VM, the creator can use the Cloud 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 Google Cloud:

  • 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.
  • Oracle on Bare Metal Solution servers with operating systems that Bare Metal Solution for Oracle supports. For more information, see Operating systems.


SAP HANA is certified to run in Google Cloud on the following Linux operating systems:

For more information on supported VM types and operating systems, see the SAP HANA planning guide.

For more information about SAP HANA, see the SAP HANA operations guide and the SAP documentation.

To determine the sizing guidelines and recommendations for SAP HANA, see the SAP benchmark sizing page.


SAP ASE on Google Cloud 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 Google Cloud, see the ASE Deployment Guide for your operating system:

For more information about SAP ASE, see the SAP documentation.


SAP MaxDB on Google Cloud 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 Google Cloud, 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 on SLES, RHEL, and Windows Server.

For more information on supported VM types and operating systems, see the IBM Db2 for SAP Planning Guide. To deploy IBM Db2 on Google Cloud, 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.bat that installs SQL Server with the correct settings.
  • You can download the SQL Server DVD either from SAP or Microsoft and use the standard Microsoft setup.exe to 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 collation, SQL_Latin1_General_CP850_BIN2, for compatibility with SAP systems.

You can confirm the collation of your SQL Server in your server properties:

SQL Server dialog showing collation setting

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.


SAP on Oracle is supported only on Bare Metal Solution servers, which run in a regional extension that is co-located and connected to select Google Cloud regions.

For more information, see:

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 Google Cloud, see:

For information about SAP HANA backup and recovery, see the SAP HANA on Google Cloud 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 disk storage

For persistent block storage, you can attach Compute Engine persistent disks when you create your VMs or add them to your VMs later.

Compute Engine offers different types of persistent disks. Each type has different performance characteristics. Google Cloud manages the underlying hardware of persistent disks to ensure data redundancy and to optimize performance.

You can use any of the following Compute Engine persistent disk types with SAP NetWeaver:

  • Standard persistent disks (pd-standard), which are backed by standard hard-disk drives, 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).
  • Balanced persistent disks (pd-balanced), which are backed by solid-state drives (SSD). Balanced persistent disks offer a balance between cost and performance.
  • SSD persistent disks (pd-ssd), which offer the best performance.
Persistent disk performance scales automatically with size, so you can adjust performance by resizing your existing persistent disks or adding more persistent disks to a VM.

The type of VM you are using and the number of vCPUs it contains also affects persistent disk performance.

The following figure shows approximate performance numbers in an example SAP NetWeaver configuration on Google Cloud. The actual numbers you might see in a similar configuration are likely to differ for a variety of reasons, including improvements made by Compute Engine over time.

Two balanced persistent disks, one 80 GB and the other 250 GB, are attached
to an n2-standard-32 host VM that is running SAP NetWeaver

As indicated in the preceding figure, when both persistent disks are of the same type, the performance that they provide to the VM is cumulative, so you can estimate the overall performance by adding the performance numbers of each persistent disks.

For example, if you attach two balanced persistent disks as shown in the figure, one that provides 180 IOPS for read and write, and throughput of 8.4 MB per second and the other that provides 1,500 IOPS for reads and writes and 70 MB per second of throughput, together the persistent disks provide 1,680 IOPS for reads and writes and 78.4 MB per second of throughput. For more information, see both Multiple disks attached to a single VM instance and Simultaneous reads and writes under Other factors that affect performance.

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.

In the Cloud Console, you can see the persistent disks that are attached to your VM instances under Additional disks on the VM instance details page for each VM instance.

For more information about the different types of Compute Engine persistent disks, their performance characteristics, and how to work with them, see the Compute Engine documentation:

Persistent disks deployed by the Deployment Manager templates

If you deploy the host VM by using the Cloud Deployment Manager scripts that Google Cloud provides for SAP NetWeaver, Cloud Deployment Manager attaches two or three standard persistent disks for the required volumes or drives, depending on whether you are using Windows Server or Linux.

File sharing solutions

Several file sharing solutions are available on Google Cloud, including the following:

  • Filestore
  • NetApp Cloud Volumes ONTAP
  • NetApp Cloud Volumes Service for Google Cloud

To determine which solution is best for your deployment scenario, see File sharing solutions for SAP on Google Cloud.

Local SSD (non-persistent)

Google Cloud 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 the Standard storage class. For infrequent access, select Nearline or Coldline storage. For archival data you don't expect to access, select Archive 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 Archive tier to optimize costs.

For a more detailed comparison, see Storage Classes. To learn about the different storage options available, see Choosing a Storage Option.

User identification and resource access

When planning security for an SAP deployment on Google Cloud, you must identify:

  • The user accounts and applications that need access to the Google Cloud resources in your Google Cloud project
  • The specific Google Cloud resources in your project that each user needs to access

You must add each user to your project by adding their Google account ID to the project as a member. For an application program that uses Google Cloud resources, you create a service account, which provides a user identity for the program within your project.

Compute Engine VMs have their own service account. Any programs that that run on a VM can use the VM service account, as long as the VM service account has the resource permissions that the program needs.

After you identify the Google Cloud resources that each user needs to use, you grant each user permission to use each resource by assigning resource-specific roles to the user. Review the predefined roles that IAM provides for each resource, and assign roles to each user that provide just enough permissions to complete the user's tasks or functions and no more.

If you need more granular or restrictive control over permissions than the predefined IAM roles provide, you can create custom roles.

For more information about the IAM roles that SAP programs need on Google Cloud, see Identity and access management for SAP programs on Google Cloud.

For an overview of identity and access management for SAP on Google Cloud, see Identity and access management overview for SAP on Google Cloud.

Networking and network security

Consider the information in the following sections when planning networking and network security.

Minimum privilege model

One of your first lines of defense is to restrict who can reach your network and your VMs by using firewalls. 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 default network that is created automatically with each project and has default firewall rules.

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.

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 Google Cloud 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.

Bastion host show in SSH scenario

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 Google Cloud 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:

Cloud VPN

You can securely connect your existing network to Google Cloud 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.

Sending email

To help protect your systems and Google's from abuse, Google Cloud enforces limitations for sending email from Compute Engine. For more information, see Sending email from an instance.

Refer to the following additional security resources for your SAP environment on Google Cloud:

Monitoring SAP NetWeaver on Google Cloud

Google Cloud provides a monitoring agent specifically for SAP NetWeaver, the Google Cloud monitoring agent for SAP NetWeaver, which collects data about the Google Cloud host machine and its environment and provides the data to the SAP Host Agent.

The SAP Host Agent, with the saposcol program, and the monitoring agent for SAP NetWeaver are required for support and to monitor system performance of SAP NetWeaver on Google Cloud.

When the monitoring agent for SAP NetWeaver is running on a Compute Engine, the agent also collects metadata from Cloud Monitoring, a part of Google Cloud's operations suite.

The monitoring agent for SAP NetWeaver provides data to the SAP monitoring system, including 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, including information about the host machine and its environment.

For detailed information about the metrics that the monitoring agent for SAP NetWeaver collects, see SAP Note 2469354.

You install the monitoring agent for SAP NetWeaver on the host alongside SAP NetWeaver. For details and instructions about how to install the Google Cloud monitoring agent for SAP NetWeaver, see the NetWeaver Deployment Guide for your operating system:

For details about the monitoring lifecycle and operations, see the SAP NetWeaver on Google Cloud 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 (/sapmnt/[SID], where [SID] is the system ID). See the SAP documentation for details.

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.

SAP Licensing

Running SAP on Google Cloud requires you to bring your own license (BYOL).

See the following SAP Notes:

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 Google Cloud 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 Google Cloud, 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 Google Cloud 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.


For issues with Google Cloud infrastructure or services, contact Customer Care. You can find contact information on the Support Overview page in the Google Cloud Console. If Customer Care determines that a problem resides in your SAP systems, you are referred to SAP 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 Google Cloud infrastructure issue, transfers the ticket to the Google Cloud component BC-OP-LNX-GOOGLE or BC-OP-NT-GOOGLE.

Support requirements

Before you can receive support for SAP systems and the Google Cloud infrastructure and services that they use, you must meet the minimum support plan requirements.

For more information about the minimum support requirements for SAP on Google Cloud, see:

What's next