(aws-rds): Add a construct to associate roles with RDS instance

[paya-cz]

Describe the feature

I import an RDS instance into my CDK stack via rds.DatabaseInstance.fromLookup, and I want to add a role to it for the S3_INTEGRATION feature, so the RDS can upload files to S3. There is currently no built-in way to achieve this.

Use Case

We run nightly data exports in Oracle RDS. The exports generate a file in a directory. We need to move this file to S3 for further processing. To upload from RDS to S3, a feature role must be added. This is currently extremely difficult to achieve through CDK when the RDS has been imported into the stack.

Proposed Solution

No response

Other Information

I have tried to implement this using AwsCustomResource but I got stuck on something that I would describe as "permission race condition". Take a look at the code first:

import * as iam from 'aws-cdk-lib/aws-iam';
import * as logs from 'aws-cdk-lib/aws-logs';
import * as rds from 'aws-cdk-lib/aws-rds';
import * as custom from 'aws-cdk-lib/custom-resources';
import { Construct } from 'constructs';

export interface AwsRdsInstanceRoleAssociationProps {
    /**
     * RDS database instance.
     */
    rdsInstance: rds.IDatabaseInstance;
    /**
     * Feature name, supported by the DB engine. The supported features vary by DB engine and DB engine version.
     * 
     * @see https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DBEngineVersion.html
     * @see https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html
     * @example S3_INTEGRATION
     */
    featureName: string;
    /**
     * Role to associate with the RDS database instance.
     */
    role: iam.IRole;
}

export class AwsRdsInstanceRoleAssociation extends Construct {
    constructor(scope: Construct, id: string, props: AwsRdsInstanceRoleAssociationProps) {
        super(scope, id);

        const dbInstanceIdentifier = props.rdsInstance.instanceIdentifier;
        const featureName = props.featureName;
        const roleArn = props.role.roleArn;

        new custom.AwsCustomResource(this, 'Association', {
            onCreate: {
                service: '@aws-sdk/client-rds',
                action: 'AddRoleToDBInstanceCommand',
                parameters: {
                    DBInstanceIdentifier: dbInstanceIdentifier,
                    FeatureName: featureName,
                    RoleArn: roleArn,
                },
                physicalResourceId: custom.PhysicalResourceId.of(`rds-instance-role-association/${dbInstanceIdentifier}/${featureName}/${roleArn}`),
            },
            onUpdate: {
                service: '@aws-sdk/client-rds',
                action: 'AddRoleToDBInstanceCommand',
                parameters: {
                    DBInstanceIdentifier: dbInstanceIdentifier,
                    FeatureName: featureName,
                    RoleArn: roleArn,
                },
                physicalResourceId: custom.PhysicalResourceId.of(`rds-instance-role-association/${dbInstanceIdentifier}/${featureName}/${roleArn}`),
            },
            onDelete: {
                service: '@aws-sdk/client-rds',
                action: 'RemoveRoleFromDBInstanceCommand',
                parameters: {
                    DBInstanceIdentifier: dbInstanceIdentifier,
                    FeatureName: featureName,
                    RoleArn: roleArn,
                },
                physicalResourceId: custom.PhysicalResourceId.of(`rds-instance-role-association/${dbInstanceIdentifier}/${featureName}/${roleArn}`),
            },
            policy: custom.AwsCustomResourcePolicy.fromStatements([
                new iam.PolicyStatement({
                    effect: iam.Effect.ALLOW,
                    actions: ['iam:PassRole'],
                    resources: [props.role.roleArn],
                }),
                new iam.PolicyStatement({
                    effect: iam.Effect.ALLOW,
                    actions: ['rds:AddRoleToDBInstance', 'rds:RemoveRoleFromDBInstance'],
                    resources: [props.rdsInstance.instanceArn],
                }),
            ]),
            logRetention: logs.RetentionDays.ONE_MONTH,
        });
    }
}

This works just fine when I create or destroy the custom resource. But the issue is with updates. Let's say I change the role passed into the construct, thus the role ARN changes. This causes the PolicyStatement to update first, and then the onUpdate action is executed. The onUpdate succeeds and returns a new physical ID, so the framework then calls onDelete for the old resource. However, the onDelete fails, because the policy has been changed and no longer contains the permissions to execute the onDelete action for the old resource. Hence why I called this a "permission race condition".

I do not see an obvious way how to work around this issue. Any help would be appreciated if there is a neat trick to make this work, before a proper built-in construct is added for this.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS CDK Library version (aws-cdk-lib)

[email protected]

AWS CDK CLI version

2.1024.0 (build 8be6aad)

Environment details (OS name and version, etc.)

Win11 Arm64

[paya-cz]

Another problem I noticed when using the custom.AwsCustomResource is that the RDS instance must be in the Available state, otherwise the request will fail. When a role is added/removed, it doesn't happen immediately, but it takes a few seconds and the instance is set to Modifying state for a short period of time. So, if the new role is added and the old role is removed almost immediately afterwards, the removal might fail because the RDS might still be in the Modifying state. There needs to be some kind of mechanism that waits for the state to be back to Available before attempting to add/remove the role. This is again not possible to achieve with custom.AwsCustomResource.

[pahud]

Hi,

When you use fromXxxx() method to lookup or reference a resource, you essentially create a pointer or reference to that resource which is not actually created or managed by CDK so CDK can't update it or attach a role to it unless this resource is created by CDK.

Your Implementation Issues

The problems you've encountered with AwsCustomResource are well-documented challenges:

1. Permission race condition: The policy updates before the custom resource actions, causing the old role removal to fail
2. RDS state management: Role operations require the instance to be in Available state

Proposed Solution

Create a new CustomResource like DatabaseInstanceRoleAssociationwhich would:

• Handle RDS instance state checking (wait for Available status)
• Manage permissions correctly to avoid race conditions
• Support the full lifecycle (create/update/delete) of role associations
• Work with both newly created and imported instances

Implementation Approach

The construct would internally use the AWS APIs:

• AddRoleToDBInstance
• RemoveRoleFromDBInstance

With proper error handling and state management that AwsCustomResource alone cannot provide.

This is technically possible, but you'll need to write a CustomResource like that.