Introduction
Both AWS and Azure provide a variety of technologies for deploying an application server. Java, .NET, PHP and Python are all supported on both platforms. I am most familiar with Java on Tomcat so that is what I have chosen to deploy first.
AWS and Azure each have several ways of deploying Tomcat web applications. I have chosen the option that allows developers to focus fully on application development. Under this option the Tomcat container is managed by the platform, configuration is done by an architect or administrator and developers simply deliver a standard WAR file.
Azure
In this article the Azure deployment was done using the preview of the new Azure management portal. The meat of the process should be the same in the current default portal.
Creation of an application service in Azure starts with selecting +NEW -> Web + Mobile -> Web App, entering initial details and selecting Create.
After a brief pause animation the web app panel is displayed.
Now you access the Web App Settings page by selecting All settings -> Application Settings. Here you select Java 1.7.0_52, Tomcat web container, 64-bit and Save. Java 1.7 is the only version available under Web App on Azure. This is not great as Oracle stopped posting public updates to this version in April 2015. Microsoft may still have access to new security patches but obviously Oracle's focus is now fully on Java 1.8.
To allow your web application to be deployed you select Deployment credentials in the left menu. Here you enter a set of credentials that will be used for all web apps deployed under this Azure account and Save.
You probably want your web application to connect to a database. If you are using an Azure database service then you can get the connection string by selecting Browse everything at the portal home page, selecting your database, clicking the "Show database connection strings" link, then clicking the copy icon next to the JDBC string.
You can paste this string somewhere and update the password. You then go back to the portal home, select Browse everything, select your web application, and select All settings -> Application Settings again. Here you can scroll down to the Connection strings and create one with whatever name makes sense to you, e.g. dbconnstr, the value you copied and updated, and a type of SQL Database.
The web application itself can be created in any Java IDE and exported to a WAR file. To access an Azure database the web application will need to include the Microsoft JDBC Driver for SQL Server (https://msdn.microsoft.com/en-us/sqlserver/aa937724.aspx) and read the connection string from an environment variable. The variable name is the name you set in the connection string settings prefixed by SQLAZURECONNSTR_. So for the connection string named dbconnstr the code to retrieve the value is System.getenv("SQLAZURECONNSTR_dbconnstr").
Deployment is done using FTP. You can get the FTP connection settings by selecting Properties in the web application settings.
You can use any FTP client to connect to the FTP (or FTPS) host, authenticating using the user on the Properties page and the password that you set under Deployment credentials. On the remote server you need to navigate to site -> wwwroot -> webapps, then put your exported WAR in the folder. The hosted Tomcat will then deploy the web application and you should be able to access it from the public internet.
AWS
Creation of an application service in AWS starts with selecting Deployment & Management -> Elastic Beanstalk, then Create New Application and filling in the application name.
You select Next, then Create Web Server.
Now you select Create an IAM role and instance profile, then Next.
At this point you select a predefined configuration of Tomcat and choose a Tomcat and Java version. AWS defaults to Tomcat 8 on Java 8. I changed the version to Tomcat 7 on Java 7 64-bit to match the Azure configuration. I selected a single instance environment type to minimise initial price and selected Next.
Under Application Version you can choose to upload your own WAR file and select one exported from your Java IDE, then select Next. AWS stores the connection string in a specific environment property so the web application needs to read it using System.getProperty("JDBC_CONNECTION_STRING").
With the WAR loaded you need to set a unique environment URL. For simplicity and price you can leave the next few screens at their default values.
On the last page of the wizard you can review the information you have entered and select Launch. The health of your web application will display as Launching for a minute or so, then change to Green.
AWS doesn't seem to have a function to give you the connection strings for a database so you will have to build it yourself from the host name, database name and user credentials. To enter it into the environment property you select Configuration on the left menu, scroll down to Environment Properties, make it the Property Value of the JDBC_CONNECTION_STRING property, then select Apply. The health of the web application will display as Updating for a minute or so then Green.
Now you will need to provide network access from your web application to your database. From the console home you need to go to Networking -> VPC -> Security Groups, select the group named rds-launch-wizard, go to Inbound Rules -> Edit -> Add another rule. Here you should set the Type to MS SQL (1433), the source to the group ID for your new Elastic Beanstalk application. The group ID should be visible in the group list above the form. After selecting Save your web application will be able to connect to your database and be accessed from the public internet.
Comparison
The largest difference between AWS and Azure for Java web applications is the choice of Java and Tomcat versions. AWS allows a large variety of Java and Tomcat versions to be deployed. Azure only allows one and it is not the latest version of either. As with the databases you can install Windows or Linux OS on Azure and install whatever version of Tomcat you like but then you must manage the OS yourself.
A more subtle difference between AWS and Azure when installing an application service and database service is in the security. By default, when allowing access from Azure services to your database, you are allowing access at the network level from services. It may be possible to tighten this up through use of more networking services but in a simple set up you cannot lock down specific application services to specific databases. AWS allows you to define as many security groups as you require for your services and allow only the communication paths that they require.
As with the databases AWS provides a few more granular controls on resources whereas Azure provides a single setting for the pricing tier. Unlike the database services the differences between the Azure pricing tiers are clearly specified in technical detail rather than using an abstract performance measure.
Overall both services are easy to set up but AWS seems to provide a more architecturally sound PaaS environment for deploying Java web applications.
For the ultimate in disaster recovery capability there is nothing stopping you from installing your database and Java web applications on both services as long as you are comfortable with a Java 7, Tomcat 7, MS SQL Server 2012 environment. Your web application will need to check two places to find its connection string but that is a small piece of extra complexity.