AWS Certified Solutions Architect – Associate

Cloud architecture best practices help to implement hybrid multi-cloud enterprise solutions with cloud services on business technology platforms like SAP BTP, Amazon AWS or Microsoft Azure.

SAP Hybrid Multi-Cloud Architectures on BTP Azure AWS Platforms

SAP cloud reference architectures are built on the SAP Cloud Business Technology Platform (BTP) foundation with Cloud Computing and Extensibility, Integration, Network and Security, Data-to-Value pillars.

SAP Azure AWS Cloud Platform Integration and Extension Layer

These pillars can be extended with services of other cloud platforms to realize multi-cloud layers for extension, integration, machine-learning or data-driven scenarios.

Multi-Cloud Architecture Best Practices

Multi-cloud architecture best practices for resilient workloads describe design patterns to implement cloud qualities like scalability, elasticity and high availability on application, integration, network, storage or compute layers. Best practices for cloud implementations are similar on SAP and hyperscaler cloud platforms but differ in the availability of services and control options.

Loosely coupled containers or virtual machines offer implementation options to implement these cloud qualities on the cloud compute layer. Serverless application design pattern reduce the complexity and operational effort of workload management for applications running in managed, stateless compute containers with integrated monitoring and logging.

The implementation of network and security best practices protects SAP enterprise cloud workloads on integrated multi-cloud platforms.

SAP on Hyperscaler Architecture

Architectural Building Blocks (ABB) on cloud platforms are mainly separated on virtual network level. The simplified solution context diagram below visualizes main building blocks of SAP deployments on hyperscaler platforms (Amazon AWS, Microsoft Azure, Google Cloud Platform) to realize secure, high available and fault-tolerant workloads.

Multi-Cloud Computing SAP on Hyperscaler Architecture Solution Concept Diagram

These architectural building blocks can be designed on virtual network or subnet level with hyperscaler compute, storage and network resources.

Public Network Building Block

SAP cloud deployments have to be accessed from on-premise and over the public internet. Single points of entry minimize attack options and avoid many-to-many connections between on-premise and cloud building blocks.

Dedicated connections between on-premise and cloud environments offer access without public internet traffic. TLS/IPsec VPN connections can be used as alternative or additionally to dedicated connections to encrypt cloud traffic on network (TLS) or IP (IPsec) layer.

Hub-spoke topologies enable to implement single public entry points to private network areas. Public (hub) building blocks, accessible from on-premise or over the public internet, are peered to multiple private accessible cloud virtual networks (spokes).

SAP on Hyperscaler Architecture Organize SAP workloads - Hub Spoke Topology

Different virtual network components can be connected with network peering concepts on hyperscaler platforms like Microsoft Azure or Amazon AWS.

Virtual hub network areas are shared public entry points to the cloud environment, connected with routing configuration to private, only internally accessible spoke subnets with resources and services. Central entry points enable to define corporate security guidelines with rules or policies and to control or inspect traffic (ingress, egress) with network virtual appliance (NVA, Firewall) or gateways (NAT, Internet, VPN).

Hub network components can host shared backup services like domain controllers, flow control services, installation or administration services (like DNS, NTP, IDP, AD DS, PKI for SSO) to reduce subscriptions for these management resources and to separate concerns between management and workload resources. SAP support access has to be enabled via a public or elastic (AWS) SAProuter IP on the Hub.

Bastion hosts or jump boxes (servers, hosts) separate hub networks with SSL secured RDP or SSH access options and allow to jump to access limited internal resources. In contrast to bastion hosts, jump boxes are not accessible from the public internet.

Compute Building Block

Cloud compute shall automatically handle changing demand with scalable and elastic workloads. Available scale-up and scale-out options have to be evaluated for each cloud infrastructure.

SAP Cloud Operational Monitoring

Elastic computing environments handle demand changes e.g. for SAP primary (PAS) or additional application servers (AAS) automatically. Autoscaling can be implemented based on performance metrics captured with Azure Enhanced Monitoring Extensions or AWS Data Providers for SAP. In addition, SAP provides the snapshot monitoring (SMON) utility with SAP specific performance metrics in a table to be accessed via OData or RFC.

High Availability Building Block

High available workloads have to be deployed redundant across availability areas (zones/sets), interconnected with low latency and bandwidth. Load balancers distribute traffic with rules between these availability zones (AWS, Azure) or sets (Azure).

High availability SLAs offered by Azure are 99,9% for single VM, Availability Set 99,95% and AZ 99,99%.

HANA System Replication (HSR) enables high availability for SAP HANA instances with redundancy. Synchronous replication modes depend on network latency for redo log shipping. SAP offers NIPING to identify the transfer performance between availability zones.

High availability of HANA Large instances can be improved by extensions provided e.g. By SUSE or RedHat.

SAP Disaster Recovery on Hyperscaler

Hybrid multi-cloud disaster recovery strategies are based on custom recovery plans implemented with different strategies for cloud and on-premise workloads. Metrics like mean time to repair (MTTR) and mean time between failures (MTBF) are performance and resilience indicators of cloud systems.

