AWS S3 vs. DynamoDB for Config Store

[RyanUthoff]

I've seen various posts and documentation about how you can use either S3 or DynamoDB as the config store for ArcGIS Server in AWS. I've seen Esri documentation that uses DynamoDB as the config store (DynamoDB Config Store). And then I've seen Esri blog posts that uses S3 as the config store (S3 Config Store)

What I haven't been able to find any documentation on though is which one is better to use? Or if there are any special considerations we need to think about when choosing one or the other?  Does one have any better performance than the other?

[ShanonLoughton]

I would not worry about it.
From what I understand, ArcGIS Server > Config Store data does not change that much. It does not take up much room either - a default deployment is barely a few MB, as it's just a few parameters and values/JSON data. So just need something it can read from every now and then, especially on ArcGIS Server service startup. DynamoDB is probably fastest for this, but I cant categorically say.

Performance-wise, the most sensitive deployment configuration decision actually is the ArcGIS Server > Server Directories (cache, jobs, output, system) location. That little legacy config gremlin must be on something that is high IOPS and near to the server as it is very chatty and constantly reading and potentially writing, so cannot have file or write locks preventing access anywhere on it - something S3 and helper middleware is prone to. It must be on a local disk (on AWS, that's a SSD-class EBS disk attached to the server) or on a fast Windows network file server for Windows deployments. For Linux I think you can connect directly to EFS but I am unsure of its performance, compared to a local disk .

Also, see discussion here:
https://community.esri.com/t5/arcgis-enterprise-in-the-cloud/why-do-we-use-dynamodb-for-server-confi...

[RyanUthoff]

Okay, that makes sense. I did previously see the discussion you posted, but it was talking about FSx vs. DynamoDB. If S3 can be used, I'd prefer to use that as opposed to DynamoDB, just for simplicity.

I didn't realize the server directories were the most sensitive. So, for a multi-machine deployment of ArcGIS Server, I'd create a single EBS volume that I'd attach to both ArcGIS Server machines and configure them to use that EBS as the server directory. That makes sense.

Although, now I'm curious. Is there a reason why we couldn't use the EBS volume as the config store as well?

Thank you!

[ShanonLoughton]

Attaching EBS volume to multiple instances might work. Historically EBS is only 1 to 1 with EC2 instances/VMs. Only certain high IOPS EBS volume types io1/io2 are supported for multi-attachment, prob only in certain regions too, and really designed for Linux if you are deploying in that OS. Windows is supported too although it looks like in a 'dumb' way according to the doco, so could be quite risky. I doubt this would ever be supported/recommended. 
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

If the above works, ArcGIS Server > Config Store could probably go there too. As would anything else like imagery or registered FGDBs.

The EBS io2 pricing equation may also do your head in:
https://aws.amazon.com/ebs/pricing/ > scroll to EBS Provisioned IOPS SSD io2 Volumes. I would pencil 5x - 10x the price of gp2. Your target IOPS is 5000, I am unsure if this needs to be minimum, or max/burst.

Whilst not appearing as an SMB protocol config to a Windows deployment, the above arrangement would still need to ensure the equivalent of no oplocks / no caching / no large-files-enabled etc.:

https://community.esri.com/t5/arcgis-enterprise-in-the-cloud/why-do-we-use-dynamodb-for-server-confi...

[JonathanQuinn]

Those storage options are actually for different things; S3 is for the content directory for Portal for ArcGIS, while DynamoDB is for the config-store for ArcGIS Server. You can't use S3 for the config-store for Server, and similarly you can't use DynamoDB for the content directory.

So there's no "better" option; the question is rather do you want cloud storage for each component or not.