Configuration options for the networking/access of API Gateway in VPC facing architecture

[dlpzx]

Is your feature request related to a problem? Please describe. Since we have internet_facing=false, API gateway is exposed via VPC Internet endpoint only (private), that is the API Gateway resource policy limits access.

This customer is not connecting their VPNs directly to the VPC where the frontend is. Instead, they have a VPN with their desktop tools, and their networking team makes sure that the routing of the custom domain of data.all chosen redirects to the ALB where the frontend is deployed.

Because they are not accessing the ALB from within the same VPC, when accessing the frontend via their browser, the DNS name of the API Gateway cannot be resolved and they cannot reach the frontend.

Describe the solution you'd like, Describe alternatives you've considered To workaround this limitation, we manually switched API Gateway from internal to regional. And, in API Gateway Resource Policy, remove VPCE restriction.

We want to open the discussion to get more guidance and possibly add configuration parameters in cdk.json

A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

P.S. Please Don't attach files. Add code snippets directly in the message body instead.

[lorchda]

The additional use-case to support for data.all is "internally routed, but not VPC-internal".

[lorchda]

Please also update the architecture diagram to show the traffic flows. This information is required to create connectivity requests.

On the architecture image https://awslabs.github.io/aws-dataall/architecture/, the traffic from the users seemingly points to Route 53. But the flows do not actually ingress to Route 53, this is only the name resolution for the frontend and userguide ALBs.

[dlpzx]

Yesterday, Oct 18th, @lorchda and I met with a networking specialist to discuss different approaches to this issue. We concluded that:

1. In the long-term new services like AWS VPC Lattice simplify the networking configuration needed while allowing a micro-services architecture to grow. Implementing VPC Lattice involves a redesign of the architecture, investing significant efforts. It is a great enhancement to include in our mid/long term roadmap discussions.
2. For the short-term we still need to provide a solution for the scenario in this GitHub issue. The ideal approach, is that traffic flows as expected and defined in the architecture diagram. That means that the API Gateway endpoint is hit by the ECS task, not by the user.
3. The other option, which is a workaround already tested by @lorchda, exposes the API Gateway endpoint to the internet. It is not as isolated as having the API only accessed by VPC endpoints in the infra VPC. But it is still secure because of WAF and of the authorization of the API.

As action points, I will look into option 2 to see if it is possible. If yes, we should implement those changes which do not require any additional configuration parameter.

In case option 2 is not possible, then we will design option 3 introducing new (or re-using) configuration parameters in the cdk.json file.

@lorchda I will have an answer by the end of this week/middle of next week. Is that acceptable or do you need it earlier? Also feel free to comment if I missed any piece of information

[lorchda]

Proposed configuration structure as designed with @dlpzx :

    "DeploymentEnvironments": [
      {
        "internet_facing": false,
        "custom_domain": {
          "hosted_zone_name": "dataall.example.internal",
          "certificate_arn":  "arn:aws:acm:REGION:ACCOUNT_ID:certificate/UID"
        },
        "apigw_custom_domain": true // NEW, default to false
        ...
      }
    ]

Implementation logic

If apigw_custom_domain == true then:

• Set domain_name in https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_apigateway/RestApi.html to https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_apigateway/DomainNameOptions.html#aws_cdk.aws_apigateway.DomainNameOptions with options:
  • certificate use the same certificate with already the wildcard subject alternate name defined (*.dataall.example.internal)
  • domain_name: api.dataall.example.internal
  • endpoint_type: INTERNAL or REGIONAL (depending on internet_facing)
• Ensure that api_url in SSM is pointing to the custom domain
• Nested if hosted_zone_id not None then:
  • Create Route 53 Alias record to API GW