VPC Subnet Zoning Patterns for SAP on AWS, Part 2: Network Zoning

by Somckit Khemmanivanh | on | in Best practices |

This post is by Harpreet Singh and Derek Ewell, Solutions Architects at Amazon Web Services (AWS).

In part one of this article series on VPC subnet zoning patterns, we described possible ways in which SAP applications may be accessed, and then discussed Amazon Virtual Private Cloud (Amazon VPC) subnet zoning patterns for internal-only access in detail. In this second article in the series, we’ll discuss how traditional application network zoning can be mapped to AWS.

FAST SAP Migrations to AWS with the SAP Rapid Migration Test Program

by Somckit Khemmanivanh | on | in Migration |

Somckit Khemmanivanh is an SAP Solutions Architect at Amazon Web Services (AWS).

If you have an on-premises SAP application running on a non-HANA (anyDB) database, you can now use the SAP Rapid Migration Test program with Amazon Web Services (AWS) to migrate to an SAP HANA (or ASE) version of your application on AWS. The SAP Rapid Migration Test program (also known as FAST, which stands for Fast AWS and SAP Transformation) provides a set of processes, procedures, and tools that SAP developed in collaboration with AWS to help customers running SAP applications (SAP ECC and SAP Business Warehouse) on anyDB to migrate to SAP HANA or SAP ASE on AWS.

You can use FAST to migrate your SAP system to AWS and upgrade it to SAP HANA in record time, using your own in-house resources, remote consulting, or a consulting partner. AWS was chosen as the development and launch partner for this initiative due to the flexibility and scale of the AWS platform. SAP and AWS partnered on the pilot phase of the program and found that migrations can be completed in as little as 48 hours and for as little as $1,000 in infrastructure costs.

Getting Started with Architecting SAP on the AWS Cloud

by Rahul Kabra | on | in Best practices |

Rahul Kabra is a Partner Solutions Architect at Amazon Web Services (AWS).

If you are considering moving your SAP workloads to AWS, you’re probably wondering what your SAP architecture would look like on AWS, how different it would be to run SAP on AWS vs. running it on premises or in your private cloud, and how your business might benefit from migrating to AWS. This introductory article will touch on these topics and will provide you with key data points to prepare you for migrating and operating SAP workloads on AWS.

Architecting your SAP landscape on AWS does require a minor mind-set change to take advantage of the agility and scalability that AWS offers for SAP workloads. You’ll also want to understand how SAP architectures leverage various AWS services, and how the AWS environment provides better security and availability than a traditional environment. In this post, we’ll explore architectural components to give you an overview of SAP on AWS.

VPC Subnet Zoning Patterns for SAP on AWS, Part 1: Internal-Only Access

by Somckit Khemmanivanh | on | in Best practices |

This post is by Harpreet Singh and Derek Ewell, Solutions Architects at Amazon Web Services (AWS).

SAP landscapes that need to reside within the corporate firewall are comparatively easy to architect, but that’s not the case for SAP applications that need to be accessed both internally and externally. In these scenarios, there is often confusion regarding which components are required and where they should be placed.

In this series of blog posts, we’ll introduce Amazon Virtual Private Cloud (Amazon VPC) subnet zoning patterns for SAP applications, and demonstrate their use through examples. We’ll show you several architectural design patterns based on access routes, and then follow up with detailed diagrams based on potential customer scenarios, along with configuration details for security groups, route tables, and network access control lists (ACLs).

Using the SAP Database Migration Option (DMO) to Migrate to AWS

by Somckit Khemmanivanh | on | in Migration |

Somckit Khemmanivanh is an SAP Solutions Architect at Amazon Web Services (AWS).

This blog post discusses how you can use the database migration option (DMO), which is a feature of the SAP Software Update Manager (SUM) tool, to migrate your anyDB database to SAP HANA on Amazon Web Services (AWS). SAP uses the term anyDB to refer to any SAP-supported, non-HANA source database (such as DB2, Oracle, or SQL Server). In this blog post, we will cover migration options from an on-premises architecture to AWS. (Note that there are many other migration options when SAP HANA is not your target platform; see the Migrating SAP HANA Systems to X1 Instances on AWS whitepaper for details.)

