Amazon Web Services (AWS) and SAP have developed a collaborative alliance dedicated to creating innovative solutions for businesses of all sizes and to delivering maximum customer value.
New and existing customers can deploy their SAP solutions on SAP certified Amazon EC2 instances in production environments knowing that SAP and AWS have tested the performance of the underlying AWS resources, verified performance, and certified against the same standards that apply to servers and virtual platforms.
Customers now have the flexibility to deploy their SAP solutions and landscapes on the scalable, on-demand AWS platform without making required long-term commitments or costly capital expenditures for their underlying infrastructure.
Let’s take a look at some of the architecture’s that are available with Afaria on AWS. In this paper, I will review three architectures, however with the flexibility AWS brings there are a number of alternatives for setting up Afaria. I’ll discuss “Basic Architecture”, an architecture to connect to the companies data center and an architecture providing Access Control. Others that could be considered would be, deploying AD within AWS for Afaria to use, standing up an SAP Relay Server to communicate to multiple Afaria Servers, and establishing an Afaria Server Farm with AWS. These three will be discussed at a different time.
The Basic Architecture
The first of the three architecture’s is what I would call the “Basic Architecture”. It’s ideal for SME’s that don’t necessarily need any access to their company’s infrastructure and are looking to just manage their mobile workforce. This is what would be considered an all and one architecture. The nice thing about this approach is it can scale from a small to large number of devices. Amazon allows for you to start with a small instance size and then as the need arises and the capacity of devices grow you can increase the instance size giving you greater memory and capacity.
The “Basic Architecture” has three main components to it. The Mobile Devices, the AWS Configuration and the EC2 Instance. The Mobile Devices can be any of the Afaria supported devices. Devices will typically enroll through Afaria’s Self Service Portal which is installed on the EC2 instance and part of the IIS server. The Self Service Portal is reached through the externally available address supplied by Amazon either through the Public IP Pool, or through an Elastic IP (recommended). Production instances are recommended to deploy Afaria in an Amazon Virtual Private Cloud. There are also other options of enrollment for Afaria, this is the most common. In the AWS configuration the typical configuration uses three components. The AWS Key Pair allows for the instance to use a automatically generated password for the instance, the Key Pair is used to decrypt this password. Using this ensures that the company that holds the Key Pair are the only ones that can get the initial Administrator password for the instance. Once this instance has been initialized, the password can then be changed.
A security group acts as a firewall that controls the traffic allowed into a group of instances. When you launch an Amazon EC2 instance, you can assign it to one or more security groups. For each security group, you add rules that govern the allowed inbound traffic to instances in the group. All other inbound traffic is discarded. You can modify rules for a security group at any time. The new rules are automatically enforced for all existing and future instances in the group. Setup the rules for the Self Service Portal, the Afaria Administrator Console, Device Communication and RDP.
To help you manage the Afaria server, a static Elastic IP address can replace the dynamically created IP. Elastic IP addresses enable you to quickly remap the dynamically assigned IP address to a static IP address. The Elastic IP will then become the externally available IP address, which you can assign a DNS to or use it in any way necessary. Devices and Administrator’s will typically connect to the instance through this address.
These three configurations are the starting foundation of the “basic architecture.” The Afaria server itself is a Windows 2008 R2 Server, and can be deployed into any available Amazon Region. The instance sizes can be selected at startup and can be increased as necessary. The “Basic Architecture” put’s all the Afaria Components on a single server. This includes the Afaria Server, Afaria Administrator, Afaria Package Server, Afaria Enrollment Server, Afaria Database and the Microsoft CA Server. With this configuration everything can be managed from a single server, and can scale to many thousands of devices. This architecture relies on Amazons Infrastructure stability. Monitoring and additional AWS features can be added to this configuration as needed.
Now that you have the “Basic Architecture” in place you want to add some additional features that Afaria has to offer. One of those features is Access Control Policies specifically for your Exchange or Domino. Afaria Access Control adds a layer of protection to your Active Sync Servers. Afaria Access Control filters ActiveSync Smartphone device synchronization requests by the default and exception policies you define. Afaria can apply Access Control to Exchange and Lotus Traveler, as well as Exchange 365. With Exchange 365 the configuration is simple. In Afaria just configure the Exchange 365 server and account within the Administrator and define your policies, there is no additional configuration needed. For companies who have their Exchange or Travelerservers on-premise this will require some configuration. The company will install a single component that can talk to their Exchange Server, typically on a CAS server. The component can then relay its information to the Afaria Server directly. The connection is outbound from the Company and the security group can be configured to only accept the http traffic from a specific IP as well as a specific port. Optionally, an SAP Relay Server could also be setup in AWS or at the customers DMZ for the component to talk to and Afaria to talk to. Additional information on the Relay Server can be found on the SAP Afaria sites.
Enterprises want to be able to use cloud infrastructure, but still be able to access corporate assets, even when it comes to mobile devices management. This might include AD, Corporate CA servers, applications, etc. One common way to provide this access is through Amazon’s Virtual Private Cloud (VPC). Amazon VPC lets you provision a private, isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. With Amazon VPC, you can define a virtual network topology that closely resembles a traditional network that you might operate in your own datacenter. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. To gain access to the corporate assets you can create a Hardware Virtual Private Network (VPN) connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter.
We’ve reviewed three different configurations for Afaria in AWS. There are many other options that can be considered for deploying Afaria In the Cloud and that’s what makes this such a desirable cost-effective solution for managing your mobile infrastructure.
SAP Afaria can be found in the AWS Marketplace. Customers with licenses for earlier versions of SAP Afaria can use the same license to experience SAP Afaria 7.0,sp1 on Amazon Web Services. Customers without existing licenses can receive a license that enables a 14-day free trial. The evaluation includes help from SAP mobile experts, who will guide customers throughout the test-drive process. Get started with SAP Afaria 7.0,sp1 on AWS by visiting the AWS Marketplace.