Skip to Content
Author's profile photo Chris Kernaghan

Going from theory to delivery AWS style

Up to now all the work I have done has been theoretical, with the view to deployment at some point in the future.

Well as some wise person said, “The future starts here”, and so in November I was asked to deploy an SAP landscape in the AWS cloud for a client blueprint project.

I was given 6 days to deploy the following landscape

An ECC 6.0 system with CRM Best practices,

A Portal 7 system,

A CRM 7 system with CRM Best practices,

A Solution Manager system,

A BI system.

A challenge to be sure, but one I was keen to complete in order to prove the skills I had built up over the course of my adventures in the Cloud.

System Builds – Planning

In order to provide the systems in the shortest time possible I ran the installations in parallel, which takes a bit more planning in order to get the installation parameters decided from the outset

During the original POC with SAP I built an excel spreadsheet in order to keep track of the SAP Instances, the Elastic IP and the storage volumes used by each system.

SAP Instance Worksheet

Disk Config Worksheet

Elastic IP sheet

Of course you do not have to follow what I have done, for me this method works, although I can see why in a distributed team this is open to serious error.

I think that something like a Google Document or a simple web application which provides the same details in a multi-user setting.

As you can see above, I was able to plan out several of the key details before starting.

I could define the SID, the DNS name and the the disk volumes then fill in the AWS provided parameters, like Instance name and Volume name.

System Builds – Installation

So once the planning was done, it was time to get my hands dirty and crack on with the installations 🙂

I chose a public AMI – Windows 2003 Server 64bit, since I was unable to use any of the AMI’s from the SAP POC as they are on a different account I had to begin form stratch.

Which was a very good test of the theory I had laid down in the previous blogs.

So using the previous blog  Creating the AMI, preparing for the SAP install, I created the AMI and prepared it for the SAP install.

  • Change the system name;
  • Create the page files;
  • Create administration users;
  • Create the disk volumes and assign to particular drive letters.

Once the AMI is prepared the SAP installation is executed in the normal way.

System Builds – Securing the SAP System

The previous blog regarding security was based on using the system for a POC, now security is vital and needs careful consideration as if there is ANY customer data on the system then the company providing the AWS service is liable.

In order to use an SAP system several ports need to be opened

  • SAP Dialog Port – 32xx
  • SAP Gateway Port – 33xx
  • SAP Message Server Port – 36xx
  • SAP Portal  Port – 5xx00

The requirements for access to this environment are

  • Accessible from the client site – reasonably easy to provide as there is a single/range of IP addresses that can be added for access.
  • Accessible from Capgemini India – reasonably easy to provide as there is a single/range of IP addresses that can be added for access.
  • Accessible from Public Internet – this is the problem, consultants with 3g cards using dynamic IP addresses

As result it becomes necessary to use a ‘choke point’ to reduce the number IP addresses to be granted access.

How to do this is open to debate, obvious possibilities are

  • Corporate VPNs
  • Internet gateways
  • Software VPNs

So more work is needed to be completed in order to work out the Pros and Cons of each method.

SAP Password security is also vital – if there are ports open to the Internet the last line of defence of the system is the strength of it’s passwords.

There are specific SAP parameters to enforce password security, but these should be implemented in line with corporate policy with a risk based view on the public internet facing aspects of the systems.

I will not give away my favourite method of constructing passwords so that they are both memorable but only breakable using brute force methods.

These is a massive gotcha in the provision of the RDP service on Windows systems – never ever ever open the RDP port to the internet.

If does not matter if you have 20 IP addresses that you use to access the RDP port, but the RDP port is something that will be abused if you open it up.

At the minute I only have it opened to two static IP addresses in order to protect the servers.

Post Installation tasks

At this point I have been working on the Installation for about 12 hours and have completed the base installations and initial security setup.

In order to complete the installation and have the system ready the following 3 tasks need to be completed

  1. Reconfigure the Database logging parameters and setup backups;
  2. Perform a client copy to create the development client;
  3. Perform a system generation.

I found that the disk to CPU performance could be faster, and it is noticable when performing an SGEN.

But to be fair, there are worse things in life and until I see more people on the system I do not know if it will adversely affect performance on a regular basis.

These tasks were completed within10 hours, so the systems were delivered ready for use (without additional software) within 22 hours.


So now I have been able to deliver a system landscape in the cloud that is now being used to provide a Blueprint system in a time that is utterly amazing.

The system so far has been stable and the performance has been excellent.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Arundeep Singh
      Arundeep Singh
      Hi Chris,

      It is good to see the cloud working for SAP. It still not really and SAP application Cloud. But definitely a step forward in the same direction.

      I believe this duration of 22 hours for setup of all the systems is best short and does not include troubleshooting time which may rise at times.

      Also it does not inlcude any preparation work to setup the platform, downloading softwares, preparing the disks etc.  Am I correct in my understanding?

      But still the time of 22 hours for all the systems is very good. I am sure all your pre planning has paid you off in big time.

      Arundeep Singh

      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author

      I am not sure I understand what you mean that it is not really an SAP Application Cloud, it simply an infrastructure service that you can configure to your requirements - it is IaaS not PaaS.

      Also 22 hours setup time is not short, it includes everything from scratch, disks, IP addresses, DNS entries. I ran the installations in parallel on their servers, for which the longest database import took just 6 hours. Remember these are very basic builds, no configuration, that was to be left to the blueprint team.

      As regards troubleshooting, because of the pre-planning I did and the simplicity of the landscape, this was not necessary.

      I was handed a challenge to put this up in the fastest, most effective way possible, under less presured circumstances would I do it in the same timeframe - No. The point of referencing the time periods in this blog is to demonstrate just how powerful and flexible a platform it is.


      Author's profile photo Arundeep Singh
      Arundeep Singh
      Yes, you are right. I was talking about the difference of IaaS and PaaS only. I just put my point that it would be interesting to see when we have SAP images right away. I know SAP is working on it. Hope, I will also get a chance to work on it some day 🙂

      Indeed, the performance figures you posted does help to buid up confidence.

      Thanks for the valuable inputs