Recovery planning has to consider service level agreements (SLA) like the acceptable maximum service interruption (Recovery Time Objective - RTO) and loss of data (Recovery Point Objective - RPO). Providing lower RTO and RPO cost more in terms of spend on resources and operational complexity.

Some recovery strategies implement active/active or active/passive setups, with defined recovery time and point objectives. Passive or standby workloads get activated in case of disaster events.

Recovery strategies can be categorized into:

Virtual IP adresses do not correspond to single hardware devices and enable failover scenarios. Examples are, AWS Overlay IPs defined on VPC level to be used across subnets and Floating IPs of Azure load balancer rules to reassign IPs from failed to other nodes (passive or warm).

Hyperscaler services like AWS Elastic Discovery Service and Azure Site Recovery Service are solutions to implement DR strategies.

SAP HANA Disaster Recovery on Hyperscaler

SAP HANA database recovery offers synchronous and asynchronous system replication between isolated, geographically independent network areas. Synchronous replication is only possible between availability zones with low latency.

Hyperscaler Backup services implement backup solutions for SAP HANA databases like AWS Backint certified for HANA Backint, Azure Backup on VMs certified for HANA Backint or certified HANA Backint third party solution or storage snapshots on HANA Large Instances.

Hybrid Cloud and Data Center Interconnection

Connections between on-premise, data-centers and cloud environments have to implement security standards and have high performance requirements. Connection targets are virtual interfaces or public service endpoints on SAP BTP AWS Azure hybrid multi-cloud business technology platforms.

Hyperscaler offer connection options like dedicated connections, VPN (Point-To-Point, Site-to-Site) or virtual WAN. Site-to-Site (S2S) are suitable for PoC, development/sandbox environments and as backup or disaster recovery option.

Dedicated Connections to Cloud Environments

Dedicated connections are private connections to hyperscaler cloud environments with guaranteed bandwidth with enhanced security and better performance than public internet connections. Dedicated connections are offered by Azure/AWS for single customers (Express Route direct, AWS Direct Connect) or by partners (Express Route, hosted AWS Direct Connections). Azure ExpressRoute and AWS Direct Connect use single mode fiber cables, which support long distances with fast transmission.

Azure automatically creates VMs with routing tables for ExpressRoute virtual gateway types with filters to limit the consumable services of Azure or Microsoft Office domains.

Dedicated solutions implement the Border Gateway Protocol (BGP) to route traffic efficiently across autonomous systems (AS) which are groups of routers uniquely identified by numbers (ASN).

Peers, communities and tags are some BGP elements. Peers represent two routers establishing TCP connections and exchanging routing information via sessions. Communities group IP prefixes with tags, assigned to virtual networks in each region, to identify and filter cloud traffic origins by on-premise route filters.

Connection Encryption Options

Encryption can be implemented on different OSI connection layers with encryption options like MACsec and IPsec, typically used for VPN connections, or combinations.

MACsec encryption offers better scalability and performance for Ethernet (LAN) and point-to-point connectivity than IPsec to protect network-to-network or device-to-network connections. MACsec encryption is available with ExpressRoute Direct or AWS Direct Connect.

Access Control of Hyperscaler Resources

Hyperscaler offer options like Private Links to control traffic to resources of service providers with private connections from virtual networks (on-premise or peered).

AWS PrivateLink endpoints are created Service Enpoints with Elastic Network Interfaces (ENI) on service consumer VPCs for private connections to resources.

Azure Service Endpoints allow to restrict traffic from private subnet endpoints of Azure vNets to resources outside the vNet. Private Links assign private virtual network IPs to PaaS resources.

Virtual appliances are often used to inspect and audit outbound network traffic.

SAP Workloads on Hyperscaler

Deployments of SAP workloads on hyperscaler environments have to consider performance requirements and costs. Workload segregation on subnet level avoids higher costs for traffic between virtual networks. The network design shall consider bandwidth metered on egress (outbound) traffics for needed network connections.

Accelerated (Azure) or enhanced (AWS) networking with single root I/O virtualization (SR-IOV) to VM NICs, offers high-performance path bypasses of host servers with reduction of latency, jitter, and CPU utilization e.g. to reduce SAP application server to database server latency, which can be analyzed with the ABAPmeter tool.

Some cost saving options are usage commitments with AWS Cost Saving Plans or Azure Reserved Instances, start-stop automation of HANA based SAP systems with AWS Systems Manager automation or Azure Runbook and stopping (deallocating) of not needed VMs.

SAP HANA Workloads on Hyperscaler Platforms

SAP HANA Databases can be deployed with conversion and lift-and-shift migration to hyperscaler platforms. Conversions from any DB can be performed as classical S/4HANA migration with system update/upgrade followed by DB migration to HANA. The SUM Database Migration Option (DMO) supports system move (changing application server), with transfer of export files to Hyperscaler, and pipe-based DMO to Azure / Hyperscaler, over WAN MPLS (Multiprotocol Label Switching) connections migration, scenarios.

