Skip to Content
Technical Articles
Author's profile photo Thomas Jung

SAP Development Using Amazon Cloud9

For a few weeks, I’ve been researching various non-SAP development tools environments; especially those that are cloud based or cloud oriented. I’ve been looking at how non-traditional SAP development might use their existing tooling for development in the SAP business application development space.  I’ve also been focused on how traditional SAP application developers might broaden their boundaries and benefit from tooling outside what they already know.

I began with a focus on HANA Deployment Infrastructure and how modern HANA development can be done without XSA, Cloud Foundry or the SAP Web IDE. This blog utilized command line tooling combined with Microsoft Visual Studio Code.

From there I expanded my experiments by trying out the Google Cloud Shell. The Cloud Shell is a free, small Linux system which a developer can spin up on demand. This environment is pre-installed with many common developer tools – Maven, Node.js, Google Cloud SDK, etc.  This gives developers a quick start, low touch development environment that is very cloud native.

Now I’ve decided to try out Amazon’s cloud IDE offering – Cloud9 as well.  If there is one common theme here is that Shell is King. The central idea is that we use the easy and low cost option to spin up cloud based server environments quickly and expose a browser based shell environment to access it. The tooling experience revolves around this remote shell and any tooling or api that can be accessed via command line can work without needing some special integration.  This is where the SAP direction with SAPUI5, CAPM, etc for command line based tooling is so nice for integration into these other environments as well.

Getting Started

We will begin by looking at the process to get starting using AWS Cloud9.  I already have an AWS account, so I’m not going to cover the basics of signing up.  That’s been covered well elsewhere.  Instead I’ll login into my account.

And then I will navigate to the launch page for the AWS Cloud9 product.  From there you can start a simple wizard to launch a new environment.


Right away we see a little different approach compared to Google Cloud Shell.  With the Google service you press a single button to Activate the Cloud Shell as a largely pre-configured image with few options to control sizing.  Amazon however seems to lean harder into the options to either start a new EC2 instance or even connect to an existing server.  This gives you a bit more options. You can follow the Google approach of just spinning up a very small, private server instance for temporary development or you could instead custom size a development server suitable for larger scale testing or centralized team development.  This view of team based development comes into play later as well as Cloud9 has some interesting collaborative features built in.

I choose to start with a private developer shell kind of approach and opted for a t2.micro instance.  If your account still qualifies for the free-tier, this size fits within the free option.  My account is too old to fall within the free option any longer, but still I’m only looking at paying about 0.01 USD an hour for this size.


At the end of the wizard, you get this very interesting best practices information:

There is some really key information here that’s central to all of these cloud based development approaches.  First the idea that the development environment is ephemeral.  The whole dev server might go away or change at any time.  Therefore when you save in any of these environments, its not necessarily permanently persisted.  A central Git repository should be your only true persistence. This way we don’t tie our development process to any one cloud or vendor tool or environment.  I took a project I started on my local laptop in VS Code, edited via SAP Web IDE full-stack on SAP Cloud Platform,  edited it further in Google Cloud Shell and then brought it into Cloud9 for even more work and running it all with no environment specific configuration.

The other important point is about updates of software.  This was one of the main appeals of these environments is that many common development tools are already installed and configured. Cloud9 is no different in that regard.  But note the item #2 that AWS Cloud9 doesn’t perform automatic updates.  But this is where I think the idea of treating your development environment as ephemeral was interesting.  Personally I deleted my environment when I was done working for the day.  The next day I’ll recreate the entire environment.  That way my tooling software is up to date as the core image. Its a different way of thinking – that you development server and environment is disposable but one that increasingly makes sense in a cloud world.

Now I want to start by doing some SAP Cloud Application Programming Model development. To get a good test and comparison, I want to follow the same tutorial for Node.js Local Development found in the SAP online help that I used in the Google Cloud Shell evaluation.

