Deploying web mapping apps on Amazon S3

This post describes an easy way to deploy web mapping applications using Amazon’s Simple Storage Service (S3) to take advantage of the benefits of cloud computing.  But first, let’s review some background information about using ArcGIS for Server in the Amazon cloud.

ArcGIS 10.1 for Server in the cloud

For the last several years, many Esri customers have opted to use Amazon Web Services to deploy their ArcGIS Server services and applications to the cloud rather than buying and maintaining the required infrastructure.  Thanks to the cloud-friendly architecture of 10.1 and the new ArcGIS Server Cloud Builder on Amazon Web Services utility, launching ArcGIS Server sites on Amazon EC2 is easier than ever.  Cloud Builder also enables you to scale sites dynamically based on demand; save, use, and share site templates; and even back up your ArcGIS Server sites.

A common practice at previous releases has been to use a single Amazon EC2 instance as a GIS server and a web server (where both GIS services and web applications are deployed).  While this architecture works just fine in some situations, to truly take advantage of Cloud Builder’s capabilities, it’s good practice to separate your GIS services from your web applications.  We’ll explore an easy way you can achieve this separation using Amazon S3.

Benefits of using Amazon S3 for apps

Amazon S3 is an easy-to-use web file storage service.  It enables you to upload files to your space in the cloud and enable anyone to access those files via a web link.  Some of the benefits of using S3 include low cost, ease of administration, and reliability.

Storing files in Amazon S3 is simple and inexpensive.  Current pricing is about 10 cents/GB-month for storage plus a data transfer fee (which only kicks in after the first GB transferred).  For deploying web mapping applications, Amazon S3 would only be used to store web application files such as HTML, CSS, JavaScript, and images (your GIS data would be on your EC2 instance), and charges to store these files are likely to be extremely small for each app.

As mentioned above, it is good practice to separate GIS services and web applications so that you can use Cloud Builder to its fullest potential.  While this separation is beneficial from an administrative perspective, it also helps from a security perspective.  Using S3 allows developers to deploy apps without having to provide them access to the GIS/web server; and the security controls on S3 are simple by design and easy to use.

Other benefits of Amazon S3 are availability and durability. Amazon asserts that files on their S3 service will be available 99.99% of the time. Their figure for durability (the assurance that a file will not be permanently lost) is even higher, at 99.999999999%. You may decide that you do not need to maintain local backups of your deployed apps due to S3’s high durability, allowing S3 to act as both your deployment and backup solution.

Amazon S3 is a great solution for hosting web apps, but you need to determine if it makes sense for your requirements.  Reviewing the Esri documentation on strategies for web application deployment on Amazon Web Services and deploying a web application on Amazon S3 will help you decide.

We also recommend the Amazon S3 FAQ for more information about S3’s benefits and capabilities.

Deploying apps to Amazon S3

The steps for deploying a web mapping application to S3 are summarized below with links to more detailed AWS documentation.

  1. Log into the AWS Management Console and navigate to the Amazon S3 console
  2. Create a new “bucket,” then:
    1. Configure the bucket as a website
    2. Grant “List” permissions to Everyone on the bucket
  3. Create a folder for your application files and upload your application files to it
  4. Make your application folder public (in this link see “To make an object accessible by everyone”)

After completing these steps, you can go to your bucket’s properties, click the Website tab, and see the URL you need to provide for your apps.  It will be listed as the Endpoint property of your bucket.  It should look something like this:

http://[bucket_name].s3-website-us-east-1.amazonaws.com

Configuring a bucket as a website

To reference your application, you would append your folder name to the URL above like this:

http://[bucket_name].s3-website-us-east-1.amazonaws.com/[folder_name]

If you set up your index document correctly (in step 2a, above), then a URL like this would be what you’d provide as a link to your application.  To deploy additional apps, just repeat steps 3 & 4 as needed creating a new folder for each set of application files.

Making friendlier URLs