SAP HANA is a fully in-memory, columnar-optimized, and compressed database. The SAP HANA systems certified by SAP enable you to run your SAP HANA databases on systems ranging from 160+ GB of RAM up to 2 TB of RAM in a scale-up configuration. Certified scale-out configurations of up to 14 TB are also available. This system configuration flexibility enables AWS to scale to fit your business and IT needs. Please contact us if you have workloads requiring more memory—we’d like to work with you to satisfy your requirements.

For an introduction to DMO, see the SAP Community Network. At a high level, you can use DMO to migrate an SAP system that is running on anyDB to run on an SAP HANA database. You can also use DMO to upgrade your SAP system’s software components and to perform a Unicode conversion as part of your migration. (Note that as of Enhancement Package (EHP) 8, Unicode is mandatory.) The standard DMO process is an online and direct migration from your source anyDB to your target SAP HANA database. (more…)

Deploying SAP HANA on AWS — What Are Your Options?

by Sabari Radhakrishnan | on | in SAP HANA |

Sabari Radhakrishnan is a Partner Solutions Architect at Amazon Web Services (AWS).

Are you planning to migrate your SAP applications to the SAP HANA platform or start a new implementation with SAP HANA? If so, you might be wondering what options Amazon Web Services (AWS) provides to run your SAP HANA workloads. In this blog post, I want to discuss the core infrastructure components required for SAP HANA and the building blocks that AWS provides to help you build your virtual appliance for SAP HANA on AWS. I hope that that this information will help you understand deployment options at a high level. This is the first in a series of blog posts that we will be publishing about various SAP on AWS topics, so check back frequently.

If you’re following the SAP HANA Tailored Data Center Integration (TDI) model, memory, compute, storage, and network are the four key infrastructure components that are required for SAP HANA. Among these, memory is the only variable that depends on your data size. Requirements for compute, storage, and network are either preset or derived from the memory size. For example, there are standard core-to-memory ratio requirements that SAP has put in place to determine the number of cores you need for compute, based on the memory size. When it comes to storage, regardless of memory size, you need to be able to meet certain throughput requirements for different block sizes and other KPIs, as laid out in the SAP HANA Hardware Configuration Check Tool (HWCCT) guide. Finally, for network, especially for scale-out scenarios, you need to be able to drive a minimum of 9.5 Gbps of network throughput between the SAP HANA nodes, regardless of memory size.

Over the past several years, AWS has worked closely with SAP to certify compute and storage configurations for running SAP HANA workloads on the AWS platform. How have we been able to achieve that? The answer is that AWS has engineered Amazon Elastic Compute Cloud (Amazon EC2) instances with different memory sizes to meet all of SAP’s stringent performance requirements for SAP HANA, including proper core-to-memory ratios for compute. In addition, Amazon Elastic Block Store (Amazon EBS) meets, and, in many cases, exceeds, the storage KPIs of the TDI model. Finally, the network bandwidth of EC2 instances meets or exceeds the 9.5 Gbps requirement for internode communications in scale-out mode.

Let’s take a closer look at these building blocks and configuration options. (more…)

Amazon Web Services Can Now Support SAP Business Warehouse (BW) Workloads on SAP HANA up to 4TB

by Vanessa Alvarez | on |

AWS has worked with SAP to certify additional scale out architectures for SAP Business Warehouse on HANA and can now support workloads requiring up to 4TB of memory. This sets the record for SAP HANA scale-out nodes in the cloud, and validates AWS is an ideal solution for enterprise customers to cost effectively run SAP HANA. Customers now have the ability to experience all the benefits of HANA analytics while utilizing the agility, cost savings, security and reliability the AWS cloud provides. AWS offers a comprehensive, end-to-end portfolio of cloud computing services to help manage analytics by reducing costs, scaling to meet demand, and increasing the speed of innovation.

