Azure Landing Zones for SAP

Azure Landing Zones for SAP: Architecting the Foundation

Introduction: Why Landing Zones Matter for SAP

When organizations decide to move their SAP workloads to Microsoft Azure, the technical focus often shifts immediately to virtual machine sizes, storage throughput, and database migration strategies. While these components are undeniably critical, they represent only a portion of a successful deployment. Without a structured, secure, and scalable foundation, SAP environments on Azure can quickly become siloed, difficult to manage, and insecure. This is where the concept of the Azure Landing Zone (ALZ) becomes essential.

An Azure Landing Zone is essentially the environment—the pre-provisioned infrastructure—in which your SAP workloads will live. It encompasses the network architecture, identity management, governance policies, and security guardrails necessary to host enterprise-grade applications. Think of it as building a house: you wouldn't start by buying the furniture; you would start by laying the foundation, installing the plumbing, and setting up the electrical grid. For SAP, which is often the heart of a business, the Landing Zone ensures that your "house" is strong enough to support the weight of mission-critical ERP systems.

Ignoring this layer often leads to "technical debt" early in the migration process. You might find that your network subnets are too small, your firewall rules are too permissive, or your resource naming conventions are inconsistent. Retrofitting these elements into a production SAP environment is complex, risky, and expensive. By designing a dedicated SAP Landing Zone, you create a repeatable, compliant, and stable environment that allows your SAP Basis and infrastructure teams to focus on the application rather than constant troubleshooting of the underlying platform.

Core Components of an SAP Landing Zone

An SAP Landing Zone is not a single service but a collection of Azure resources configured to work in harmony. To build an effective foundation, you must address several pillars: identity, networking, management, and security.

1. Identity and Access Management (IAM)

Before any server is deployed, you must define who can access the environment and what they can do. For SAP, this is particularly sensitive because the data within the ERP system is usually the most confidential information in the company.

• Role-Based Access Control (RBAC): Use Azure RBAC to grant the minimum necessary permissions. For example, your SAP Basis team needs permissions to manage virtual machines and storage accounts, but they likely do not need permissions to modify the networking firewall or Azure Active Directory settings.
• Privileged Identity Management (PIM): Ensure that administrative access is time-bound and approved. No one should have permanent "Owner" or "Contributor" status on your SAP production subscriptions.

2. Network Topology

SAP systems are highly sensitive to network latency and throughput. A poorly designed network will result in slow transaction processing and user dissatisfaction.

• Hub-and-Spoke Model: Use a hub-and-spoke architecture. The "Hub" contains shared services like firewalls, VPN gateways, and ExpressRoute circuits. The "Spoke" is where your SAP production, quality, and development environments reside.
• Segmentation: Separate your SAP application servers from your database servers using Network Security Groups (NSGs) or Azure Firewall. You should restrict traffic so that only specific application server IPs can communicate with the database instance on the required ports (e.g., SQL Server 1433 or HANA 3xx13).

3. Governance and Policy

Azure Policy acts as the "enforcer" of your design. If you decide that all SAP resources must be deployed in a specific region, or that all disks must be encrypted, Azure Policy can automatically prevent the creation of resources that violate these rules.

Callout: The SAP Infrastructure vs. Application Distinction It is vital to distinguish between the SAP application layer and the Azure infrastructure layer. The infrastructure layer (the Landing Zone) is the plumbing. The SAP application layer (the ABAP stack, HANA database, Java engine) sits on top. A common mistake is to treat the SAP application configuration as part of the infrastructure. Keep your infrastructure-as-code (IaC) templates focused on the Azure resources, and use configuration management tools like Ansible or Chef for the SAP application layer.

Designing the Network for Performance

The network is the circulatory system of your SAP landscape. In an on-premises data center, you have physical control over the cabling and switches. In Azure, you must rely on software-defined networking (SDN) features to achieve the same level of performance.

Latency Sensitivity

SAP HANA, in particular, is extremely sensitive to latency. If the distance between the application server and the database server is too high, or if the network path is congested, the database will experience "wait times" that translate directly into slow user experiences. To mitigate this, always deploy your SAP application servers and database servers within the same Azure Proximity Placement Group (PPG).

A Proximity Placement Group is a logical grouping that ensures your virtual machines are physically located as close to each other as possible within an Azure data center. While this does not guarantee zero latency, it significantly reduces the variance in latency, which is often more important for SAP performance than the absolute minimum latency.

Network Security Groups (NSGs)

NSGs serve as your virtual firewalls. You should apply them at the subnet level. A typical SAP subnet architecture might look like this:

• App Subnet: Contains the SAP application servers (ASCS, PAS, AAS).
• DB Subnet: Contains the HANA or SQL Server database instances.
• Management Subnet: Contains jump boxes (bastion hosts) and monitoring agents.

Tip: Minimize NSG Complexity Instead of creating hundreds of individual rules, use Application Security Groups (ASGs). You can group your SAP application servers into an ASG called SAP-App-Servers. Then, you can write a single NSG rule that allows SAP-App-Servers to talk to the SAP-DB-Servers ASG on specific ports. This makes your rules much easier to read and maintain.

