As more companies move to the cloud, and utility companies are taking a leap towards the Esri Utility Network (UN), we explored whether you could deploy the UN in an Amazon Web Services (AWS) database-as-a-service with Aurora PostgreSQL.

PostgreSQL is a quick and efficient software for standing up an ArcGIS Enterprise Geodatabase and is commonly installed on on-premises servers.  However, AWS is offering PostgreSQL databases, as a cloud service, making it even easier for companies to attain the ArcGIS Enterprise Geodatabase level of infrastructure.  But can this database-as-a-service be configured for the Esri Utility Network?

PostgreSQL supports different geometry types: PostGIS and ST_Geometry.  Esri’s standard deployment instructions for PostgreSQL on-premises servers is to configure ST_Geometry, which requires access to the operating system on which PostgreSQL is installed.  PostgreSQL in AWS Aurora is a database-as-a-service and the user does not have access to the operating system, therefore cannot configure ST_Geometry.  Going forward we now know AWS Aurora only supports PostGIS geometry and the two cannot be interchanged.   In other words, if you are working with a client or contractor, you cannot share a PostgreSQL backup between an ST_Geometry and PostGIS configuration.  Why this is important, is when performing a UN migration, whether a Proof of Concept (POC), Pilot or Production migration, when building the UN geodatabase, we sometimes do this internally in the SSP on-premise environment, and provide a database backup for the client to restore. At SSP we had not completed or had heard of the full UN data structure being implemented in the cloud with PostGIS geometry, so we tried it.

We started by provisioning an AWS account and an Aurora PostgreSQL database via a web browser.  We chose to use a virtual desktop with ArcGIS Pro on our own internal network instead of also provisioning this through AWS.  We used the sample UN data Esri provides from Naperville, IL and staged the UN schema, applied the asset package, enabled the topology, and published a feature service.  And while we were successful in these actions there are a few lessons learned to share.

The decision to use a local virtual desktop and not an AWS desktop on the same network as the database was the first lesson learned.  The processing time to apply the Asset Package containing the small Naperville dataset was not practical for a real-world scenario.  Going forward, to reduce the latency consider a desktop/ArcGIS Pro installation on the same AWS network where the database has been provisioned.  Additionally, we found that using an install of ArcGIS Pro on a non-persistent desktop such as Amazon Appstream 2.0, in conjunction with security restrictions, meant that a large dataset being applied to the UN was almost impossible since the processing time exceeded the timeout on these desktops. This can be configured in the console by administrators. The maximum session duration is 5760 (96 hours), but company security may reduce that considerably.

The second lessons learned when using an AWS desktop for ArcGIS Pro, was the Utility Network Tools (aka untools) needing to be installed. Any dependencies such as licenses, (including Utility Network, ArcGIS Pipeline Reference (APR) and others), and python packages such as untools must be installed by an administrator, before creating the image to be deployed.

The benefit of moving to the cloud is the reduction in overhead and administration of servers required when they are on-premises.  The ability to stand up this environment quickly, also lends itself to a smoother transition to the UN.  At SSP we have confirmed this AWS PostgreSQL environment will support the UN using PostGIS geometry with these couple caveats.