I’ve inherited an API that uses ddb. Unfortunately, everything is being done on one production table. I am in the process of completing a development setup, so we don’t have to experiment on the production database. As it turns out, the new data is much cleaner and our client wants to use it instead. I figured, I could simply update the Resource block of our ddb config to point to the new ddb table resource arn but that’s when I ran into trouble.
Part of the config looks like this:
...
iamRoleStatements:
- Effect: Allow
Action:
- dynamodb:DescribeTable
- dynamodb:Query
- dynamodb:Scan
- dynamodb:GetItem
- dynamodb:PutItem
- dynamodb:UpdateItem
- dynamodb:DeleteItem
Resource:
- "arn:aws:dynamodb:us-east-1:*:table/${self:provider.environment.PROD_TABLE}"
At first, I simply updated the Resource block to the value below and deployed
- "arn:aws:dynamodb:us-east-1:*:table/${self:provider.environment.DEV_TABLE}"
After the deploy I received this (redacted) error in CloudWatch:
AccessDeniedException: User: arn:aws:sts::<redacted>:assumed-role/... is not authorized to perform: dynamodb:DescribeTable on resource: arn:aws:dynamodb:us-east-1<redacted>/PROD_TABLE
Note, the arn:aws:dynamodb resource (above) is referencing the old database
A re-deploy does not update the resource for the newly created assumed (lambda) role. I am not sure how to make this happen without a “remove” and “deploy.”
Forgoing an exact solution is there an easier way to switch over to a different ddb without causing any major disruption to our users?