Resources for Cloud GIS

[mpboyle]

We are starting to look at what it would take to move our entire GIS infrastructure to the cloud.  This would include our enterprise geodatabases and Enterprise deployment. 

I'm not terribly concerned about the Enterprise deployment part of the move.  The portion that I'm really interested to hear peoples thoughts/ideas/experiences on is the actual data migration/setup/configuration/performance.

There are several logistical questions we have in order to fully understand what it would take on our end to provide our users with their familiar desktop setups if our enterprise databases were in the cloud.

1. Is there a preferred/recommended cloud environment between Azure and AWS.  Are there any glaring reasons to use one over the other?
2. If our data is in the cloud, how would users make direct connections to the geodatabase for adding datasets to Pro? ... are you able to connect to a database via an IP address? ... do feature services become more important?
3. If our data is in the cloud, are you able to use OS authentication to make a direct connection to the geodatabase or does it require a named user in the database?
4. Is there a performance hit when connecting to a cloud geodatabase?
5. Is it recommended to use remote/cloud desktops to connect to a cloud geodatabase to improve performance?

I'm sure there are many things I've overlooked, we are mainly interested in getting our heads wrapped around the logistics of a move to the cloud.

Any thoughts/ideas/suggestions are welcome!

[ReeseFacendini]

If snapshots / backups at the cloud level are a need, AWS will provide those for you where Azure doesn't have a way to do that.  If you are storing data in a cloud database, you will want to have cloud desktop / jump machines otherwise the performance of reading / editing data will be degraded.  Our desktop software connects to databases over IPs or machine hostnames, and if you have a domain setup in the cloud you can use OS auth from the desktop / jump machines.

[mpboyle]

A few follow-up questions (apologies in advance since we're new to this):

1. Are you able to install Sql Server on AWS --- if so, are we responsible for the install and upgrade of Sql Server?
2. Is there a certain recommended tier family for AWS when running Enterprise vs. desktops?
3. Is each component a separate instance on AWS, or are you running multiple desktops from one instance?
4. What is the recommended approach for migrating data to the cloud? --- backup/restore, detach/attach, file geodatabase, something else...?
5. How is active directory managed in AWS to allow users to use OS authentication?
6. I'm assuming we're responsible for anything installed in AWS in terms of updating --- what are we NOT responsible for updating?

Again, thanks for any response.  Does Esri have any videos/docs detailing install/setup/config in the cloud?

[ReeseFacendini]

No worries, moving to cloud is not a small task!

1. You can install SQL Server on an AWS machine, but yes you will then be responsible for maintaining that system as if it was on-premise.  AWS offers a cloud RDS solution, where you are only responsible for maintaining your data and Amazon handles everything else.
2. The m5 family is a good place to start for Enterprise, because of resource reliability and it allows for higher network traffic.  Desktops can be setup in AWS WorkSpaces, which allows better flexilbility when needing to have multiple users connect at once.
3. A production level Enterprise should be distributed and each component (not necessarily web adaptors) on a separate machine
4. If you are migrating to an instance of SQL Server that you installed on a dedicated VM, backup/restore would be the easiest way.  I believe that AWS has tools available to migrate data to its managed RDS system, but I can't speak to the ease of that.
5. AWS utilizes the same tools that Microsoft does for managing AD (https://aws.amazon.com/directoryservice/), but I can't speak to how to configure it specifically.  Once setup, it should function as a "normal" AD and allow for OS auth to systems and services.
6. Any VMs that are created, you are responsible for maintaining in terms of updates to the actual machines and the software installed on them.  In that regard it's no different then being on-prem.  AWS provides the tools, but expects the customer to maintain things in accordance with their polices.
7. Here is the link to our AWS Cloud doc (https://enterprise.arcgis.com/en/server/latest/cloud/amazon/what-is-arcgis-server-on-aws.htm).  This will also link back to all our other cloud information 

[mpboyle]

I appreciate the help!

A few more follow-ups:

1. I'm still a little uncertain about how every piece communicates if deployed on AWS.  We currently have a distributed installation of Enterprise, with each component on a dedicated VM server.  Would we be looking at one EC2 machine with multiple VMs or one EC2 machine for each Enterprise component?
2. Along the same lines as above for desktop machines, is it one WorkSpace powering many desktops, or one WorkSpace per desktop?
3. Does AWS automatically handled OS updates/migrations, for example Windows Server 2016 to 2019 or is that on the user?

Thanks again!

[ReeseFacendini]

1. Each EC2 instance is a single VM, so you would have multiple EC2s to mirror the current deployment.
2. I am not super familiar with WorkSpaces, so I can't say how they operate and would recommend reaching out to AWS directly (or possibly a google search) to get more info.  Someone else in the community here may also have experience with it and might be able to offer more insight
3. Upgrades to the OS are handled by the user.  AWS simple provides the starting point and leaves all other aspects to the user

[YungKaiChin]

I could only speak from my experience with Azure.

For databases, avoid Azure Database. Instead, try Azure SQL Managed Instance.

Also, in our experience, avoid Enterprise Cloud Builder.