# Microsoft SQL Server for SAP NetWeaver on AWS Deployment and Operations Guide SQL Server setup *SAP specialists, Amazon Web Services* * [Last updated](document-revisions-sap-sql.md#document-revisions-sap-sql.title): December 2020* This guide provides guidance on how to set up AWS resources and the Microsoft Windows Server operating system to deploy Microsoft SQL Server for SAP NetWeaver on Amazon EC2 instances. This guide is for users who are responsible for planning, architecting, and deploying SQL Server on AWS for SAP NetWeaver based applications. You should have a good understanding of AWS services, general networking concepts, Windows Server operating systems, and SQL Server administration. ## Overview This guide is part of a content series that provides detailed information about hosting, configuring, and using SAP technologies in the Amazon Web Services Cloud. For the other guides in the series, ranging from overviews to advanced topics, see [SAP on AWS Technical Documentation home page](https://aws.amazon.com/sap/docs/). This guide provides guidance on how to set up AWS resources and the Microsoft Windows Server operating system to deploy Microsoft SQL Server for SAP NetWeaver on Amazon EC2 instances. Instructions in this document are based on recommendations provided by SAP and Microsoft for SQL Server deployment on Windows via the below SAP notes or KB articles: **Table 1 - SAP NetWeaver on Windows OSS Notes** | SAP OSS Note | Description | | --- | --- | | 1656099 | SAP Applications on AWS: Supported DB/OS and Amazon EC2 products | | 1409608 | Virtualization on Windows | | 1732161 | SAP Systems on Windows Server 2012 (R2) | | 2384179 | SAP Systems on Windows Server 2016 | | 2751450 | SAP Systems on Windows Server 2019 | | 1564275 | Install SAP Systems Using Virtual Host Names on Windows | | 1772688 | SQL Server AlwaysOn and SAP applications | In addition, this document also follows best practices from AWS, Microsoft, and SAP for SAP NetWeaver deployments on Windows. This guide is for users who are responsible for planning, architecting, and deploying SQL Server on AWS for SAP NetWeaver based applications. You should have a good understanding of AWS services, general networking concepts, Windows Server operating systems, and SQL Server administration. This document doesn’t provide guidance on how to set up network and security constructs like Amazon Virtual Private Cloud (Amazon VPC), subnets, route tables, ACLs, NAT Gateway, IAM Roles, AWS Security Groups, and so on. This document focuses on configuring and maintaining compute, storage, and operating system for Microsoft SQL Server for SAP NetWeaver based applications. # Prerequisites ## Specialized Knowledge Before you follow the instructions in this guide, we recommend that you become familiar with the following AWS services. (If you are new to AWS, see [Getting Started with AWS](https://aws.amazon.com/getting-started/).) + [Amazon EC2](https://aws.amazon.com/documentation/ec2/) + [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon FSx](https://aws.amazon.com/fsx/) + [Amazon VPC](https://aws.amazon.com/documentation/vpc/) + [AWS CloudFormation](https://aws.amazon.com/documentation/cloudformation/) + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html) + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ## Technical Requirements Before you start to deploy Microsoft SQL Server database for SAP applications on AWS, ensure that you meet the following requirements: + Windows Server 2008 R2, 2012 R2, or 2016 operating system + Microsoft SQL Server 2008 R2 or higher database + Install [AWS SAP Data provider](https://docs.aws.amazon.com/sap/latest/general/aws-data-provider.html) on Amazon EC2 instances after installing SQL Server database + If you plan to deploy domain installation, you should have a user ID that is a member of domain admins. Otherwise, the domain admin should create groups and user IDs (such as adm, SAPService, and so on) as required for SAP in advance. See [SAP installation guide](https://help.sap.com/viewer/nwguidefinder) for more details. + AWS Account with permission to create resources. + Access to SAP installation media for database and application + AWS Business Support or AWS Enterprise Support plan # Planning **Topics** + [ # Architecture Options ](architecture-options.md) + [ # Deployment Options ](deployment-options.md) + [ # Security ](security.md) + [ # Sizing ](sizing.md) + [ # Operating System ](operating-system.md) + [ # Compute ](compute.md) + [ # Storage ](storage.md) + [ # Network ](network.md) + [ # Business Continuity ](business-continuity.md) # Architecture Options SAP NetWeaver applications based on SQL Server can be installed in three different ways: + **Standard system or single host installation**: ABAP System Central Services (ASCS)/System Central Services (SCS), Database, and Primary Application Server (PAS) of SAP NetWeaver run in single Amazon EC2 instance. This option is suited for non-critical and non-production workloads. + **Distributed system**: ASCS/SCS, Database, and PAS of SAP NetWeaver run on separate Amazon EC2 instances. For example, you can choose to run ASCS and PAS on one Amazon EC2 instance and database on another Amazon EC2 instance or other possible combinations. This option is suited for production and non-production workloads. + **High Availability (HA) system**: For your SAP application to be highly available, you need to protect the single point of failures. Database is one single point of failure in SAP applications. There are two methods you can use to protect SQL Server and make it highly available. + Database native solution: [SQL Server Always On](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-2017) availability group. + Third-party solutions: For example, [SIOS Data Keeper](https://us.sios.com/solutions/sql-server-high-availability/), [Veritas InfoScale](https://www.veritas.com/support/en_US/doc/ka6j000000009eOAAQ). Regardless of which option you choose to make your SQL Server database highly available, AWS recommends that you deploy a primary and secondary SQL Server in different AWS Availability Zones within an AWS Region. The following diagram provides a high-level architecture for SQL Server high availability on AWS. This option is suited for business-critical applications. ![\[High-level HA architecture for SQL Server\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/high-level-ha-architecture-sql-server.png) # Deployment Options Microsoft SQL Server 2008 R2 or later is supported for SAP applications on AWS. See [SAP Note 1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products](https://me.sap.com/notes/1656099) for supported SAP applications and databases on AWS. # Security AWS provides several [security capabilities](https://aws.amazon.com/security/) and services to securely run your SAP applications on AWS platform. In the context of SQL Server for SAP applications, you can use network services and features such as Amazon VPC, AWS Virtual Private Network, AWS Direct Connect, and Amazon EC2 [security groups, network access controls, route tables,](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) and so on, to restrict the access to your database. ## Network Security Generally, databases for SAP applications do not require direct user access. We recommend that you only allow network traffic to the Amazon EC2 instance running SQL Server from Amazon EC2 instances running SAP application servers (PAS/AAS) and ASCS/SCS. By default, SQL Server receives communication on TCP port 1433. Depending on your VPC design, you should configure Amazon EC2 security groups, NACLs, and route tables to allow traffic to TCP Port 1433 from SAP application servers (PAS/AAS) and ASCS/SCS. ## Encryption We recommend that you encrypt your data stored in AWS storage services. See the following documentation for more details: + [Encrypting Data at Rest and in Transit for Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html) + [Protecting S3 objects using encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) + [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) # Sizing [SAP Quick Sizer](https://www.sap.com/about/benchmark/measuring.html) is generally used to size the SAP environment for new implementations. However, if you are migrating your existing SAP applications based on SQL Server to AWS, consider using the following additional tools to right-size your SAP environment based on current use. + **SAP Early Watch Alerts (EWA):** SAP EWA reports are provided by SAP regularly. These reports provide an overview of historical system use. Analyze these reports to see if your existing SAP system is overused or underused. You can use this information to right size your environment. + **Windows native tools:** Gather and analyze historical use data for CPU/Memory with [Performance Monitor/Windows System Resource Manager](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc749154(v=ws.11)) to right size your environment. + ** AWS Application Discovery Service:** [AWS Application Discovery Service](https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html) helps with collecting usage and configuration data about your on-premises servers. You can use this information to analyze and right-size your environment. Since it is easy to scale up or scale down your Amazon EC2 instances on AWS, we recommend that you consider the following guidelines when sizing your SAP environment on AWS. + Do not add too much capacity to meet future demand. + Account for the SAP Quick Sizer buffer. SAP Quick Sizer tools provide sizing guidance based on assumptions that for 100% load (as per your inputs to tool) system use will not exceed 65%. Therefore, there is a fair amount of buffer already built into SAP Quick Sizer recommendation. See [SAP’s Quick Sizer guidance](https://apps.support.sap.com/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sap/qs_oberflaeche/pdf1.htm?area=QSDOC&filename=QS_for_beg_classic.pdf) for details. # Operating System SAP applications based on SQL Server are supported only on Windows operating system. For supported Windows version, see the SAP [product availability matrix (PAM)](https://support.sap.com/pam) for the SAP application that you plan to deploy on AWS. # Compute AWS provides multiple SAP certified Amazon EC2 instances. See [SAP Note 1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products](https://me.sap.com/notes/1656099) for details. Based on results of your sizing exercise, you can deploy your SQL Server on any of the SAP certified Amazon EC2 instances that meets your requirement. # Storage The following table lists the main directories for SQL Server database. **Table 2 - Main directories for SQL Server database** | Usage | Directory | Description | | --- | --- | --- | | Database data files | `:\DATA0 ` `:\DATA1` **…​..** `:\DATA` | Directory for SAP database data files | | Database transaction log files | `:\log` | Directory for SAP database transaction Log | | Tempdb data files | `:\Tempdb` | Directory for temporary database data files | | SQL binaries and other data files | `:\Program Files\Microsoft SQL Server ` | Directory for SQL Server program files and master, msdb, and model data files | Amazon Elastic Block Store (Amazon EBS) volumes are designed to be highly available and reliable. Amazon EBS volume data is replicated across multiple servers in an Availability Zone to prevent the loss of data from the failure of any single component. Due to this built-in protection, you don’t have to configure RAID 1 for volumes containing database transaction log files, tempdb data files, SQL binaries, and other data files. We also do not recommend RAID 5 for database data files on AWS due to following reasons. + Volumes are replicated within Availability Zone by default. + Parity write operations of RAID 5 consume some of the IOPS available to your volume and will reduce the overall IO available for database operations by 20-30% over RAID 0 configuration. # Network Ensure that your network constructs are set up to deploy resources related to SAP NetWeaver. If you haven’t already set up network components like Amazon VPC, subnets, route tables, and so on, you can use [AWS Quick Start for VPC](https://aws.amazon.com/quickstart/architecture/vpc/) to easily deploy scalable VPC architecture. # Business Continuity We recommend that you architect your business-critical applications to be fault tolerant. Depending on your availability requirements, there are different ways in which you can achieve this. This section discusses how you can set up highly available SQL Server for SAP applications. ## High Availability You can configure high availability for SQL Server database on AWS using Always On availability groups or third-party tools. ### SQL Server Always On Availability Groups A prerequisite for deploying a SQL Server Always On availability group is Windows Server Failover Clustering (WSFC). SQL Server Always On uses WSFC to increase application availability. WSFC provides infrastructure features that complement the high availability and disaster recovery scenarios supported in the AWS Cloud. Implementing WSFC cluster on AWS is very similar to deploying it on-premises provided you meet two key requirements: + Deploy the cluster nodes inside an Amazon VPC. + Deploy the cluster nodes in separate subnets that are in different Availability Zones. See [Overview of Always On Availability Groups (SQL Server)](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-2017) for details. The following figure provides an overview of architecture for SQL Server Always On availability groups on AWS. This architecture includes following components + A VPC configured with private subnets across two Availability Zones. This provides the network infrastructure for your SQL Server deployment. + AWS Directory Service for Microsoft Active Directory deployed in private subnet. Alternatively, you can also manage your own AD DS deployed on Amazon EC2 instance. + In a private subnet, Windows Servers configured with WSFC for SQL Server Enterprise edition with SQL Server Always On availability groups. ![\[SQL Server Always On availability groups across two Availability Zones.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/sql-always-on-avail-group.png) ### Third-Party Solutions You can also use third-party tools like SIOS Data Protection Suite, NEC ExpressCluster, or Veritas InfoScale to provide high-availability for SQL Server. These solutions use WSFC and replicate data from primary to secondary with block level replication of the Amazon EBS volume. ## Disaster Recovery Disaster recovery is about preparing for and recovering from a disaster. Any event that has a negative impact on your business continuity or finances could be termed a disaster. To implement a cost effective Disaster recovery strategy for your SAP applications and databases that meets your business objective you need to consider the following requirements. ### Separate DR Strategy from HA Design First you must evaluate whether a separate DR strategy is required in addition to the HA design offered by AWS protection. On AWS, we recommend that you deploy business critical application in high availability architecture across two Availability Zones in an AWS Region. Each Availability Zone is designed as an independent failure zone. This means that Availability Zones are physically separated within a typical metropolitan region and are located in lower risk flood plains. Availability Zones include a discrete uninterruptable power supply (UPS) and onsite backup generation facilities, and are each fed via different grids from independent utilities to further reduce single points of failure. The level of protection provided by Availability Zone design is sufficient for most customers and is able to meet their business objectives. ### DR in AWS Regions If you determine that you need a separate DR strategy, next you must decide if you need a DR plan in a different AWS Region than your primary AWS Region or in same AWS Region as you primary (for example, using third Availability Zone of your primary AWS Region as DR). Data sovereignty is the primary reason that influences this decision. However, there may be other reasons, such as proximity to users, cost, ease of management, and so on. ### DR Architecture Finally, you must decide on the DR architecture and understand the infrastructure required to implement it. The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the primary factors that influence DR architecture. We recommend any of the following three DR architectures: + **Cold:** This architecture essentially relies on backups. Backups are taken (database – data and log, AMI, Snapshots) on a regular basis and used to rebuild the systems in the target AWS Region to recover for any disaster. Because this architecture completely depends on backups, the RPO depends on how frequently you take backups, and RTO depends on how large the database is to be recovered. + **Pilot Light:** This option provides better RTO/RPO over cold option because the SQL server database is synchronously or asynchronously getting replicated to a smaller EC2 instance. If you choose this architecture, you mus resize SQL Server EC2 instances, create application server from AMIs before starting production operations. You can use [AWS CloudFormation](https://aws.amazon.com/cloudformation/) to automate these tasks. + **Hot DR:** SQL Server database for DR EC2 instances are sized the same as production instances which helps to reduce recovery time over Pilot light because you do not need to resize the instances before starting production operations. For application servers, you can choose to replicate the volumes with CloudEndure or other third-party tools, like SIOS, ATAMotion, and so on. Depending on your specific RTO/RPO, you can implement cold, pilot light, or hot DR architecture. The following table below provides a comparison between cold and pilot light DR for achievable RTO/RPO. **Table 3 - Cold versus Pilot light DR** | DR Architecture | Strategy | RTO/RPO | | --- | --- | --- | | Cold | SQL Server backup/restore | High/High\$1 | | Cold | Amazon AMI | Low/High | | Cold | Amazon AMI with frequent DB volumes (Data & Log) snapshots | Low/Low\$1 | | Pilot Light | Sync Replication (with-in primary region) | Low/Near-Zero | | Pilot Light | Async Replication (in different region) | Low/Few Minutes | | Hot | Async Replication (in different region) | Few Minutes/Few Minutes | \$1The exact time it will take to recover database in DR scenario depends on how much you need to catch up to achieve point in time required for Cold architecture. **High** – couple of hours to a day or more. **Low** –less than an hour to couple of hours. # Deployment **Topics** + [ # Windows EC2 Instance Deployment ](windows-ec2-instance-deployment.md) + [ # SQL Server Deployment ](sql-server-deployment.md) + [ # SQL Server Deployment for High Availability ](sql-server-deployment-for-high-availability.md) # Windows EC2 Instance Deployment Deciding the right storage layout is important to ensure you are able to meet required IO. Amazon EBS general purpose volume (gp2) provides 3 IOPS per GB whereas provisioned IOPS (io1) provide a max of 50 IOPS per GB. See [EBS features](https://aws.amazon.com/ebs/features/?nc=sn&loc=1) for details. If you decide to separate SQL data, log, and tempdb to different volumes, consider these aspects. For gp2, with one volume for all (data, log, and tempdb). Create storage config file as below. Replace placeholder `` as per your requirement. ``` [ { "DeviceName": "xvdb", "Ebs": { "VolumeSize": , "VolumeType": "gp2", "DeleteOnTermination": true } } ] ``` For separate volumes, gp2 (data), io1 (log) and io1 (tempdb) create storage configuration file as below. Replace placeholders `` and `` with size of the disk and IOPS you need. ``` [ { "DeviceName": "xvdb", "Ebs": { "VolumeSize": , "VolumeType": "gp2", "DeleteOnTermination": true } }, { "DeviceName": "xvdc", "Ebs": { "VolumeSize": , "VolumeType": “io1", "Iops": , "DeleteOnTermination": true } }, { "DeviceName": "xvdd", "Ebs": { "VolumeSize": , "VolumeType": “io1", "Iops": , "DeleteOnTermination": true } } ] ``` # SQL Server Deployment Follow the instructions in the appropriate SAP installation guide for your version of SAP NetWeaver and your combination of operating system and database. See [SAP installation guides](https://help.sap.com/viewer/nwguidefinder). # SQL Server Deployment for High Availability 1. Deploy the SAP NetWeaver ASCS instance. For instructions, see the [SAP NetWeaver on AWS Deployment and Operations Guide for Windows](https://docs.aws.amazon.com/sap/latest/sap-netweaver/sap-netweaver-windows-guide.html) . 1. Create two EC2 instances for Microsoft SQL server, one in each Availability Zone. See the [Windows EC2 instances deployment](windows-ec2-instance-deployment.md) section for steps. 1. Assign two secondary IP addresses to each instance from the same subnet CIDR in which they are installed: 1. Use one address for Windows Server Failover Cluster (WSFC). 1. Use the second address for the Availability Group listener. You can assign IP addresses through the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS Tools for Windows PowerShell. For detailed working instructions, see [Multiple IP Addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/MultipleIP.html#ManageMultipleIP). For example, in the screenshot that follows, 10.100.4.53 is the primary private IP address of the EC2 instance. It has been allocated two secondary private addresses: 10.100.4.54 and 10.100.4.55. ![\[Locate the private IP addresses for your EC2 instances.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/multiple-ip-addresses.png) 1. Domain join EC2 instances created in Step 1. If you are using AWS Managed Microsoft AD, see [AWS Directory Service documentation](https://docs.aws.amazon.com/en_us/directoryservice/latest/admin-guide/join_windows_instance.html) for detailed steps. 1. Log in to the EC2 instance as admin, open PowerShell, and execute the following command to install the Windows Failover Clustering feature. ``` Install-WindowsFeature -Name Failover-Clustering -restart -IncludeAllSubFeature ``` **Note** This command may force your EC2 instance to restart. Make sure you execute the command on both EC2 instances. 1. Log in as domain admin into one of the EC2 instance and execute the following command to create the Windows Server Failover Cluster. Make sure to replace the placeholders before executing the command. ``` New-Cluster -Name -Node , -NoStorage ``` For example: ``` New-Cluster -Name SAPSQLCluster -Node primarysql,secondarysql -NoStorage ``` 1. Install SQL Server on both EC2 instances. For instructions, see the [SAP installation guide](https://help.sap.com/viewer/nwguidefinder). Install the database instance on the primary node. Follow SAP installation guide to install Database instance on primary node. Make sure you perform domain installations and choose **Domain of Current User** or **Different Domain** as appropriate during parameter selection. ![\[The domain model parameter.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/domain-installation.png) 1. Create operating system users on secondary instance. 1. Start **sapinst**, and in the **Available Options** pane, navigate to **Generic Options >** **MS SQL Server >** **Preparations >** **Operating System Users and Groups**. **Note** The navigation path can vary depending on the version of SWPM you are using. 1. Create users and groups for this instance, as appropriate. **Note** You do not need to create users on the primary instance because the database instance was installed on the primary node operating system. ![\[The Operating System Users and Groups option.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/os-users-groups.png) 1. Install SAP Host agent on secondary instance with SWPM. 1. Create a SQL Server Always On availability group. See the [Microsoft documentation](https://techcommunity.microsoft.com/t5/ITOps-Talk-Blog/Step-By-Step-Creating-a-SQL-Server-Always-On-Availability-Group/ba-p/648772) for SQL Always On availability group installation instructions. 1. Adjust the SAP profile files for parameters per the following example. Make sure to replace the `` placeholder with appropriate the value for your setup. For details, refer to [SAP Note 1772688 - SQL Server Always On and SAP applications](https://me.sap.com/notes/1772688). ``` dbs/mss/server = ;MultiSubnetFailover=yes ``` SAPDBHOST = `` 1. Perform failover and failback of SQL Server to validate it is working correctly. 1. Continue with installation of primary application server (PAS) and additional application server (AAS) following the instructions in [SAP installation guides](https://help.sap.com/viewer/nwguidefinder). # Operations This section provides information on AWS services that help you with day-to-day operations of your SQL Server database for SAP applications. **Topics** + [ # Monitoring ](monitoring.md) + [ # Backup and Recovery ](backup-and-recovery.md) + [ # Storage ](storage-1.md) + [ # Operating System Maintenance ](operating-system-maintenance.md) + [ # Business Continuity ](business-continuity-1.md) + [ # Support ](support.md) + [ # Cost Optimization ](cost-optimization.md) # Monitoring AWS provides multiple services to monitor and manage your infrastructure and applications on AWS. You can use services like [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) and [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) to monitor your underlying infrastructure and APIs, respectively. CloudWatch provides ready-to-use key performance indicators (KPIs) that you can use to monitor both CPU and disk utilization. You can also create [custom metrics](https://aws.amazon.com/blogs/database/monitor-your-microsoft-sql-server-using-custom-metrics-with-amazon-cloudwatch-and-aws-systems-manager/) for monitoring SQL server. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure. AWS CloudTrail is enabled on all AWS accounts and records your account activity upon account creation. You can view and download the last 90 days of your account activity for create, modify, and delete operations of supported services without the need to manually set up CloudTrail. # Backup and Recovery You need to regularly back up your operating system and database to recover them in case of any failure. AWS provides various services and tools that you can use to back up your SQL Server database of SAP applications. ## Amazon Machine Images (AMIs) You can use the AWS Management Console or the AWS CLI to create a new [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) of your existing SAP system. This AMI can be used to recover your existing SAP system or to create a clone. The AWS CLI `create image` command creates a new AMI based on an existing Amazon EC2 instance. The new AMI contains a complete copy of the operating system and its configuration, software configurations, and optionally all Amazon EBS volumes that are attached to the instance. For details on how to create an AMI of an existing Amazon EC2 instance, see [Creating an Amazon EBS Backed Windows AMI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html). AMI creation and lifecycle can be centrally managed in [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) AWS Backup. ## Amazon EBS Snapshots You can back up your Amazon EBS volumes to Amazon Simple Storage Service by taking point-in-time [snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html). Snapshots are incremental backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. Snapshots are suited to back up SAP file systems like `/usr/sap/ ` , `/sapmnt/`. If you decide to take snapshots of your EBS volumes containing data and log files, make sure to use [Volume Shadow Copy Service](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee923636(v=ws.10)) or shut down your database before a snapshot is triggered for consistency. You can use [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) to create backups using VSS functionalities. The following command creates a snapshot of volume (with example `volume id vol-1234567890abcdef0`). You can use this command in AWS CLI to create your own volume snapshot. ``` aws ec2 create-snapshot --volume-id --description "This is my volume snapshot." ``` ## Database Backups For SQL Server database backup, you can use one of the following methods: + **SQL native tools to take backup on disk:** Backup requires high throughput compared to IOPS. We recommend using [Throughput Optimized HDD (st1)](https://aws.amazon.com/ebs/features/) which provides maximum throughput of 500 MB/s per volume. Once the backup completes on disk, you can use scripts to move it to an Amazon S3 bucket. + ** AWS Backup **for application-consistent backups via Microsoft’s Volume Shadow Copy Services (VSS). Ensure that the flag in the advanced backup settings is enabled: ![\[Advanced backup settings.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/advanced-backup-settings.png) + **Third-party backint tools:** Partners like Commvault, Veritas, and so on use SAP backint interface and store backups directly in Amazon S3 buckets. # Storage The following list includes Amazon storage services included in this guide. ## Amazon EBS [Amazon EBS](https://aws.amazon.com/ebs) provides persistent storage for SAP application and database. You can increase EBS volume size or change the type of volume (for example, gp2 to io1) without requiring downtime. For more information, see [Modifying Amazon EBS volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html). ## Amazon FSx for Windows File Server [Amazon FSx](https://aws.amazon.com/fsx) does not require you to explicitly provision storage at all – you simply pay for what you use. Amazon FSx requires regular maintenance for patching, but you can define the maintenance windows as per your business requirements. For details, see [FSx Maintenance Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/maintenance-windows.html). ## Amazon S3 [Amazon S3](https://aws.amazon.com/s3) does not require you to explicitly provision storage at all – you simply pay for what you use. # Operating System Maintenance In general, operating system maintenance across large estates of EC2 instances can be managed by: + Tools specific to each operating system, such as Microsoft System Center 2019 + Third-party products, such as those available on AWS Marketplace + AWS Systems Manager AWS Systems Manager can help with the following key operating system maintenance tasks. ## Patching You can follow SAP recommended patching processes to update your landscape on AWS. For operating system patching, use [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) to roll out OS patches as per your corporate policies. Patch manager includes features like: + Scheduling based on tags + Auto-approving patches with lists of approved and rejected patches + Defining patch baselines AWS Systems Manager Patch Manager integrates with AWS Identity and Access Management (IAM), AWS CloudTrail, and Amazon CloudWatch Events to provide a secure patching experience that includes event notifications and the ability to audit usage. For details about the process, see [How Patch Manager Operations Work](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works.html). If AWS Systems Manager Patch Manager does not fulfil your requirements, there are third-party products available on the [AWS Marketplace](https://aws.amazon.com/marketplace). ## Maintenance Window [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) let you define a schedule for when to perform potentially disruptive actions on your instances, such as patching an operating system, updating drivers, or installing software or patches. ## Automation using Documents [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) simplifies common maintenance and deployment tasks of Amazon EC2 instances and other AWS resources. Automation enables you to do the following: + Build Automation workflows to configure and manage instances and AWS resources. + Create custom workflows or use pre-defined workflows maintained by AWS. + Receive notifications about Automation tasks and workflows by using Amazon CloudWatch Events. + Monitor Automation progress and execution details by using the Amazon EC2 or the AWS Systems Manager console. There are many AWS provided documents specific to Windows already available. # Business Continuity AWS recommends that you periodically schedule business continuity process validations by executing disaster recovery (DR) tests. This planned activity will help to flush out any potential unknowns and help the organization to deal with any real disaster in a streamlined manner. Depending on your disaster recovery architecture, business continuity may include: + Backup/recovery of database from AmazonS3 + Creation of systems from AMI and point-in-time recovery via snapshots + Changing the EC2 instance size of pilot light system + Validation of integration (AD/DNS, email, third party, and so on.) # Support SAP requires customers to have a minimum of an [AWS Business Support](https://aws.amazon.com/premiumsupport/plans/business/) plan with AWS. This ensures that any critical issues raised with SAP are also handled by AWS on priority. AWS Business Support provides less than one hour response time for production down scenarios. For a response time of less than 15 minute for business critical systems along with other benefits, you can choose [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/). For any SAP application issues, AWS suggests that you raise an incident with SAP via the SAP Support portal. After the first level of investigation, SAP can redirect the incident to AWS Support if the issue is infrastructure-related. However, if you choose to raise support issues for SAP applications with AWS Support, we cannot redirect the tickets to SAP. For any infrastructure-related issues, you can raise the issue directly with AWS Support. # Cost Optimization Resources (CPU, Memory, additional application servers, system copies for different tests/validations, and so on) require SAP landscape changes over time. AWS recommends that you monitor system utilization and the need for existing systems on a regular basis and take actions to reduce cost. In case of a database like SQL Server, the only opportunity to right-size the database server is by scaling up/down or shutting it down, if not required. Here are few suggestions that you can consider for cost optimization: + Consider Reserved instances over On-Demand instances if the requirement is to run your instances 24x7 365 days per year. Reserved instances provide up to a 75% discount over On-Demand instances. See [EC2 pricing](https://aws.amazon.com/ec2/pricing/) for details. + Consider running occasionally required systems like training, sandbox, and so on, on-demand for the duration required. + Monitor CPU and memory utilization over time for other non-production systems like Dev/QA and right-size them when possible. # FAQ **Q.** Can I use [Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/) as a database to deploy SAP NetWeaver based applications? **A.** No, Amazon RDS for SQL Server is not certified by SAP for SAP NetWeaver based applications. However, it is certified to be used as database for SAP Business Objects BI (BObj BI) **Q.** Can I purchase and use a Microsoft SQL Server license from AWS, such as [Microsoft SQL Server 2019 Enterprise on Windows Server 2022](https://aws.amazon.com/marketplace/pp/prodview-hyy374htf4h2w), Amazon Machine Image (AMI), to host my SAP NetWeaver based workloads, and other SAP workloads? **A.** Yes, AWS provides a variety of options for Microsoft SQL Server license-included AMIs, as a pre-installed package with different combinations of Microsoft Windows Server and Microsoft SQL Server versions and editions available. For more information, see [Licensing options](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-licensing-options.html) and [Find a SQL Server license-included AMI](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-amis.html). There are some differences in how SAP manages technical support, when the support ticket is raised with SAP support, and if the issue raised is found to be with Microsoft SQL Server, when those licenses are from AWS. In that situation, you need to raise a separate ticket with Support for SQL Server technical support, following the terms of your Support plan. # Document Revisions | Date | Change | | --- | --- | | December 2020 | Minor updates to text in Backup & Recovery section | | July 2019 | Initial publication |