A city's AWS Backup job cannot snapshot an RDS database. The IAM role AWS Backup uses to take RDS snapshots was never created. What should the operator do?
Select an answer to reveal the explanation.
Short Explanation
A backup that cannot borrow the warehouse key cannot photograph the inventory, however full the shelves are. You create the AWS Backup default service role and pass it to the backup plan or job so AWS Backup can call the RDS snapshot APIs. Opening the database port or moving the instance to a public subnet does not create that role.
Full Explanation
AWS Backup needs a service role that it assumes to create, tag and delete backups of the resources you protect. For a backup plan or on-demand job you pass that role, and AWS's guidance is to choose the default service role, AWSBackupDefaultServiceRole, which carries the AWSBackupServiceRolePolicyForBackup managed policy. The console can create it for you the first time you assign resources or start an on-demand backup, and in the CLI you must create it yourself. When the role does not exist, the job fails before any snapshot exists, so you create it and select it for the backup. A backup vault does not open a client connection to the database port and copy tables, so a security group change does not help. Encryption is unrelated to a missing role, and turning it off does not create an identity AWS Backup can assume. Snapshot creation is an API call in the Region, not a connection to the instance endpoint, so a public subnet does not supply the missing role. The database can stay private and encrypted. Caveat: with a customer managed KMS key the role also needs permission to use that key. Operational check: after the role exists, start an on-demand backup of this database and confirm the job records a recovery point.