Once again this is where having a pre-installed and configured environment is so handy.  The development server and IDE already have Node.js, NPM, and so many other things installed and perfectly ready to use.  I can further configure these tools by opening a terminal shell directly within the Cloud9 development tooling.  For instance I want to add the sap registry ( to my NPM configuration.

I’m now able to use NPM to install the @sap/cds module which functions as the command line development tool for SAP Cloud Application Programming Model.

CAP Development

From there I begin in earnest with the tutorial. I can use the cds module we installed previously to initialize this empty project for Cloud Application Programming Model development.  The command shell creates the project structure but then we can further edit using the graphical folder structure and other editors.  Its a graceful combination of the power of the command line but the time savings of more guided developer tooling.

So after following along with the first few steps of the tutorial, I’m ready to test my OData service.  From the shell window within Cloud9, I can start the OData server using the cds run command.

And much like the Google Cloud Shell environment, there is an easy application preview that will launch testing access via a web browser.  No long deploy, startup or complicated testing configuration needed. Its simply save, run and you are seeing your changes within seconds.

And once again we see the power of combining shell, command utilities and a development IDE.  I continue with the tutorial and deploy my DB model to sqlite3 (which in turn I installed into this environment using NPM).

I can also use CURL from a second shell command instance to test non GET operations on the OData service. So I had no problems following the entire tutorial from this development environment.

So now we’ve seen two very different cloud providers but with similar approaches to how they treat the cloud based development environment.  I find the more I work in this approach with disposable development servers, portable projects, and command shell centric tooling and running; the more I like it.  The flexibility and power are quite appealing.


I did do a little bit of playing around with the Cloud9 environment that went beyond just trying to run through the SAP Cloud Application Programming Model tutorial.   For one I was really impressed by the breadth of programming languages that were supported in Cloud9  I found way more than expected.  In fact I was pleasantly surprised to even find ABAP supported out of the gate. So naturally I had to clone an ABAP based project and at least give it a spin:

I also found on Twitter the other day a tutorial for running VS Code via a web server – which was designed to run on Google Cloud Shell.

I was curious if the same would work on AWS Cloud9.  I did have to increase the size of my ec2 instance to t2.small, but then VS Code ran fine from it. I was even able to load the SAP CDS Extension (which installs via local vsix file).


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Michael Howles
      Michael Howles

      Great post, Thomas.  I really like Cloud9 as well as VS Code.  I feel VS Code has better extensions ecosystem however Cloud9 is easy turnkey solution for developing in the cloud.  I also like the graphical Git support better in VS Code versus having to resort to git CLI commands.  I do also like how Cloud9 shuts itself down after inactivity.  One thing that ALMOST combines what I like best about each is which runs VS Code in the browser from a server (or via Container for zero-effort approach) and it supports VS Code extensions and Terminals.  It's worth also checking out if you have the time!

      Author's profile photo Thomas Jung
      Thomas Jung
      Blog Post Author

      Actually if you have look at that last screenshot in this blog, its VS Code running via code-server from this same environment (I also run it on Google Cloud Shell). In fact I spent all day today coding in VS code running from Cloud Shell and interacting with HANA via hdbsql in a terminal window.  But that's a blog for another day...

      Author's profile photo Michael Howles
      Michael Howles

      Ah, I see!  My bad.  All the IDEs start looking the same after awhile 😉

      Author's profile photo Nabheet Madan
      Nabheet Madan

      Great blog sir!. Just like we have option of customizing our Google Cloud shell as per once need based on the image does AWS also provide the same?

      Author's profile photo Thomas Jung
      Thomas Jung
      Blog Post Author

      It was a little different with AWS than GCP.  GCP has a dedicated Cloud Shell image that through some effort you can customizing beyond just persisting your profile.  AWS took a little different approach allowing you to connect to any existing EC2 instance.  Therefore you can always just customize, snapshop, AMI-ize your own development images as much as you want.