RDS service instances that fail to create are left in an orphaned state and can't be deleted

[ccostino]

When a user creates a new RDS service instance with cf create-service... but the command fails, the service instance can be left in an orphaned state with no actual service and the user is not able to delete the service instance to try again. For example, this is the error output we recently saw that caused this situation:

TIMESTAMP [APP/PROC/WEB/0] OUT InvalidParameterCombination RDS does not support creating a DB instance with the following combination: DBInstanceClass=db.m3.medium, Engine=postgres, EngineVersion=13.3, LicenseModel=postgresql-license. For supported combinations of instance class and database engine version, see the documentation. <nil>
TIMESTAMP [APP/PROC/WEB/0] OUT InvalidParameterCombination RDS does not support creating a DB instance with the following combination: DBInstanceClass=db.m3.medium, Engine=postgres, EngineVersion=13.3, LicenseModel=postgresql-license. For supported combinations of instance class and database engine version, see the documentation. 400
TIMESTAMP [APP/PROC/WEB/0] OUT [martini] Completed 400 Bad Request in 3.33056033s

We need to adjust the error handling in the createDB functions to make sure AWS API calls that result in 400s are handled and cleaned up properly.

Acceptance criteria:

• When a user runs cf create-service... and the command fails, it handles the API error gracefully and cleans things up properly so orphaned services aren't left over.

---

Security considerations:

• Fixing this helps prevent cruft from building up in the platform and helps our users with better error handling

Implementation sketch

• Fix/improve the error handling in the createDB functions where AWS API calls are made

[ccostino]

Noting here that at the time of opening this issue, I was unable to replicate this error myself. The database failed to create and no service instance was left in an orphaned state. The createDB method does have error handling for the AWS API call and seems to handle the failure properly, so I'm not exactly sure what happened with the customer report we originally received.