RDS vs DynamoDB - Compliance, security and other considerations.

Hi,

These ones may help you in establishing a list of pros and cons:

• https://dev.to/napicella/dynamodb-or-aurora-rds-should-we-always-use-dynamodb-51d5
• https://www.geeksforgeeks.org/difference-between-amazon-aurora-and-amazon-dynamodb/
• https://medium.com/@abylead/aws-database-overview-rds-vs-aurora-vs-redshift-vs-dynamodb-7eeebb61ca98

The best choice is always really dependent on your use case. So, the best it to appreciate the pros and the cons that you read in the context of your project: you must weigh them in your specific context.

Best,

Didier

DynamoDB is secure enough, and you can use it. You have encryption (at rest and in transit). You can also use VPC endpoint to send traffic to DynamoDB via the internal network

https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html

Authentication is managed by IAM.

Just keep in mind that this is vendor lock

I suggest you also consider the likely counterarguments from the proponents of using Aurora PostgreSQL over DynamoDB.

DynamoDB is a multi-tenant service with APIs open to the public internet. Even if your workloads access it securely within AWS and using a VPC gateway endpoint (a type of PrivateLink connection), your DynamoDB tables will still be fully accessible from anywhere on the public internet, with only authentication and potential authorisation rules (including indirectly by restricting access to the KMS keys with which your table's data keys are encrypted) that you set up to limit access.

By contrast, an RDS/Aurora database resides in the VPC where you created it. Unless you configure an internet-exposed interface for the RDS database (with the "publicly accessible" option), then in addition to the authentication and authorisation to the database and the tables it contains, any outsider would additionally need access to the VPC even to attempt to connect to the RDS/Aurora database. Inside the VPC, security groups and NACLs could be used to restrict access even further.

Generally speaking, it's entirely possible that an auditor would be concerned about the data being possible to access from any location on the public internet.

However, you can also configure network perimeter protections for a DynamoDB table. It just doesn't happen by itself the way it appears to do with an RDS/Aurora database placed inside a VPC. With DynamoDB, you can attach an identity-based IAM policy to the principals in your account, and/or a resource-based policy to your DynamoDB table to limit certain or all principals to accessing it only from authorised VPCs (when passing through a VPC endpoint/PrivateLink connection) or IP addresses (when accessing from the public internet, such as for human users to access it via the management console, unless the console is also accessed via a VPC endpoint).

You can restrict access to the DynamoDB table with policy statements that inspect request context condition keys indicating the network origin of the request, such as aws:SourceVpc (indicates the VPC ID that owns the endpoint/PrivateLink connection) and aws:SourceIp (the source IP when the request is received over the public internet). It's useful to set the rules carefully, because they can lock you out of your table just as effectively as they can outsider.

The condition keys for filtering by network origin are in this section of documentation for IAM: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip

There's also a blog post series about different ways of controlling access to AWS resources with policies. Of that series, this part discusses network-based restrictions, along with practical examples: https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-access-to-company-data-only-from-expected-networks/