aws-samples / amazon-rds-proxy-multitenant-load-test Goto Github PK

Following error is present in Set Version step. I am not really sure why is it there.

Using exactly same Release code in the link bellow and no issues there.
https://github.com/aws-samples/aws-content-creation-render-environment-for-windows/runs/1972395445?check_suite_focus=true

The environment variable here Is causing the issue and 100% of connection is getting dropped. The logs show error

Database connection failed due to 1045 (28000): Access denied for user 'user117'@'%' (using password: NO)

The working solutions is to remove ${DbClusterResourceId} and replace it with * which essentially give access to any cluster/database instance in the account.

The Access denied error only appears when connecting to database with Proxy in front of it. The No Proxy cluster access is fine and working as expected.

This is as much a question / clarification than anything, but as somebody looking to build a multi-tenant RDS Proxy solution with AWS, this example is a bit misleading in that it doesn't really call out the limitation with this approach, mainly that this solution would remove any existing RDS Proxy secrets that may have existed prior to the creation of the new secrets / users.

In my mind, this would be a viable solution for a small number of relatively static tenants, but for something like a SaaS that might scale out to hundreds (or even more) of users, dynamically creating users in the way demonstrated in this example doesn't seem tenable. Of course an API call could be made to fetch the existing secrets associated with the proxy, then append a list of additional secrets, but I imagine most people building out a multi-tenant system would be interested in scaling this past a handful of secrets.

I'm interested to know if this pattern does indeed scale (i.e. the pseudo logic mentioned above of fetching the proxy config to get existing secrets, appending any new secret(s), then updating with the complete list) or would be supported by RDS Proxy, or if this approach is really only workable for a small, relatively static set of tenants?