Infrastructure as Code (IaC) for SAP

Manual deployment of SAP infrastructure is a recipe for disaster. If you manually configure a server, you run the risk of "configuration drift," where one server is slightly different from its neighbor, leading to unpredictable behavior. Using IaC ensures that your environment is reproducible and consistent.

Terraform for SAP

Terraform is the industry standard for deploying Azure resources. By defining your infrastructure in code, you gain version control, peer review capabilities, and the ability to spin up new environments in minutes rather than days.

Here is a simplified example of how you might define a virtual network for an SAP landscape using Terraform:

resource "azurerm_virtual_network" "sap_vnet" {
  name                = "vnet-sap-prod-001"
  address_space       = ["10.0.0.0/16"]
  location            = "East US"
  resource_group_name = azurerm_resource_group.sap_rg.name
}

resource "azurerm_subnet" "app_subnet" {
  name                 = "snet-sap-app"
  resource_group_name  = azurerm_resource_group.sap_rg.name
  virtual_network_name = azurerm_virtual_network.sap_vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

Explanation of the code:

1. azurerm_virtual_network: This block defines the entire network container. The address_space should be carefully planned to avoid overlaps with your on-premises data center, especially if you have a VPN or ExpressRoute connection.
2. azurerm_subnet: This divides the network. By separating the App and DB subnets, you can apply different security policies to each, which is a fundamental security best practice for SAP.

Storage Architecture and Performance

SAP workloads are disk-intensive. Whether it's the database transaction logs or the application server's swap space, storage throughput is often the bottleneck. Azure offers several storage tiers, and choosing the right one is critical.

Managed Disks

For SAP HANA, you should almost exclusively use Azure Premium SSD or Ultra Disk. Standard HDD storage is unsuitable for production SAP databases because it cannot provide the necessary Input/Output Operations Per Second (IOPS) or throughput.

• Premium SSD: Good for most application servers and small-to-medium databases. It provides consistent performance.
• Ultra Disk: Essential for large, high-transaction HANA databases. It allows you to dynamically adjust performance (IOPS and throughput) without restarting the virtual machine.

Storage Best Practices

1. Write Acceleration: If you are using M-series virtual machines for your HANA database, enable Write Acceleration on the OS and data disks. This significantly reduces latency for write operations.
2. Striping: For very large database volumes, use LVM (Logical Volume Manager) in Linux to stripe multiple Azure disks together. This aggregates the performance of the individual disks, allowing you to exceed the throughput limits of a single disk.
3. Encrytion: Always use Azure Disk Encryption or Server-Side Encryption with Customer-Managed Keys (CMK) to ensure that your SAP data is protected at rest.

Warning: Storage Throughput Limits Every Azure virtual machine has a maximum throughput limit (measured in MB/s). Even if you attach a super-fast Ultra Disk, you are still capped by the virtual machine's own network throughput limit. Always check the "Max cached and uncached disk throughput" for your chosen VM size in the Azure documentation before finalizing your design.

Monitoring and Management

Once your SAP system is live, you need to know how it is behaving. Azure offers integrated tools that provide visibility into the health of your SAP environment.

Azure Monitor for SAP

Azure Monitor for SAP is a specialized service that provides health and performance metrics for your SAP systems. It collects data from both the operating system (Linux/Windows) and the SAP application layer (HANA, NetWeaver).

• Key Metrics to Monitor:
  • CPU Utilization: High CPU on application servers might indicate inefficient ABAP code or a high volume of background jobs.
  • Memory Usage: HANA is an in-memory database. If you run out of RAM, the system will start swapping to disk, which will effectively stop your business processes.
  • Disk Latency: If latency exceeds 5-10ms for database volumes, you need to investigate your disk configuration or storage tier.

Logging and Alerting

Configure your Landing Zone to send all logs to a Log Analytics Workspace. This includes firewall logs, NSG flow logs, and sign-in logs from Azure AD. Use Azure Monitor Alerts to notify your Basis team via email or SMS when critical thresholds are crossed. For example, create an alert that triggers if the HANA database memory usage exceeds 90% for more than five minutes.

Common Pitfalls and How to Avoid Them

Even with the best intentions, architectural mistakes are common. Here are the most frequent issues encountered when building SAP Landing Zones and how to prevent them.

1. The "Flat Network" Mistake

Many teams start by putting everything in one subnet because it is easier to manage. This is a significant security risk. If an application server is compromised, the attacker has a direct, unobstructed path to your database.

• Prevention: Always implement a multi-subnet architecture from day one. Even if you don't use complex firewall rules initially, having the subnets in place makes it easier to implement security later.

2. Ignoring Regional Availability

SAP systems are often global. If you deploy your Landing Zone in one region without considering the proximity to your users, you will face performance issues.

• Prevention: Use the Azure Speed Test to check latency between your primary office locations and potential Azure regions. If you have users in both Europe and Asia, consider a multi-region deployment for your application servers.

3. Underestimating Storage Throughput

Teams often look at the size of the disk (e.g., 1TB) but ignore the throughput (e.g., 200 MB/s). If your HANA database is writing logs at 300 MB/s, you will experience constant performance degradation.

• Prevention: Calculate your required throughput based on your SAP sizing report (the Sizing Tool provided by SAP). Choose your disk type based on the throughput requirement, not just the capacity requirement.

4. Lack of Automation

If you provision your first environment manually, you will find it nearly impossible to recreate that same environment for a Disaster Recovery (DR) site or a Test system.

• Prevention: Treat your Landing Zone as code. If it isn't in your Terraform or Bicep repository, it doesn't exist in production.

Comparison Table: Storage Options for SAP

Step-by-Step: Setting Up a Secure Subnet for SAP

To ensure your SAP environment is secure, follow these steps to set up a hardened subnet environment:

1. Create the Virtual Network (VNet): Define your address space (e.g., 10.10.0.0/16).
2. Define Subnets: Create distinct subnets for App, DB, and Management.
3. Create Network Security Groups (NSG):
   • Create an NSG for the App subnet. Allow traffic from your corporate VPN range on specific ports (e.g., 3200 for SAP GUI).
   • Create an NSG for the DB subnet. Explicitly deny all traffic except from the App subnet IPs on the database port.
4. Associate NSGs: Bind the NSGs to their respective subnets.
5. Enable Flow Logs: Turn on NSG Flow Logs and send them to a storage account. This is a compliance requirement for most audits and is invaluable for troubleshooting connectivity issues.
6. Test Connectivity: Use the Test-NetConnection cmdlet (Windows) or nc command (Linux) to verify that only the allowed ports are open.

Note: The Importance of Bastion Avoid assigning public IP addresses to your SAP servers. If you need to access them for management, use Azure Bastion. This service allows you to connect via RDP or SSH over SSL, keeping your virtual machines completely off the public internet.

Industry Best Practices for SAP on Azure

To ensure your environment remains stable and performant, adhere to these industry-standard practices:

• Use Accelerated Networking: Enable Accelerated Networking on all your virtual machines. This uses SR-IOV (Single Root I/O Virtualization) to provide significantly lower latency and higher throughput by bypassing the virtual switch.
• Implement Proximity Placement Groups: As mentioned earlier, use these to ensure your application and database servers are as physically close as possible.
• Standardize Naming Conventions: Use a strict naming convention for all resources (e.g., vm-sap-prod-app-01). This makes it easier to track costs, manage security, and automate deployments.
• Backup and Recovery: Use Azure Backup for your virtual machines and integrate with the SAP HANA backup API to ensure consistent database backups. Always test your restoration process at least once per quarter.
• Change Management: Even in the cloud, treat your production SAP environment with the same rigor as an on-premises data center. Use a formal change management process for any infrastructure changes, including disk resizing or network updates.

Frequently Asked Questions (FAQ)

Q: Can I use the same Landing Zone for non-SAP workloads? A: You can, but it is generally discouraged for large enterprises. SAP workloads have unique performance and security requirements. Keeping them in a dedicated Landing Zone allows you to apply specific policies and monitoring tools without impacting other business applications.

Q: How often should I update my Landing Zone? A: Treat your Landing Zone like a living product. You should review your security policies, firewall rules, and resource configurations at least every six months to ensure they align with the latest Azure features and your organization's security standards.

Q: What is the biggest mistake people make during the migration? A: The most common mistake is failing to perform proper "sizing." If you migrate a system that was undersized on-premises, it will continue to be undersized on Azure. Use the SAP Quick Sizer tool to determine your exact requirements before you start building your Landing Zone.

Q: Do I need a VPN or ExpressRoute? A: For production SAP systems, an ExpressRoute is highly recommended. It provides a private, dedicated connection to Azure that is much more reliable and secure than a standard internet-based VPN.

Key Takeaways

1. Foundational Importance: An Azure Landing Zone is not an optional extra; it is the essential foundation for a stable, secure, and performant SAP environment.
2. Network Design: Prioritize latency by using Proximity Placement Groups and a hub-and-spoke network architecture to isolate traffic and improve performance.
3. IaC Adoption: Utilize Infrastructure as Code (Terraform or Bicep) to ensure that your infrastructure is consistent, version-controlled, and easily reproducible.
4. Storage Optimization: Select your storage tiers carefully. HANA databases require high-performance storage (Premium SSD or Ultra Disk) to prevent bottlenecks.
5. Security-First: Never expose SAP servers to the public internet. Use Bastion services and strict NSG/ASG policies to lock down your environment.
6. Continuous Monitoring: Leverage Azure Monitor for SAP to gain visibility into the health of your system, and set up automated alerts to catch issues before they impact your business users.
7. Governance: Use Azure Policy to enforce standards and prevent configuration drift, ensuring your Landing Zone remains compliant over time.

By following these principles, you will create a robust environment that not only supports your current SAP migration but also provides the flexibility and scalability required for the future growth of your organization. Transitioning to the cloud is a significant step, but with a well-architected Landing Zone, you position your SAP landscape for long-term success.