- Le plus récent
- Le plus de votes
- La plupart des commentaires
You don't mention you're using VPC Link for API Gateway HTTP APIs, or API Gateway REST APIs (it's not essential to know but it would narrow down the responses somewhat).
But for both of those you don't need to resolve the NLB DNS name - you configure API Gateway to point directly to the NLB you have already configured. For REST APIs you create a VPC Link per NLB; for HTTP APIs you create a VPC Link per VPC and then in each integration you select the appropriate NLB.
I'm not sure if this is the question you're asking - I would test this first without private certificates (to see if the private certificates are the problem or there is another issue) and then once you have it working, add additional layers.
Maybe something related to this. Can I have DNS alias A record for created NLB in such scenario and use that alias in private API Gateway Integration as endpoint URL instead of the default NLB domain name? If I do so I have error "Invalid HTTP endpoint specified for URI". Is it supported? To give more context: behind NLB I have target group with ALB with a private certificate from on-premise self hosted CA. But I configured tlsConfig with insecureSkipVerification set to true in x-amazon-apigateway-integration for that endpoint. So I guess such private cert should be accepted then?
I got the same error. It seems that API Gateway only accept existing TLDs even if you defined private zones in Route53. You can hit .dev, .qa but not .local or .prod
Contenus pertinents
- demandé il y a 7 mois
- demandé il y a un an
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a un an
Is this a repeat of the question or an answer? If you try to answer whether with the tlsConfig using insecureSkipVerification = T can work, what is your verification result? Does it work? I felt the first step of Private DNS resolution in this scenario seems not working, not even get to the https tls handshaking state. Also, insecureSkipVerification is usually not recommended, although the integration endpoint is private and possibly owned by API owner.