Simple configuration
This document explains the steps you could take to deploy ArcGIS Server on Amazon EC2 to support a public-facing Web application. The scope of the deployment is relatively small, such as would be required for a small government. Where appropriate, the steps link to more detailed help about how to accomplish each task.
Data and requirements for the application
In this scenario, your objective is to create a simple map viewer application like the one described in the ESRI white paper Best Practices for Creating a Web Mapping Application for Municipal/Local Government. It offers standard map navigation and query operations, address finding capabilities, and simple printing.
The data for the application is the same as described in the white paper. It covers a medium-sized city of about 300,000 people (Riverside, California). Because the amount of data is limited (12.5 GB), it is not stored in an enterprise ArcSDE geodatabase; rather, a file geodatabase is used. In the application, the data is organized into three map services: a vector basemap, a raster imagery basemap, and a utilities overlay map.
The application has the following requirements:
- Response times are expected to be less than 2 seconds for any operation.
- The application is expected to be online at any given time. However, 99.9% availability is not required.
There are no anticipated spikes in usage and no elasticity requirements for this application. Another scenario in this help book explains how the deployment could be scaled out to accommodate more users.
Overview of the Amazon strategy for this application
Your strategy for serving this application is to deploy it on a virtual machine in the Amazon cloud, or an EC2 instance. You create this EC2 instance using the ArcGIS Server Amazon Machine Image (AMI), which causes ArcGIS Server and the IIS Web server to be installed and preconfigured on the instance.
The first instance you create is for development purposes only and doesn't have to be very large. Remember, you pay based on the power of your machine. When you're just testing and developing your application and services, you don't need many CPUs or a huge amount of memory. As you prepare your application for deployment, you should move it through a series of development, staging, and production tiers, each time creating larger instances that more closely reflect the final computing power you need.
Before you do anything with your development EC2 instance, you need to adjust its security configuration to allow remote desktop sessions. Once you can connect to the instance, you upload data and create GIS services from that data. Your instance includes ArcGIS Server Manager and ArcCatalog so that you can easily create services and make adjustments to your data.
Once you've deployed the services, you can also add the Web application and ensure that the data, GIS server, and Web server tiers work together smoothly. Once you've verified that everything works, you create a custom AMI and redeploy it to a more powerful EC2 instance for performance testing. This is your staging instance.
After you assess the performance of your application on the staging EC2 instance, you again create a custom AMI and deploy it to a new, possibly larger, production instance. You configure your security user and role stores on this instance and disable remote desktop connections to the instance. You can also configure an Amazon Elastic IP, enabling you to quickly make available a replacement instance at the same Web address if your original instance is stopped or terminated for any reason. Once you've done these things, your instance is ready to be exposed to the world.
You've just read an overview of how you could deploy the Web application on Amazon. Now let's back up and look at each step in more detail.
Preparing to use ArcGIS Server on Amazon EC2
Creating an Amazon account, requesting access to the ArcGIS Server AMIs, and enabling remote desktop connections on a security group are some steps that you must take before you can begin using ArcGIS Server on Amazon EC2.
Creating an Amazon account
Before you can begin using ArcGIS Server on Amazon EC2, you must create an Amazon account. This account allows you access to administer your instances. It's also used for tracking and billing your usage of Amazon Web services. To create an account, visit the Amazon Web Services home page and follow the steps for signing in as a new user.
Requesting access to the ArcGIS Server AMIs
The ArcGIS Server AMIs are not publicly available; they need to be shared with you before you can use them. Once you've created an Amazon account, contact Esri Customer Service and provide them your account name and number (see Finding your Amazon account number). Customer Service will then share the ArcGIS Server AMIs with your account.
Enabling remote desktop and HTTP access for a security group
Another step you must take is enabling remote desktop access to your instances. By default, EC2 instances are completely locked down, meaning there is no traffic allowed through any port. You must open a port, typically 3389, for remote desktop usage through your IP address. You must also open a port for HTTP access so you can use the Services Directory. For steps on how to do this, see Opening an Amazon security group for ArcGIS Server. You can apply the steps to either the default group or to a different security group that you create.
Deploying your development instance
At this point, you're ready to launch your development EC2 instance. You will use this instance only for the purpose of uploading data, configuring your services, and ensuring that your application works. For this reason, your development instance should not be any larger than necessary for completing these simple configuration tasks. In our scenario, the smallest available instance type (named "Large [m1.large, 7.5 GB]") is sufficient for the development instance.
Creating the development instance from the ESRI-provided ArcGIS Server AMI
You create the development instance by finding the ESRI-provided ArcGIS Server AMI, then following a wizard that helps you launch the instance. Deploying instance from this AMI ensures that ArcGIS Server is installed and preconfigured. The instance runs on Windows Server 2008 and also includes ArcGIS Desktop, IIS, and a Welcome page that helps you get started.
Follow the instructions in Activating ArcGIS Server on Amazon EC2 if you need step-by-step guidance to launch the instance. As you make choices to complete the wizard, be sure to choose the Large instance type and select the security group for which you enabled remote desktop connections.
Logging into the instance
Once you see in the AWS Management Console that your EC2 instance is running, you can log into the instance using Windows Remote Desktop. You can find login instructions in the topic Administering your Amazon machine with Remote Desktop. If you can't establish the connection, check that
- Your machine is permitted to make remote desktop connections outside your organization's firewall. Ask your system administrator whether your organization limits remote access to external machines. He or she may need to elevate your privileges before you can connect to EC2 instances.
- You have allowed remote desktop connections from your IP range for the security group you are using for this EC2 instance. By default, all Amazon security groups are locked down until you specifically open ports for connections. See the previous section, Enabling remote desktop and HTTP access for a security group, if you need to review this.
When you start an EC2 instance, a configuration script runs that configures ArcGIS Server. The script may take a few minutes to complete. If you notice this script running at login, you should not interrupt it in any way. You should wait to use ArcGIS Server until the script has completed.
Getting your data onto Amazon
The next step is to move your GIS data to a place on the Amazon cloud that's accessible to your EC2 instance. There are a multitude of ways that you can transfer the data from your on-premise deployment to the cloud. Some of these are outlined in Strategies for data transfer to Amazon.
Besides choosing how to move the data, you also need to decide where to put it. A 100 GB EBS volume named GIS Data is automatically created and attached when you deploy the ArcGIS Server AMI. Another option is to deploy the enterprise geodatabase AMI, which comes with ArcSDE and PostgreSQL and can be synchronized with your on-premise geodatabase using ArcGIS Server geodata services.
In the case of the Riverside map, you need to move about 12.5 GB of data into the cloud. The preattached EBS volume is probably the best choice for this data. The relatively small size of the data and simple workflows do not justify the cost or effort of deploying the enterprise geodatabase AMI.
If resources are limited and you're sure you do not need 100 GB, you can optionally detach and delete the 100 GB EBS volume and attach a smaller one of the appropriate size. See Adding more disk space (EBS volumes) to your deployment to learn about creating and attaching EBS volumes.
Creating the GIS services
Once you upload your data to Amazon, you can create the GIS services that your applications will use. Services represent maps or other GIS resources that you configure in ArcGIS Desktop and expose to your intranet or the Internet using ArcGIS Server. For example, a map service represents an ArcMap document (MXD) or a map service definition (MSD) that you've published to ArcGIS Server. Clients can request map images from the map service or send a query to the server about some of the data contained in the map.
To learn more about the different types of services and how to publish them, see the ArcGIS Server Help beginning with the topic What types of services can you publish?. You typically use ArcGIS Server Manager or ArcCatalog to publish and administer services.
The Riverside scenario uses five services:
- Street map service for display
- Imagery map service for display
- Utilities map service for display
- Geocoding service for finding addresses
- Geometry service for simple buffering
You can create all these services on an EC2 instance in the same way that you would create them in an on-premise deployment of ArcGIS Server. The ArcGIS Server SOC account must have access to any item that you publish as a service. When you deploy the ArcGIS Server AMI, the SOC account is preconfigured with access to the GIS Data directory (D:\).
In the Riverside scenario, the street map and imagery basemap are cached for performance. If you have a cache already, you can choose to transfer it to Amazon EC2 or S3 along with your other data, but it's probably faster just to re-create the cache. All the geoprocessing tools for caching are included with ArcGIS Server on Amazon EC2, and a default cache directory is configured for you when you launch an instance from the ArcGIS Server AMI.
Configuring the Web application
Along with moving your data to the cloud, you also need to migrate your Web application to your EC2 instance. This involves doing the following things:
- Transferring the application to your EC2 instance and placing it in a virtual directory
- Updating any URLs in your code to point to the Web address of your EC2 instance
- Testing your application
There are other aspects of preparing your application for the cloud that you will complete as you move your EC2 deployment through the staging and production tiers. These include setting up an elastic IP address and configuring security. Since you are just configuring the development instance right now, your focus should be on ensuring that the application runs and that it successfully uses all the services you created on your EC2 instance.
Deploying your staging instance
Once you've ensured that your application is working correctly on your development instance, you're ready to move it to a more powerful staging instance for more testing and configuration. You don't want to have to recopy all the data and re-create your services manually on the staging server, so you'll create a custom AMI reflecting the work you've done so far. You'll then deploy this custom AMI to a new EC2 instance on a more powerful machine.
Creating a custom AMI
An AMI represents a machine image, or the state of a machine once it's completely configured for a certain need. You used the out-of-the-box ArcGIS Server AMI when you deployed your development instance. Now, you need to make a custom AMI and use it to deploy your staging instance. Creating a custom AMI allows you to preserve the data, services, and applications that you already configured on your development instance. You can deploy the custom AMI on a larger machine.
See Creating your own ArcGIS Server AMI to learn how to create a custom AMI. These steps also show you how to launch a new EC2 instance using your custom AMI. To more closely match the memory footprint of the machine listed in the aforementioned best practices white paper, choose Extra Large as the instance type this time.
Testing your staging instance
Once you create your staging EC2 instance, log in using Remote Desktop, the same way you did with the development instance. Verify that your GIS services and application appear as expected. Then you can delete your development instance so that you don't incur further charges for it.
The staging instance is the place to configure ArcGIS Server security if you plan to require authentication for your Web application or your GIS services. Security in ArcGIS Server works the same way in the cloud as it does outside the cloud: you need to configure a user and role stores, add members to these stores, and set the desired permissions for each role.
The staging instance is also very appropriate for load testing. Use your staging instance to understand whether your EC2 instance will be able to handle the expected number of concurrent users while yielding acceptable performance times. You may wish to purchase testing software that can put your application under an artificial load.
If testing reveals that your expected load cannot be handled without more computing power, you can choose to retest on a larger EC2 instance. If you have adjusted any setting on your machine since deploying the staging instance, create a new custom AMI and deploy your larger instance from the new AMI to make sure you get the changes.
Deploying your production instance
When you arrive at the desired size for your machine and have optionally configured security the way you want, create another custom AMI. You don't have to redeploy this AMI now if you like the state of your machine, but it will be useful if you need to restore your deployment in the future or if you want to add more EC2 instances later.
On your production instance, you'll need to tighten security and associate an Amazon Elastic IP on your machine.
Tightening security on your production instance
On your production instance, you can optionally enable SSL and any other encryption or security mechanism that you require for your deployment. You should adjust your Amazon EC2 security group to disable Remote Desktop connections to the instance.
Setting up an elastic IP for your machine
Amazon Elastic IP allows you to reserve an IP address for use with your Amazon EC2 deployments. You can associate this IP address with any of your EC2 instances. Client applications will connect to your application using the elastic IP address. If your EC2 instance experiences a failure or other problem, you can quickly associate your elastic IP with a new EC2 instance to minimize downtime.
See Creating an Elastic IP for instructions.
This scenario walked you through the process of setting up ArcGIS Server on Amazon EC2 to support a small government Web application. You learned how to create an EC2 instance, move your data to the cloud, and re-create your services and applications. You also observed how to resize your Amazon instances and move your deployment through development, staging, and production tiers, increasing security each time.