aws-apigateway: RegionalCertificateArn is not supported for PRIVATE custom domain name

[successkrisz]

Describe the bug

When trying to use a custom domain for a private API gateway, using a public hosted zone + acm certificate, CDK fails with the following error message:

CREATE_FAILED        | AWS::ApiGateway::DomainName      | PrivateApiGateway/PrivateApi/CustomDomain (PrivateApiGatewayPrivateApiCustomDomainDEF6FEC5) Resource handler returned message: "Invalid request provided: RegionalCertificateArn is not supported for PRIVATE custom domain name. (Service: ApiGateway, Status Code: 400, Request ID: 397a2f2f-1442-468f-939d-b7a770000000)" (RequestToken: cdd58010-f394-96ac-234d-cfffe0000000, HandlerErrorCode: InvalidRequest)

The very same thing I can set up using the AWS Console when following this guide: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-custom-domains-tutorial.html

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

Based on the documentation here: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-custom-domains-tutorial.html, I'd expect to be able to:

• Use a public hosted zone & acm certificate covering the domain I'd like to use
• Create a private API Gateway RestApi with:

import * as cdk from 'aws-cdk-lib'
// ...
new apigateway.RestApi(this, 'PrivateApi', {
   ...otherApiProps,
   domainName: {
     domainName:'foo.example.com',
     certificate,
     endpointType: apigateway.EndpointType.PRIVATE,
   },
})

Current Behavior

When it gets to the stage where the domain name is created it always fail creation with the following error

private-api | 0/5 | 09:08:39 | CREATE_FAILED | AWS::ApiGateway::DomainName | PrivateApiGateway2/DomainName (PrivateApiGateway2DomainName89C927F5) Resource handler returned message: "Invalid request provided: RegionalCertificateArn is not supported for PRIVATE custom domain name. (Service: ApiGateway, Status Code: 400, Request ID: 151b2d57-b415-489f-baed-db0a606921ea)" (RequestToken: 0c796725-c410-88ff-d0d5-a449e4731ea4, HandlerErrorCode: InvalidRequest)

Reproduction Steps

As it fails on the step for the DomainName creation step it can be reproduced by:

import * as cdk from 'aws-cdk-lib'
import * as apigateway from 'aws-cdk-lib/aws-apigateway'
import { Construct } from 'constructs'

export class PrivateApiGateway extends Construct {
  constructor(scope: BaseStack, id: string, props: PrivateApiGatewayProps) {
    super(scope, id)
    const hostedZone = cdk.aws_route53.HostedZone.fromLookup(this, 'HostedZone', { domainName: 'example.com' })
    const certificate = cdk.aws_certificatemanager.Certificate.fromCertificateArn(
            this,
            'Certificate',
            process.env.CERTIFICATE_ARN,
        )
    const domainName = new apigateway.DomainName(this, 'DomainName', { // <= this step fails
            domainName: 'api.example.com',
            certificate,
            endpointType: apigateway.EndpointType.PRIVATE,
    })
  })
}

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.173.1 (build 4eac959)

Framework Version

No response

Node.js Version

22.11.0

OS

MacOS

Language

TypeScript

Language Version

5.7.2

Other information

No response

[khushail]

@successkrisz , thanks for reaching out. could you please share the synthesized template output generated after cdk synth step ?

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[dviryamin]

It seems that the logic determining whether to use CertificateArn or RegionalCertificateArn in CfnDomainName does not account for the possibility of a PrivateEndpoint with a custom domain name, likely because this is a new feature. Unfortunately, I couldn’t get it to work in my tests. If possible, I kindly ask the maintainers to revisit this issue, as it might impact others trying to use this configuration. I hope to explore this further in the coming weeks if time allows.