Using AWS Direct Connect, we've built a network between our on-premise and our AWS VPC. We've developed a web application that users will access from within the on-prem network. We're using the HTTP API Gateway, which uses a VPC Link to connect to the private ALB. We've used a Custom Domain Name with the HTTP API Gateway and disabled the default endpoint. The domain name is registered in a private hosted zone on Route 53.
We want to keep all the traffic between the clients and the API Gateway within our private network. However, we can see that the requests going to the HTTP API Gateway leave our network because the custom domain name for the API Gateway resolves to a public IP address.
Is there a way to assign a private IP address to the HTTP API Gateway? Or any other way to keep the traffic within our network?
One option is to switch to the REST API Gateway and make its endpoint type Private. However, the HTTP API Gateway suits our needs much better with its simplicity. It also has the option for connectivity to an ALB using VPC Link, which the REST Gateway lacks.
Sadly no, the HTTP APIs do not support Private APIs. Whatever solution you will use, HTTP API endpoint must be public.
You have to use REST API, or create your own fully custom solution if REST API is out of question.
I want to provide an update to this topic.
AWS updated its product and private endpoints are available right now.
AWS - Private API endpoint
There are also a couple of examples out there also for CDK, Cloudformation or management console.
I hope this helps
Related
I have 1 Lambda Function connected to AWS Oracle RDS. I have exposed lambda to outer world via API Gateway.
How can i access same API Gateway in my EC2 Instance where i have my back-end services running?
[ec2-user#ip-22-22-22-22 dummy]$ ./telnet 10apexecute2.execute-api.eu-west-1.amazonaws.com 443
Trying 55.11.144.98...
Please help
As the account must be restrictive with its outbound communication over internet, the suggested solution would to make use of a VPC endpoint for API Gateway.
Once you create this endpoint, make sure to enable the "Enable Private DNS Name" option to override the DNS resolution for execute-api endpoints to speak to resolve through your VPC endpoint.
More information can be found in this blog post: Introducing Amazon API Gateway Private Endpoints | AWS Compute Blog
I'm looking to setup an AWS API Gateway which will have private APIs (internal business client apps only)
One of the client apps that will be making requests to 1 of the apis is a client that is on-prem.
What options are available to authenticate requests coming from a client when that client is on-prem? Is there some type of tunnel I am able to create between the on-prem client on AWS VPC?
I dont want to at all make the APIs public. So I want to continue to keep all apis private. Any and all insights appreciated.
The following tools are provided to enhance the security of API Gateway.
Firstly there's support for a private API Gateway. By doing this it will only be accessible from the VPC and devices connected via VPN or Direct Connect to the API Gateway.
If it must be publicly accessible, but kept private you can lockdown he endpoint via either an API Gateway Resource Policy or by attaching a WAF to your API Gateway.
Finally if you need more advanced methods of authenticating and providing authorization to specific routes in your API, then you should look at API Gateways feature of Lambda Authorizers.
It looks like the simple answer is:
Option 1: Use Direct Connect
https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
or
Option 2: Use AWS Site-to-Site VPN
https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html
What options are available to allow on prem client make requests to VPC Endpoint (interface created for private RestAPI) ?
Do I absolutely need to use Corporate DNS?
If I use corporate DNS, my concern is that all existing requests going to S3 by on prem will suddenly get routed and wont work as expected?
Assuming here that I have also direct connect and transit gateway.
Is a VPC Endpoint even necessary?
Any insight is appreciated.
I'm making the assumption at this point that a VPC Endpoint is the solution for allowing on prem client to make request since it needs some VIP or url to make the request to. How else would I create a private RestAPI without a VPC endpoint?
I am assuming you are asking about Private API Gateway.
In this case VPC Endpoint is mandatory, as it is private.
When you create VPC Endpoint, it will generate some specific DNS names for this endpoint, you can use them to reach your API Gateway.
As you have Direct Connect, your best solution is to use Route53 Resolver.
In this solution your on-premise DNS will forward all resolution names that ends with amazonaws.com to Route53 Resolver.
Please, do not confuse name resolution with network connectivity, resolving names via Direct Connect doesn't mean all services request will flow via Direct Connect.
There is a good whitepapper about this solution:
https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf
With AWS API Gateway, is there a way to send a request through a corporate proxy? Let's say that I have a service that will only accept traffic sourced from http://proxy.my-proxy.domain.com:8000.
If the above is not possible, is there a way to send requests with an IP from my VPC CIDR?
NOTE - This is a private API Gateway with all VPC-E configured
correctly.
NOTE - As I am merely a simpleton, I do not have
privileges to modify this proxy.
NOTE - I'd rather not use lambda (if
possible)
Private endpoints are only private within the AWS ecosystem, they cannot be utilized outside them unless you establish connectivity between AWS VPC and your corporate network.
There are three ways to achieve this as far as i know
You can make your API Gateway be public and use WAF to control access to it. You can whitelist only your corporate proxy IP addresses that are only allowed to access this gateway.
Establish a VPN connection between your AWS VPC and the corporate network. This will allow you to use private endpoints without making them public using a secure encrypted pipe
Setup AWS Direct Connect between your AWS VPC and the corporate network. This may not be an option considering the cost to the value proposition
I just ended up using Lambda attached to my VPC w/ API Gateway proxy integration.
I have a situation when my product(some Web API) is living inside of VPC, i.e. with no any any external access. I'd like to expose the part of this APIs(just a couple of HTTP methods) to be accessible from the internet. I'm trying to achieve this using AWS API Gateway but it looks like I cannot make internal ELB endpoint the API Gateway resource. Any ideas how can I do this?
Thanks,
--Vovan
This was originally not possible, and then was solved with support for client certificates that API Gateway could use to authenticate itself to your services. This was a good solution, and is still available, but still required your services to be exposed -- at least in some sense -- to the Internet.
In November, 2017, AWS released a new capability that allows you to actually provision a network path between API Gateway and your internal services.
You can now provide access to HTTP(S) resources within your Amazon Virtual Private Cloud (VPC) without exposing them directly to the public Internet. You can use API Gateway to create an API endpoint that is integrated with your VPC. You create an endpoint to your VPC by setting up a VPC link between your VPC and a Network Load Balancer (NLB), which is provided by Elastic Load Balancing.
https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-api-gateway-supports-endpoint-integrations-with-private-vpcs/
Historical context follows.
As of now, there is no simple and foolproof way to do this, because your services that are accessible to API Gateway need to be accessible via/exposed to the public Internet and there is no built in trust mechanism by which you can be assured that such a request actually originated from any API Gateway deployment, much less your API Gateway deployment.
Amazon seems to have solved the issue of authenticating requests to your back-end services as having assuredly come, not only from API Gateway, but from your API Gateway instance. As before, endpoints still need to be exposed to the Internet, since the source IP address is not predictable -- but API gateway now supports client SSL certificates, which the back-side of API Gateway uses to authenticate itself to the front-side of your back-end service, that API gateway is calling.
Q: Can Amazon API Gateway work within an Amazon VPC?
No. Amazon API Gateway endpoints are always public to the Internet. Proxy requests to backend operations also need to be publicly accessible on the Internet. However, you can generate a client-side SSL certificate in Amazon API Gateway to verify that requests to your backend systems were sent by API Gateway using the public key of the certificate.
Q: Can I verify that it is API Gateway calling my backend?
Yes. Amazon API Gateway can generate a client-side SSL certificate and make the public key of that certificate available to you. Calls to your backend can be made with the generated certificate, and you can verify calls originating from Amazon API Gateway using the public key of the certificate.
— https://aws.amazon.com/api-gateway/faqs/#security
When you generate a client certificate in the API Gateway console, you're provided with the public key for that certificate. For security, the private key is retained by API Gateway and is not accessible to you. API Gateway will present the public key to your back-end when negotiating SSL. Any peer not presenting that same public key is not API gateway, and your back-end should deny SSL negotiation.
If a malicious actor should ever come into possession of the public key, they would not still be able to communicate with your back-end over SSL, because they would lack the mated private key, which is only known to API Gateway. (Your side of the interaction would be encrypted using your SSL certificate and it's mated private key, which is of course, known only to you.)
This capability addresses what previously appeared to be a significant limitation of the utility of API Gateway's HTTP proxy functionality... a limitation of such significance, in fact, that when I discovered the revised information, above, I began to doubt myself: Had this been there all along, and I had somehow managed to overlook it? The Wayback Machine says no, it's new. This information was added in September, 2015.
It's somewhat of a circuitous path, but you can proxy your Web service endpoints that are in a VPC through a Lambda function. That Lambda function can be called directly from the API Gateway. This blog post gives details on how to do that.