I want to call a local api from AWS lamdba (or any AWS tool that will do the job). For example, given the following node api endpoint:
http://localhost:3334/api/ping
How can I wireup AWS to hit this? Does the endpoint have to be publicly exposed?
That endpoint is only available on the machine it is running on. There is no way anything outside that machine can hit it. An endpoint with an address of "localhost" can only be accessed from the local host.
You would have to expose your API to the internet, or setup some sort of VPN link with your AWS VPC in order to make your API accessible from AWS.
Related
Right now I'm using AWS lamba and AWS EC2 and I'm relying on VPC to share data between a lambda function and a server when lambda needs something from the server.
With the right settings in Secure Groups the server accepts only requests from that special lambda and I don't have to do secure the connection between the two because it's like the server and the lambda function are the only two things in their network.
But I'm trying to move my server to another provider, and this means i have to find a way to secure the server
My question: is there something like a VPC I can create between lambda and a server hosted somewhere else AWS? what kind of tecnologies do i need?
I started looking for VPNs and certificates
I have a service on Cloud Run (Service A) who is trying to call another service on Cloud Run (Service B). Both the services are in us-east1.
For Service B, Ingress is set to 'Allow internal traffic only' and Authentication is set to 'Allow unauthenticated invocations.
I created a Serverless VPC Connector in the same region as the services and set the IP address range to 10.8.0.0/28.
I then connected Service A to the connector mentioned above and set 'Route only requests to private IPs through the VPC connector'.
I seem to be getting a 403 when attempting to hit the service. Has anyone had this issue? If so, how did you solve this problem?
You need to set the egress to All, to route all the traffic to the serverless VPC connector.
Indeed, even if you set the service B to internal egress, the Cloud Run service is still exposed publicly, but an additional check is performed on the requests that come in to validate the traffic origin (comes from your VPC or not).
In your case, in the service A, with the private range only egress, you route only the traffic going to private IP, and it's not the case of the always-publicly-exposed "internal" service B.
I am guessing that the code 403 you are getting it from the cloud run service and that is a problem with the authentication, so to solve that error code you could follow this link, there you will find a detail explanation of how authenticated users for you services.
I was able to fix this issue. This must be used when you have to use authenticated user to access cloud run application
Accessing Authenticated Cloud Run applications using IAP
It means that your client is not authorized to invoke this service.
You can address this by taking one of the following actions:
If the service is meant to be invocable by anyone, update its IAM settings to make the service public.
If the service is meant to be invocable only by certain identities, make sure that you invoke it
Please find the link that might help in troubleshooting this error.
We've got dockerized microservices in AWS, all behind an API Gateway and accessible via REST. Authentication is managed by the API Gateway.
Is there any possibility to test those REST-microservices on a local machine (including authentication/api gateway logic)? Is there a possibility to make the API Gateway echo back the requests to my local machine and to call the microservices running locally? What is best practice for testing API Gateway managed authentication locally?
To use the AWS API Gateway locally, spin up SAM locally using the SAM CLI. There are however limits to what you can do with SAM, so you may not be able to do what you need to do locally. For example, websockets are still not supported (as of Sept 2020) as far as I know.
Instead of voting this answer down, please add a comment to provide other important information.
SAM stands for Serverless Application Model. See the Quickstart Guide for Developing Serverless Apps using SAM.
Other links:
Running API Gateway Locally
AWS CLI (required to run the SAM CLI)
Install the SAM CLI
SAM CLI Reference
Unfortunately, API Gateway doesn't offer local testing/development solutions at the moment.
To call the microservices locally a workaround could be to use Private integration on API Gateway which would use VPCLink. VPCLink will connect to services running within a VPC via NLB. For example, the setup would be API Gateway --> VPCLink Integration --> NLB --> EC2 instance (for example, acts as proxy) --> calls local service (VPC connects to local network via Direct connect)
Although a complicated setup but a possible workaround
i created an android application that requires use of web service
i want it to be able to access the app everywhere therefore i need
my web services to be public with an external ip so i can access
what is the best way to do it?
I have an Amazon Web Services account i dont know if created an instance and run the web services there will be the best solution
My big problem with Amazon instance is that it takes a while to show in the app the result of the web service
Any ideas in how to make my web service public?
It appears that your requirement is:
Expose a public API endpoint for use by your Android application
Run some code when the API is called
There are two ways you could expose an API:
Use Amazon API Gateway, which that can publish, maintain, monitor, and secure APIs. It takes care of security and throttling. A DNS name is provided, which should be used for API calls. When a request is receive, API Gateway can pass the request to a web server or can trigger an AWS Lambda function to execute code without requiring a server.
Or, run an Amazon EC2 instance with your application. Assign an Elastic IP Address to the instance, which is a static IP address. Create an A record in Amazon Route 53 (or your own DNS server) that points a DNS name to that IP address.
I'm trying to put an Amazon API Gateway in front of an Application Load Balancer, which balances traffic to my ECS Cluster, where all my microservices are deployed. The motivation to use the API Gateway is to use a custom authorizer through a lambda function.
System diagram
In Amazon words (https://aws.amazon.com/api-gateway/faqs/): "Proxy requests to backend operations also need to be publicly accessible on the Internet". This forces me to make the ELB public (internet-facing) instead of internal. Then, I need a way to ensure that only the API Gateway is able to access the ELB outside the VPC.
My first idea was to use a Client Certificate in the API Gatway, but the ELB doesn't seem to support it.
Any ideas would be highly appreciated!
This seems to be a huge missing piece for the API gateway technology, given the way it's pushed. Not being able to call into an internal-facing server in the VPC severely restricts its usefulness as an authentication front-door for internet access.
FWIW, in Azure, API Management supports this out of the box - it can accept requests from the internet and call directly into your virtual network which is otherwise firewalled off.
The only way this seems to be possible under AWS is using Lambdas, which adds a significant layer of complexity, esp. if you need to support various binary protocols.
Looks like this support has now been added. Haven't tested, YMMV:
https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-api-gateway-supports-endpoint-integrations-with-private-vpcs/
We decided to use a header to check to make sure all traffic is coming through API Gateway. We save a secret in our apps environmental variables and tell the API Gateway to inject that when we create the API. Then check for that key in our app.
Here is what we are doing for this:
In our base controller we check for the key (we just have an REST API behind the gateway):
string ApiGatewayPassthroughHeader = context.HttpContext.Request.Headers["ApiGatewayPassthroughHeader"];
if (ApiGatewayPassthroughHeader != Environment.GetEnvironmentVariable("ApiGatewayPassthroughHeader"))
{
throw new error;
}
In our swagger file (we are using swagger.json as the source of our APIs)
"x-amazon-apigateway-integration": {
"type": "http_proxy",
"uri": "https://${stageVariables.url}/path/to/resource",
"httpMethod": "post",
"requestParameters": {
"integration.request.header.ApiGatewayPassthroughHeader": "${ApiGatewayPassthroughHeader}"
}
},
In our docker compose file (we are using docker, but the same could be used in any settings file)
services:
example:
environment:
- ApiGatewayPassthroughHeader=9708cc2d-2d42-example-8526-4586b1bcc74d
At build time we take the secret from our settings file and replace it in the swagger.json file. This way we can rotate the key in our settings file and API gateway will update to use the key the app is looking for.
I know this is an old issue, but I think they may have just recently added support.
"Amazon API Gateway announced the general availability of HTTP APIs, enabling customers to easily build high performance RESTful APIs that offer up to 71% cost savings and 60% latency reduction compared to REST APIs available from API Gateway. As part of this launch, customers will be able to take advantage of several new features including the ability the route requests to private AWS Elastic Load Balancers (ELB), including new support for AWS ALB, and IP-based services registered in AWS CloudMap. "
https://aws.amazon.com/about-aws/whats-new/2020/03/api-gateway-private-integrations-aws-elb-cloudmap-http-apis-release/
It is possible if you use VPC Link and Network Load Balancer.
Please have a look at this post:
https://adrianhesketh.com/2017/12/15/aws-api-gateway-to-ecs-via-vpc-link/
TL;DR
Create internal Network Load Balancer connected to your target group
(instances in a VPC)
In the API Gateway console, create a VPC Link and link it to above NLB
Create API Gateway endpoint, choose "VPC Link integration" and specify your NLB internal URL as an "Endpoint URL"
Hope that helps!
It is now possible to add an authorizer directly to Application Load Balancer (ALB) in front of ECS.
This can be configured directly in the rules of a listener. See this blog post for details:
https://aws.amazon.com/de/blogs/aws/built-in-authentication-in-alb/
Currently there is no way to put API Gateway in front of private ELB, so you're right that it has to be internet facing. The best workaround for your case I can think of would be to put ELB into TCP pass through mode and terminate client certificate on your end hosts behind the ELB.
The ALB should be internal in order to have the requests routed there through private link. Works perfectly fine in my setup without need to put NLB in front of it.
Routes should be as following:
$default
/
GET (or POST or whichever you want to use)
Integration should be attached to all paths $default and GET/POST/ANY etc