Add a data source for Aurora DB cluster endpoints

[tabacco]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

AWS provides an API endpoint for describing Aurora cluster endpoints, DescribeDBClusterEndpoints, and it would be great to have support for that in a data source.

Aurora doesn't always provide an Endpoint field in the response to DescribeDBClusters. For example, if the cluster is secondary in a global database cluster, it'll only have a ReaderEndpoint, even though the cluster technically has a (nonfunctional) writer endpoint.

I'm not sure what the most "correct" way to implement this is. I think normally you'd have one source that provides a list of IDs, and another that provides a single record. In this case, though, a cluster will always have one single result when EndpointType is READER or WRITER, but may have multiple results for CUSTOM, and there's no single unified ID except the Endpoint value itself.

For example, here's a result for a cluster with the standard READER/WRITER endpoints, and one custom READER. Only the custom one has an arn and DBClusterEndpointIdentifier.

{
    "DBClusterEndpoints": [
        {
            "DBClusterEndpointIdentifier": "test-ro-endpoint",
            "DBClusterIdentifier": "test-db",
            "DBClusterEndpointResourceIdentifier": "cluster-endpoint-ABCDEFGHIJKLMNOPQRSTUVWXYZ12345",
            "Endpoint": "test-ro-endpoint.cluster-custom-abcdefg12345.us-west-2.rds.amazonaws.com",
            "Status": "creating",
            "EndpointType": "CUSTOM",
            "CustomEndpointType": "READER",
            "StaticMembers": [],
            "ExcludedMembers": [],
            "DBClusterEndpointArn": "arn:aws:rds:us-west-2:000000000000:cluster-endpoint:test-ro-endpoint"
        },
        {
            "DBClusterIdentifier": "test-db",
            "Endpoint": "test-db.cluster-abcdefg12345.us-west-2.rds.amazonaws.com",
            "Status": "available",
            "EndpointType": "WRITER"
        },
        {
            "DBClusterIdentifier": "test-db",
            "Endpoint": "test-db.cluster-ro-abcdefg12345.us-west-2.rds.amazonaws.com",
            "Status": "available",
            "EndpointType": "READER"
        }
    ]
}

New or Affected Resource(s)

• New Data Source: aws_rds_cluster_endpoints

Potential Terraform Configuration

data "aws_rds_cluster_endpoints" {
    cluster_identifier = "cool-cluster"
    endpoint_type = "WRITER"
}

References

• DescribeDBClusterEndpoints API

[github-actions[bot]]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[Bill-HP-Cassidy]

Our AWS clusters frequently change writer instances. Sometimes it is an automatic fail-over performed by AWS itself. More often, we do modifications, fixes or upgrade by: 1) Make a new reader 2) Failover to it

This method avoids any interruption in service. But, it means that the name of the writer instance changes pretty frequently.

It would make maintenance of our clusters more automated and easier to maintain if I could get the name of the writer instance for the cluster from a some attribute of the cluster. Making the entire output of DescribeDBClusters for the cluster would be one way of supplying the name of the writer instance.

[github-actions[bot]]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!