Supported HANA Lift and Shift scenarios are HANA System Replication (HSR), homogeneous system copy, HANA backup and restore and Near Zero Downtime (NZDT) with clone system.

Migrations of SAP HANA systems have to be planned with sizing report /SDF/HDB_SIZING for existing SAP environments or with the HANA QuickSizer tool for Greenfield installations.

SAP HANA tailored data center integration (TDI) enables HANA installations with cloud compute, storage and network components. Cloud storage needs to be replicated on compute instances with sufficient IOPS and high throughput, enabled e.g. on RAID-0 striped volumes with redundancy implemented on storage not on RAID level.

Scaling up HANA databases offer some performance advantages and easier management than multiple cluster nodes in scale out scenarios. Scaling out of HTAP (Hybrid Transactional Analytical Processing) databases with OLTP and OLAP has to be planned e.g. how nodes are distributed over availability zones.

Data and log storage areas have to be separated completely for each HANA node (master + worker). Shared binary, trace and configuration or backup files can be mounted via NFS to each HANA cluster node.

SAP HANA Dynamic Tiering is available on dedicated hosts to extend memory with disk-based columnar store. Dynamic Tiering manages less frequently accessed (warm) data for native SAP HANA and is not available for S/4HANA and BW/4HANA, which use Data Aging strategies instead.

Large HANA instances can be deployed on non elastic bare metal servers, to overcome virtual machine limits. These hardware resources components are provided dedicated for customers with big sized databases (> 4 TB).

Overview SAP Hyperscaler Building Blocks

The following table lists some Solution Building Blocks (SBB) as part of reference cloud architectures for SAP workloads on hyperscaler platforms like Microsoft Azure, Amazon AWS and Google Cloud Platform (GCP):

SBB S/4HANA on Azure S/4HANA on AWS S/4HANA on GCP
Public Hub
Private Connectivity Azure ExpressRoute Direct Connect with VPN Gateway Cloud Interconnect with VPN Gateway
Gateways Application / VPN Internet / VPN Internet / VPN
Hub Network Azure VNet public subnet public subnet
Hub Components VPN Gateway, Azure Firewall, Azure Bastion AWS Transit Gateway, Bastion Host GCP Network Peering, VM with Identity-Aware Proxy as Bastion host
Private Spokes
Compute Engine Azure VM Amazon EC2 Google GCE
Database RDS recovery combines daily backup and transaction logs stored periodically each 5 min
Storage Azure Managed Disks AWS S3 and AWS Glacier (Standard RTO 3-5 h) Google Cloud Storage
Deployment automation ARM templates AWS Launch Wizard guided deployment Cloud Deployment Manager

These building blocks get deployed with tools or scripts to ensure reproducibility and to facilitate governance.

Hybrid Multi-Cloud Native Kubernetes

Kubernetes Cluster

Kubernetes Cluster Components

Kubernetes is suitable as central component of hybrid and multi-cloud architectures. Workloads may run in containers on different cloud provider platforms. Kubernetes multicloud deployments reduces vendor lock-in.

Kubernetes clusters are sets of nodes managed with a control plane to run containerized applications. Multi-cluster deployments enhance availability, isolation and scalability of applications.

The central part of Kubernetes clusters is the control plane, which makes global decisions about the cluster e.g. scheduling, as well as detecting and responding to cluster events. There are two primary communication paths from the control plane (apiserver) to the nodes. One from the control plane to the kubelet process and the second from the control plane to any node, pod or service through the apiserver's proxy functionality.

Kubernetes Node Components

Kubernetes Multi-Cluster components

The Google Cloud Config Connector is a Kubernetes operator, that enables managing non-Kubernetes resources and applications. Also AWS and Azure provide service operators to manage their provider specific managed services.

Istio Service Mesh

Istio provides a uniform way to integrate microservices, manage traffic flows and policies. Istio is integrated in Kyma and can be combined with Knative.

The multi cluster service mesh connects, manages and secures communication between different parts of a microservice architecture. It consists of a replicated or shared control plane and a data plane, which is composed of a set of intelligent Envoy proxies, deployed as sidecars for microservices with each pod.

Another kind of Envoy proxy is running on the edge of a service mesh, integrated with Istio ingress gateways for traffic load balancing, monitoring and routing. Internal traffic control can be configured with Istio cluster local gateways.

Knative Serverless Workloads

Knative is a Kubernetes based serverless framework, focused on implementing a cloud native, cross-platform serverless standard. Knative based applications can be deployed with containers, which is less "serverless", but more flexible and portable.

Components Short description
Eventing Implements event-driven services with bindings, which connect producers of CloudEvents with HTTP addressable, loosely coupled consumers.

Eventing requires Istio local cluster gateways for service discovery and can be extended with Knative channels for fan-out scenarios, in which Istio takes over query routing and advanced load balancing.
Serving build on Kubernetes and Istio to support the deployment, routing and auto-scaling of serverless workloads

Multi-Cloud Kubernetes Istio Knative

Knative extends Istio with Serving to support serverless applications and with Eventing to produce and consume Cloud Events.

Azure Architecture

Azure to AWS services comparison