I am writing an application that will only have around 10k - 100k requests per 24 hours. The application requires maintaining many maps, which totally will be about 3-4GB in size. These maps will be concurrently read and also written to, which through my own testing I believe I've handled just fine using SpringBoot, ConcurrentHashMap, and @RestController/@Service etc etc.

My question is, have I "done something wrong" by not using DynamoDb in this scenario? I will summarize some of my feelings about the pros and cons below:

Data Size

I can imagine that if I had TBs of data, DynamoDB would be a compelling choice here because such a large amount of data cannot fit comfortably into RAM without paying quite the price :) But 3-4GB of data can fit quite cheaply into an EC2 instance's RAM, and I'm not planning to have 100s of EC2 instances.

Performance

Not sure what could possibly be faster than an in-process ConcurrentHashMap for a REST application? Even if DynamoDB does in fact deliver millisecond latency, you still are making a network call.

Complexity

While the AWS SDK is a very common dependency to need anyway, and the DynamoDB API is quite friendly, the fact remains that there is a bit more complexity added to your application when using it compared to just a ConcurrentHashMap

Cost

This seems to me to be the principal reason for me to not use DynamoDb in my case. With a few EC2 instances running 24/7 with all of the data loaded into memory, I can have the best possible performance and least complex deployment process for a few hundred dollars per year? I am confident that these few EC2 instances can handle the read/write traffic I described above. And even if they couldn't, DynamoDB's capacity units also get very cost prohibitive as well very quickly.

EDIT: I should have mentioned that these maps are essentially configuration files and not anything that needs serious consistency/persistence guarantees like customer data or etc.