Using InterfaceVPCEndpoint is awkward for custom PrivateLink connections

• I’m submitting a …

  • 🪲 bug report
  • 🚀 feature request
  • 📚 construct library gap
  • ☎️ security issue or vulnerability => Please see policy
  • ❓ support request => Please see note at the top of this template.

• What is the current behavior?

Using InterfaceVPCEndpoint seems oriented toward creating endpoints for AWS-managed services. This makes it awkward to use for connecting to custom VPC Endpoint Services. Specifically:

1. The privateDNSEnabled: true default doesn’t work for custom VPC Endpoint services outside of AWS Marketplace. service com.amazonaws.vpce.us-west-2.vpce-svc-abc123 does not provide a private DNS name.

2. Getting the primary DNS name (i.e. the DNS entry that points to other AZs) is challenging. Something like this does not work:

this.baseLambdaFunction = new lambda.Function(this, 'Resource', {
    runtime: props.runtime,
    handler: props.handler,
    code: lambda.Code.asset(props.zipPath),
    vpc: props.vpc,
    environment: {
        MY_SERVICE_HOST: vpcEndpoint.vpcDNSEntries[0] // => "#{Token[TOKEN.24]}"
    },
    memorySize: props.memorySize,
});

Instead, getting that value requires several Cfn functions:

const firstEntry = cdk.Fn.select(0, endpoint.attrDnsEntries);
const entryParts = cdk.Fn.split(':', firstEntry);
const primaryDNSName = cdk.Fn.select(1, entryParts);

1. The current service property expects one port which is presumptuous because services can listen on many ports.

• What is the expected behavior (or behavior of feature suggested)?

It may be the case that the intended use of InterfaceVPCEndpoint may be different enough from connecting to custom VPC Endpoint Services to warrant a new class. I don’t have any good names but maybe CustomVPCEndpoint. This new construct would address the 3 issues noted above.

At the least, it would be nice if InterfaceVPCEndpoint had a primaryDNSName method so that users don’t need to know the exact format of this Cfn value to get a DNS name.

• What is the motivation / use case for changing the behavior or adding this feature?

Make using custom PrivateLink connections with CDK more convenient.

• Please tell us about your environment:

  • CDK CLI Version: 1.3.0
  • Module Version: 1.3.0
  • OS: OSX Mojave
  • Language: TypeScript

[flemjame-at-amazon]

@mitchlloyd the private DNS portion is fixed as of https://github.com/aws/aws-cdk/pull/5987/

[dlants]

I ran into this while trying to set up privatelink for ElasticSearch Cloud

It seems that ElasticSearch did not set up a default dns, so privateDnsEnabled does not work for the com.amazonaws.vpce.us-east-1.vpce-svc-0e42e1e06ed010238 service. Instead you have to create your own private hostedZone with a Cname that maps * to your private endpoint dns.

Naively, I attempted:

    const hostedZone = new route53.PrivateHostedZone(
      this,
      "ElasticSearchHostedZone",
      {
        zoneName: "vpce.us-east-1.aws.elastic-cloud.com",
        vpc: myVpc,
      }
    );

    new route53.CnameRecord(this, "ElasticSearchRecord", {
      zone: hostedZone,
      recordName: "*",
      domainName: endpoint.vpcEndpointDnsEntries[0]
    });

This failed with:

| CREATE_FAILED        | AWS::Route53::RecordSet
[RRSet of type CNAME with DNS name *.vpce.us-east-1.aws.elastic-cloud.com. does not contain exactly one resource record.]

Replacing the CnameRecord declaration with:

    const firstEntry = cdk.Fn.select(0, endpoint.vpcEndpointDnsEntries);
    const entryParts = cdk.Fn.split(':', firstEntry);
    const primaryDNSName = cdk.Fn.select(1, entryParts);

    new route53.CnameRecord(this, "ElasticSearchRecord", {
      zone: hostedZone,
      recordName: "*",
      domainName: primaryDNSName
    });

worked!