Recently I came across this issue where the database team reported that while trying to restore the Oracle RDS database they are getting an EC2 related permission issue. To my surprise, they also said earlier they had the required permission and this is the first time they came across any such error however I was sure nothing changed from the permissions side.
Just to re-validate, checked for the associated IAM policy and found they have AWS RDSFullAccess policy assigned so logically should be able to restore the RDS database without any issue.
As a second troubleshooting step, I checked CloudTrail logs for any restore failed events without luck then tried to replicate the issue in my test account however didn't encounter any error.
Just to re-validate, checked for the associated IAM policy and found they have AWS RDSFullAccess policy assigned so logically should be able to restore the RDS database without any issue.
As a second troubleshooting step, I checked CloudTrail logs for any restore failed events without luck then tried to replicate the issue in my test account however didn't encounter any error.
At this point thought to give a deeper look at CloudTrail logs and checked for all the events during the period (when tried to restore the RDS database), interestingly there were a few CreateSecurityGroup related events.
And when checked further,
Now it was clear that while trying to restore the RDS database, they were selected to create a new security group instead of the desired option "Choose existing Security Group" option.
Post figuring this out, it was easy to make the database team understand that regardless of database vendor the core platform concepts would remain the same.
Some of you might think that why I didn't check CloudTrail logs even before trying to replicate the issue in the test environment and the reason is opinions from others and the name Oracle (now read the above paragraph again 😉).
That's it... 😊
No comments:
Post a Comment