Dynamically Scale-out to Meet Demand and Increasing Data Volumes
Customers can now to scale out their AWS infrastructure to support up to 17 HANA nodes* using the AWS r3.8xlarge instance type with 244GiB of RAM. This gives customers the ability to support up to 4TB* of data in memory for Business Warehouse and/or OLAP based HANA workloads. Additionally, AWS has developed the SAP HANA on AWS Quick Start Reference Deployment, which is a step-by-step guide for deploying SAP HANA on AWS in an SAP supported manner. This guide includes field-tested best practices and links to AWS CloudFormation templates, which automate the provisioning of the AWS infrastructure components as well as the SAP HANA deployment.. By utilizing these templates, customers can have a production ready AWS SAP HANA environment up and running in as little as 30 minutes.

SAP HANA Secure Back-up and Recovery Options with Amazon S3
SAP HANA on AWS leverages Amazon Elastic Block Storage (EBS) as the primary means of storage for the HANA database. These SSD-backed EBS volumes are automatically replicated within Availability Zones to protect from component failure, offering high availability and durability. Customers also have the ability to back-up their HANA database to Amazon Simple Storage Services (S3), which is designed to provide 99.999999999% durability for as little as $.03 per GB per month. When customers store any object in Amazon S3, the data is automatically replicated amongst multiple facilities and on multiple devices within each facility in the selected AWS region. Furthermore, Amazon S3 also supports SSL encryption in transit and 256-bit AES encryption at rest, which can be automatically configured.

Replicate SAP HANA Systems in Multiple Availability Zones
When building out any system on AWS it is a best practice to start by configuring your Amazon Virtual Private Cloud (VPC). Amazon VPC allows you to logically isolate your AWS resources within a virtual network you define. You have the ability to completely control the rules within this virtual network, including IP address range, subnets, route tables and gateways. Amazon VPCs can be applied across multiple Availability Zones within a given region. Once the VPC is created, customers can provision their HANA instances within that VPC in multiple Availability Zones within the same region. This allows customers to reduce their single points of failure by replicating their HANA database clusters in multiple Availability Zones using a single VPC

AWS Enterprise Accelerator
Finally, AWS provides its customers with a number of self-service guides on how to deploy SAP HANA at scale on AWS. AWS Professional Services has developed an Enterprise Accelerator program to help customers’ jumpstart their migration of SAP workloads onto the AWS platform. The program includes AWS workshops for SAP, SAP implementation/migrations plans, reference architecture development, and more. Click here to learn more.
*HANA scale-out clusters larger than 5 nodes are currently in controlled availability. SAP will need to verify your BW sizing report result before you implement a HANA scale-out cluster larger than 5 nodes on AWS. Please contact SAP att and before you implement HANA scale-out clusters of this size.

Refer to SAP OSS Note 1964437

How SAP Business One Solution Providers Benefit from Building an AWS Practice

by Vanessa Alvarez | on |

SAP has been a member of the Amazon Partner Network (APN) since 2011 and since then, we have worked together to certify multiple SAP Solutions on AWS, including a number of configurations of Business One, and most recently SAP Business One on HANA to run on the AWS Cloud. Small and medium enterprises can now access all of the benefits of SAP Business One while leveraging the increased agility, cost savings, security and reliability that the AWS Cloud provides.
When SAP customers of all types move to AWS they almost always enjoy a lower TCO, increased agility and flexibility, and the advantages of moving to an OPEX model, which makes it a very attractive option. AWS has a very robust APN partner ecosystem with thousands of Consulting and Technology partners to support our customers globally. APN Partners are seeing that they can better serve their customers when they build a cloud practice around AWS and offer cloud solutions to their customers.
Provide Customers Solutions, The Way They want to Consume Them
If you look at the B2B software market as a whole, customers are interested in hearing about ways they can trade what usually is a large upfront CapEx expense into a lower monthly predictable recurring payment for software solutions that includes infrastructure consumption. The explosion of SaaS (software-as-service) in the market is evidence of this; the model is becoming the new standard for the way customers want to buy. When SAP Business One VARs (value-added-resellers) work with AWS to build a cloud practice they have the ability to offer their customers that exact same experience. It gives them the ability to provide their customers the SAP Business One solution they want on the terms they expect in this new cloud-based economy.
New Stable and Predictable Revenue Stream
Many software VARs operate off of a larger, transactional CapEx heavy license sales model that is measured on a quarterly basis. The revenue that they collect comes in large chunks in the quarter that they complete the sales process and obtain a payment from a customer (typically a PO). They then go through process of implementing and customizing the software over the coming months. While this does provide an influx in cash, this model is difficult to predict with a degree of certainty and typically puts companies into revenue peaks and valleys annually. These revenue peaks and valleys have an effect on gross profit, which affect marketing and other selling expenses, and can ultimately result in a potential decrease in your net income. VARs who build a fully managed SAP Business One offering on AWS introduce a new, predictable recurring revenue stream to their business that over time begins to smooth out these peaks and valleys. As they grow this business and earn back the initial customer acquisition costs they gain an increased level of predictability and more stable cash flows. The services they offer and business model they operate in today will ultimately dictate how they will shift their expenses to accommodate for this new revenue stream.