So now you know an easy way to deploy and share web apps; however, the default URLs of these apps, as you have seen above, are a bit cumbersome.  The creation of a CNAME is something that you can do to make your app URLs friendlier and easier to remember.  A CNAME is essentially an alias that translates Amazon’s default domain URL into a URL from your domain.  For example, if your domain is www.esri.com you might want to use myapps.esri.com for your apps.

If you plan to use a CNAME, Amazon recommends creating a bucket with the same name as your host name.  See Amazon’s documentation for associating a host name with an Amazon S3 bucket using CNAME for more information.

In many organizations, you may simply be able to request a CNAME from your helpdesk or web administrator.  You’d just provide your bucket name and your desired host name and they’d configure the DNS for you.  Otherwise, you may have to configure this yourself using your DNS provider.  If you don’t have a DNS provider, Amazon offers a DNS service called Amazon Route 53 and has help for routing requests through Route 53 to S3.

Tips and best practices

Here are some more quick tips and best practices for deploying your mapping apps using Amazon S3:

Organize your apps – If you plan to deploy a lot of apps, consider organizing them into several buckets and implementing naming conventions for your buckets and folders.  This will make your app files easier to find and URLs easier to remember.  For example, you could group your apps in folders by department, project, or year.  You can use more than one level of folders to organize your apps.  Note that bucket names must be unique across all users of Amazon S3, so consider a good way to make yours unique like using your organization and/or department name or abbreviation.

Friendly GIS server names – In addition to setting up friendly URLs for your apps, as described above, you can also establish friendly names for your ArcGIS Server sites running in EC2.  Just set up a CNAME for the ArcGIS Server site’s elastic load balancer URL.

Use web maps – By referencing ArcGIS Online web maps in your apps (rather than building your map layer-by-layer with code) many types of changes will not require you to re-deploy new app files.  For example, if you need to change the pop-up definition, layer symbols, or layer names – or even if you need to add or remove a layer from the web map – you can make the change in the ArcGIS.com map viewer.  Otherwise the code and/or configuration files will need to be modified and then uploaded to Amazon S3.

The need for speed – If high performance is required, you can use Amazon’s CloudFront service in conjunction with S3 to accelerate the performance of your apps.  CloudFront is a content delivery service that provides low latency and high data transfer speeds.

Apps?  What apps? – There is a huge library of configurable app templates and custom app development tools available for you to use to bring your maps and spatial content to life on the web.  Examples of web apps that you might deploy range from configured or slightly modified versions of the ArcGIS Online app templates or storymap templates, Esri’s Atlas template, one of the many ArcGIS for Local Government app templates, configured versions of the ArcGIS Viewer for Flex or Silverlight, or even your own custom apps that you’ve build from scratch using one of the ArcGIS Web APIs.

Contributed by Owen Evans, Esri solution engineer

This entry was posted in Services, Web and tagged , , , , , . Bookmark the permalink.

Leave a Reply

2 Comments

  1. davidsavvy says:

    Owen,
    Thanks for the informative article. I am currently investigating the use of EC2 for my ArcGIS for Server deployment. It seems the advantages of using S3 are purely administrative. Or, are there perfomance for cost advantages as well?

  2. oevans says:

    Hi David — Yes, if you were deploying apps on your GIS server EC2 instance, then the benefit is mostly administrative since you will have to pay ever so slightly more to use S3 + EC2 as opposed to just EC2. However, if you were using a dedicated EC2 instance as a web server, then S3 will be more cost effective.

    As far as performance goes, the client’s browser downloads the app files when the app is first accessed, but after that all the code runs on the client and all the requests go to the GIS server, so the only load S3 gets is that initial download. For typical apps (say, a few hundred kB or even a few MB) that get light/medium use you’re not likely to see a significant effect using S3, but if you had lots of different users hitting your app(s) and your app files were large you could get a performance/capacity benefit from moving that load off the GIS/web server to S3. That’s also a situation where you might consider using CloudFront as well.