I want to select specific Elastic IP my own when my lambda function executed.
my service has to respond to several situations, and by user's attributes.
Could I write code in a lambda function, that can choose specific my own elastic IP?
I had searched for this. but old information says it cannot do.
but recently I heard about it is possible by using Network Load Balancer or Application Load Balancer.
But I don't know how to use this for the problem.
No. You cannot associate an Elastic IP (EIP) address with an AWS Lambda function.
Well, actually you can, but I wouldn't recommend it. When a Lambda function is associated with a VPC, it connects via an Elastic Network Interface (ENI). It is possible to attach an EIP to an ENI. This also grants access to the Internet if it is attached to a public subnet.
So why avoid it? Because Lambda might create additional ENIs, especially if the Lambda function is frequently invoked and run in parallel. This means it will not have a consistent ENI.
An alternative method is:
Attach the AWS Lambda function to a private subnet
Put a NAT Gateway in a public subnet
Associate an Elastic IP address with the NAT Gateway
All traffic from the Lambda function to the Internet will then come from the NAT Gateway's EIP (however, I don't think you can change that EIP)
Looking at #John Rotenstein's reply: for small systems, with limited calls to the same lambda adding an EIP to the ENI for a lambda could work - if you put a queue in front of the lambda to handle the requests and limit the concurrency of the lambda to 1. That's cheaper than a NAT Gateway (saves around $30) per month. For larger systems, this may not be an issue and you may need the concurrency to be more than one - in that case the NAT gateway is the only way out.
Related
I am looking to assign a static IP to my Lambda which is being invoked via the API gateway. This is required because, the downstream system that i invoke from this lambda accepts web requests only from a Whitelisted IP.
I am successful in achieving this via the VPC that i associate with my lambda. But VPC introduces a bad cold-start time which sometime ranges 12-16seconds. So i am looking for a way to prevent this cold start from the VPC, but at the same time assign a static IP to the lambda.
You will need to:
Create a VPC with an Internet Gateway, a public subnet and a private subnet
Attach the AWS Lambda function to the private subnet
Launch a NAT Gateway in the public subnet and update the Route Table of the private subnet to use the NAT Gateway
The NAT Gateway will use an Elastic IP address (which is a static IP address). All traffic from the Lambda function to the Internet will come from this IP address, which can be used in the whitelist.
You might think that this is a bit of overkill for simply attaching a static IP address, but multiple Lambda function can run in parallel and they could run in multiple Availability Zones. Sending all traffic through the NAT Gateway is the only way to ensure they all have the same IP address. (Or, to be more specific, one IP address per AZ in which the NAT Gateway is launched.)
You can't assign a public/static IP to any Lambda function.
Your only good option is to deploy into a VPC with an Internet Gateway and configure routing from the Lambda's subnet through a NAT which has an Elastic IP. Then your target host can whitelist the Elastic IP.
Also see:
Public IP address for AWS API Gateway & Lambda (no VPC) - Stack Overflow
AWS Lambda functions with a static IP – Matthew Leak – Medium
I agree with the answer by John for having static IP whitelisting part. However, it won't resolve your cold start problem because lambda,if ideal, actually takes a small time to start. So I would recommend you also create a Cloudwatch event to hit lambda periodically to resolve this or write a simple code(either in lambda or somewhere else) which sends an empty request periodically so that cold start problem is resolved. You can view the improvement in X-Ray. This is an overhead but one time process.
To eliminate cold starts, you can use a service like https://lambdawarmer.com to keep a desired number of lambda instances always warm.
It basically uses a bunch of servers to periodically and exactly concurrently hit an endpoint on your lambda to keep a certain number of lambdas always warm.
I have provisioned an AWS API Gateway and created a Lambda function to connect to an external REST API. The API Gateway & Lambda is not in a VPC so the egress IP address is random. The challenge I have is the external REST API is behind a firewall, which requires the IP address or subnet of the Lambda to be whitelisted.
I have looked at the AWS IP Address page (below), however there is no explicit mention of either API Gateway or Lambda.
https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html#filter-json-file
Has anyone come across this before & found a resolution to it. For the purposes of this solution I cannot put the API Gateway & Lambdas in a VPC.
Any help would be greatly appreciated!
API Gateway seems to be irrelevant to this discussion. If I understand your question, you're trying to make API requests from a Lambda function to a remote API server and you want those requests to originate from a known IP address so that you can whitelist that IP at the remote server.
First thing I would say is don't use IP whitelisting; use authenticated API requests instead.
If that's not possible then use VPC with an Internet Gateway (IGW). Create a NAT and an Elastic IP, launch the Lambda into a private subnet of that VPC, and route the subnet's non-local traffic to the NAT. Then whitelist the NAT's Elastic IP on the remote API server. Examples here and here.
I know that you said you "cannot put [...] Lambdas in a VPC", but if you don't then you have no control over the originating IP address.
It is frustrating that the only way to ensure a Lambda function uses a static ip without a hack is to put the Lambda inside a VPC, create a NAT with an Elastic IP, as many other answers nicely explain.
However, NATs cost around $40 per month in regions that I am familiar with, even with minimal traffic. This may be cost prohibitive for certain use cases, such as if you need multiple dev/test/staging environments.
One possible workaround (which should be used with caution) is to create a micro EC2 instance with an elastic IP (which gives the static IP address), then your choice of proxy/routing so you can make HTTP calls by tunnelling from the Lambda function through the EC2 instance. (e.g. SSH from Lambda function into EC2 instance then CURL from EC2 to the endpoint which is protected by an allowlist)
This is a few extra hoops to jump through and could introduce security vulnerabilities which should be mitigated (e.g. Beware storing SSH keys or passwords inside a Lambda function, ensure Security Groups are tight) but I wanted to post this as a possible workaround for any devs who need a cost effective workaround for a requirement to connect to an endpoint which enforces allowlist rules.
I have an aws api gateway which has a custom domain.
I have to access one of client's api from AWS api gateway.
Those api's will be accessible based on IP address.
If I want to access those api's from aws, I need to know the Ip address of my AWS apigateway.
But I am not sure where I can get this.
Any possibilities to get the static IP address of AWS apigateway?
Unfortunately the API Gateway doesn't support this scenario of invoking an IP-whitelisted API directly. Basically any AWS instance can be used to make the API call and there's many IPs that AWS is using for this.
There are some ways around this, depending on your situation;
If the server you are reaching is within your own VPC, you could create a VPC link (with NLB) and circumvent the IP-whitelist issue. This solution only works for resources within your control.
If the server is external and is expecting a static IP, your best solution is to make your call from within a VPC. To make sure you have a static public IP you can use an elastic IP and a NAT Gateway in your VPC (more info here).
To invoke the external API triggered from the API Gateway you can use a Lambda but because of the VPC a cold start will be quite slow, >10s. To make sure the API will be responding fast you can use an EC2 instance or ECS service on Fargate.
After you clarified your requirements in the comments above it appears that you need your AWS Lambda function, which is being triggered by API Gateway, to appear to a third party as if it has a static outgoing IP address.
The solution to this is to configure your Lambda function to run in your VPC, in a private subnet of your VPC that has a route to a NAT Gateway. Then all outgoing connections from the Lambda function which access resources outside your VPC will use the NAT Gateway's static IP address.
We need to access APIs in a corporate backend that accept calls only from authorised IP addresses.
At this moment our mobile clients are calling an AWS Lambda function that performs some transformations and then calls another service on an EC2 instance that has the authorised public IP address assigned. This second service performs the final call to the corporate backend returning the data to the lambda and then to the clients.
This is working fine, but it adds some unnecessary complexity to the architecture that we wish to avoid.
Is it possible to assign the public IP to the lambda function somehow to avoid having this extra service in EC2?
Thanks,
GA
The straightforward solution is this:
create a NAT Instance or NAT Gateway with an Elastic IP address
create a private VPC subnet which uses the NAT device as its default route
deploy the Lambda function in VPC, associated with that private subnet.
Each Lambda container created will have an elastic network interface (ENI) on that private subnet, which means the NAT device will be its default gateway, which means the NAT device's EIP will be its source IP address for internally-originated connections that are bound for the Internet.
No change to the lambda function code, itself is required.
The above is the official solution.
Note also that with current technology, placing a Lambda funcion inside a VPC will have an impact on cold-start times, any time a new Elastic Network Interface (ENI) needs to be allocated.
When a Lambda function is configured to run within a VPC, it incurs an additional ENI start-up penalty.
https://docs.aws.amazon.com/lambda/latest/dg/vpc.html
I have an AWS Lambda function that makes use of an ElastiCache Redis cluster.
Since the Redis cluster is "locked" in a VPC, the Lambda function must reside in that VPC too.
For some reason, if the Lambda is allocated an IP of a public subnet, which has an Internet gateway - it still cannot make connections to the outside (the internet), thus making it impossible to use Kinesis.
For that, they suggest using a NAT gateway which lets the Lambda connect to the outside.
Basically, this works for me - but my issue is the money.
This solution is expensive for large amount of data transfers and I'm looking for some way to make it cheaper.
For a small POC that I've made, I paid ~$10.
This is too much for ~30GB as my production pipeline will run hundreds of gigabytes / month.
How do you suggest I let the Lambda function connect the outside (specifically Kinesis) without using a NAT gateway?
Thank you!
without using a NAT gateway?
Use a NAT instance.
You have to have one of these two things for anything in VPC to access the Internet from a private IP address.
NAT instances were exactly how this was always done in VPC, until the relatively new NAT Gateway service was rolled out.
You can also use a NAT gateway, which is a managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort. For common use cases, we recommend that you use a NAT gateway rather than a NAT instance.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html
Sure, it's easier, but it costs more. A lot more. The most significant difference in this case is that with a NAT instance, you pay a flat rate for use of the hardware, which could be an inexpensive t2.nano, $5/mo.
The NAT Gateway service is a high powered solution with nearly infinite scaling capacity, and is priced accordingly. A NAT instance is only as good as the hardware you choose to run it on, but I find t2.nano and t2.micro quite adequate for workloads requiring less than 250 Mbit/s of Internet connectivity.
Use the link, above, to learn more.
Lambda function instances will never be assigned a public IP address, regardless of the type of VPC subnet you place them in. A NAT gateway is the only solution to provide a Lambda function inside a VPC with access to resources that reside outside the VPC (like Kinesis).
If that isn't going to work for you due to cost, you might look into running a Redis server on an EC2 instance with an Elastic IP, which would allow the Lambda function to connect without being inside the VPC. A similar alternative would be to use RedisLabs instead of ElastiCache.