Reduce Time Consuming Steps in Your Customer Acquisition Cycle
Most of the time, SAP Business One VARs have to add multiple steps in their customer acquisition cycle around infrastructure in order to deliver a solution. They will generally have to provide a customer with the needed infrastructure requirements and allow the customer to procure new, or sometimes re-provision existing infrastructure on their own. This often requires a customer to start a second procurement track to obtain the infrastructure they need to deploy the solution they want to run. This can add weeks or months to the time it takes to deliver a solution to a customer. Regardless of the model, with AWS, you have instant access to the infrastructure you need to deploy SAP Business One globally. This allows SAP Business One VARs to provide customers more transparency around the total cost of the solution, the time it takes to deploy, and ultimately reduces the time it takes for the VAR to provide the SAP Business One solution to the customer. This allows the customer to gain access to the SAP Business One system faster and eliminate additional buying cycles.
Increase Your Agility and Provide your Customers Solutions Faster
AWS has a number of different tools that we provide our customers and APN partners to automate the provisioning of the underlying resources needed to support different applications. The power of this technology allows customers and APN partners to reduce the deployment process on AWS down to minutes and a few mouse clicks. AWS CloudFormation allows you to quickly and easily build, and deploy a template that includes a collection of AWS resources (called a stack) to support SAP Business One, or any application that can run on AWS. You have the ability to take these templates and deploy them in any of the 30 Availability Zones offered globally by AWS in a matter of minutes. This allows you to automate the infrastructure provisioning, reduce or even eliminate potential mistakes, and dramatically reduce the deployment time for a customer for SAP Business One.

Want to learn more about building an AWS Cloud practice around SAP Business One? We are here to help, contact us here.
Want to learn more about the AWS Partner Network (APN)? Click here to learn about the APN Consulting Partner program and all the benefits it provides.
Want to try Business One on Hana yourself? Click here to download our SAP Business One on HANA Quick Start. This will allow you to automatically provision an SAP Business One on HANA environment in under 90 minutes!

C4 Instance Family certified for SAP Applications

by Vanessa Alvarez | on |

The new compute-optimized EC2 instances of the C4 family are now certified for general SAP usage. The availability of the entire C4 instance family is documented in the SAP platform note 1656099 (requires SAP customer authentication)
This new family of instances allows SAP customers to improve their performance and the price/performance for compute intensive SAP workloads loads compared to the older C3 instance family.
A quick look at the SAP AWS platform note 1656099 shows as well that the flagship instance type c4.8xlarge is the AWS EC2 instance type with the highest certified total SAP throughput measured in SAPS. SAPS are a SAP throughput metric used to size SAP system.
What’s so exciting about the C4-Family?
C4 is a successor of the SAP certified C3 instance family. The new C4 instances are based on the Intel Xeon E5-2666 v3 (code name Haswell) processor. C4 instances leverage a custom version of this processor, designed specifically for EC2, which runs at a base speed of 2.9 GHz, and can achieve clock speeds as high as 3.5 GHz with Turbo boost. These instances are designed to deliver the highest level of processor performance on EC2.
The C4 instances do well with SAP applications since they allow you to achieve significantly higher packet per second (PPS) performance, lower network jitter, and lower network latency using Enhanced Networking.
I use SAP. What’s in for me?
The C4 instance family provides immediate value and savings for every one who already uses C3 instances for compute intensive SAP workloads.
The table below is a recompilation of the facts in the SAP platform note with an addition of price/performance information as used in the North Virgina region as a reference:
Instance Name RAM C3 vCPU Count C4vCPU Count C3 SAPS C4 SAPS Through-put C4 over C3 Cost per SAPS, C4 over C3*
c4.large 3.75GiB 2 2 1989 2379 +20% -16,4%
c4.xlarge 7.5GbiB 4 4 3978 4758 +20% -12,0%
c4.2xlarge 15GiB 8 8 7957 9515 +20% -10,8%
c4.4xlarge 30GiB 16 16 15915 19030 +20% -11,4%
c4.8xlarge 60GiB 32 36 31830 37950 +19% -11,4%
* Price/Performance: Costs of the North Virginia region for Windows per hour per SAPS as of April 2015
The table above shows that the SAP throughput of the C4 family is 19-20% above the one of the predecessor generation. This means to a SAP user:
• Lower risk of resource exhaustion due to 19-20% more CPU head room
• Potentially ~20% less application servers needed in client-server configuration
• Better scalability inside the box. Features like enhanced networking lower the efforts to achieve the maximum throughput.
The table shows as well that the price performance improves in between 11 and 16% depending of the instance type.
How to use the C4 Family in my SAP Fleet?
C4 instances are the perfect choice for CPU hungry SAP applications without needing too much memory.
They’re as well a great choice for CPU hungry single user test and development systems.
They’re a great starting point for standalone systems, which may not need a lot of memory. Note, if more memory is needed you can easily switch to an instance in the R3 family with a few API calls.
SAP HANA One, available on the AWS marketplace is currently supported on the c4.8xlarge instance type. For HANA deployments needing more than 60GB of RAM please continue to use the r3.8xlarge instance type.
How do I use C4 instances to optimize my SAP Instance Fleet?
First and foremost: Use HVM virtualization for all your SAP instances. This is mandatory for Windows instances. It’s optional (and strongly recommended) for Linux instances.
The HVM virtualization will allow you to switch your instance type through a simple reboot. This will work as well for future instance types!
SAP administrators will want to fine-tune their EC2 instances whenever they have a maintenance window. This allows them to stop, migrate and restart the instance. The time needed for this exercise varies depending on the individual configuration. The time needed is typically within the range it takes to have a cup of coffee…
There are two reasons to migrate an instance:
Preemptive maintenance: using a new instance type will lower the risk of forced shutdowns which may be required for security updates.
Newer instance types are likely to have a longer total product lifetime combined with a better price/performance. This leads to a recommended migration path as follows:
Rightsizing through stop/starts with instance migration: The C4 instances are financially more attractive than the R3 instances since they offer the same amount of CPUs with less memory. This makes the C4 instances very attractive for use as SAP application servers.
SAP system performance requirements may change over time. The AWS platform allows SAP users to pick a larger or smaller system in the family whenever they are needed. Now you don’t have to invest upfront for hardare you may ore may not need in the next 5 years.. Adjust your compute needs and therefore costs by the hour.
Scale up and down in the C4 instance family as you need!
The R3 instance family offers similar amount of vCPUs with more memory compared to the C4 family. The R3 instance family allows to operate SAP systems with up to 244GiB RAM.
This gives SAP users a fine grained migration path:
• Scale up and down in a family if more CPU is needed
• Migrate from the C4 family to the R3 family by reboot if you need more or less memory
The diagram below shows the choices AWS customers have to find the best fit for the needs of the day below:

The entire C4 family is certified for SAP use. SAP customers will want to use this instance type instead of the previous generation C3 family since the C4 family offers better performance and overall price/performance.
Plan your migration to C4 instances today during your next maintenance window.