Can I assume that while my cloud function is running, no other cloud function (that is also currently running) also has the same IP address? In other words, do I "own" the IP address of the cloud function during the time in which it is running?
My guess is no, since it would just cost Google more money to do that without much benefit for 95% of users, but I couldn't find any info on this anywhere, hence this question.
If my intuition is correct, then perhaps the only way to be sure that my function has a unique IP is to assign it a static IP? As of writing, static IPs for Cloud Functions are apparently in beta.
Currently, as the product stands, you can not assume that if you make an outgoing request from Cloud Functions that it will appear to come from an IP address, with no other outgoing traffic from any other functions appearing to come from it. As you've seen in the other question, there are blocks of addresses that Google owns, and the traffic could appear to come from anywhere within those blocks, depending on the region of deployment and other factors. You can expect that there are going to be far more Cloud Functions deployed for all projects for all customers running concurrently than there are specific IPs within those blocks. So you should not make any assumptions about the IP of origination. It could change at any time, and any function's or project's traffic may appear to come from it.
If this situation changes due to additional features offered by Cloud Functions, you might get a different set of guarantees, but it's not clear what those are without being in this beta program.
Doug is right. There is any guaranty of the IP address. And I don't hear about any alpha/beta program with static public IP.
However, there is an beta program called vpc connector, in networks section in the console, which allows you to define a small range of IP (cidr /28) to be used by function to enter in the VPC of your project. You can then set up all the route and the firewall rules that you want with this range in your VPC.
Finally, about the early Access mentioned in the link, and which shouldn't be public, it's not exactly that. Stay tuned.
Related
We're using Lambda to submit API requests to various endpoints. Lately we have been getting 403-Forbidden replies from the API endpoint(s) we're using, but it's only happening randomly.
When it pops up it seems to happen for a couple of days and then stops for awhile, but happens again later.
In order to troubleshoot this, the API provider(s) are asking me what IP address / domain we are sending requests from so that they can check their firewall.
I cannot find any report or anything showing me this, which seems unbelievable to me. I do see other threads about setting up VPC with private subnet, which would then use a static IP for all Lambda requests.
We can do that, but is there really no report or log that would show me a list of all the requests we've made and the Ip/domain it came from in the current setup?
Any information on this would be greatly appreciated. Thanks!
I cannot find any report or anything showing me this, which seems unbelievable to me
Lambda exists to let you write functions without thinking about the infrastructure that it's deployed on. It seems completely reasonable to me that it doesn't give you visibility into its public IP. It may not have one.
AWS has the concept of an elastic network interface. This is an entity in the AWS software-defined network that is independent of both the physical hardware running your workload, as well as any potential public IP addresses. For example, in EC2 an ENI is associated with an instance even when it's stopped, and even though it may run on different physical hardware and get a different public IP when it's next started (I've linked to the EC2 docs because that's the best description that I know of, but the same idea applies to Lambda, ECS, and anything else on the AWS network).
If you absolutely need to know what address a particular non-VPC Lambda invocation is using, then I think your only option is to call one of the "what's my IP" APIs. However, there is no guarantee that you'll ever see the same IP address associated with one of your Lambdas in the future.
As people have noted in the comments, the best solution is to run your Lambdas in a private subnet in your VPC, with a NAT and Elastic IP to guarantee that they always appear to be using the same public IP.
On GCP, I want to change external IP address of my VM instance several times in a day and in my project VM needs to be assigned new IP address each time. However, regardless of using ephemeral or static IP, when I try to change IP, there are only 3 or 4 different IP addresses. After 4 times change, the loop backs to start so the IP has been assigned before was assigned to VM again.
Is there a way to assign a new IP address to VM each time?
In this scenario you can use protocol forwarding in order to assign multiple/different external IP addresses to a VM instance. Then When traffic is sent to an external IP address that is served by a forwarding rule, the forwarding rule directs that traffic to the corresponding target pool or target instances.
As per document you can create up to 50 forwarding rule objects per project.
I think (don't know) that this isn't possible.
You are being loaned public IPs from Google's pool and, technically these are assigned randomly (you won't always get these IPs) but, over the timeframe you've monitored, you detect there's a pattern and the behavior is insufficient for your needs.
It's unclear why you need random IPs -- I assume random DNS naming won't suffice for your use-case -- you may want to submit a feature request to Google's Issue Tracker
Given that you detect a period of 3-4 IPs, you could temporarily hold these on VM interfaces and, once you obtain a different IP for your app, you could release the others?
Originally asked on the AWS forums but I get the sense I won't hear back for quite some time, so I'm also posing my questions here:
I recently set up a Client VPN based on this guide. When connected I'm successfully able to access the internet as well as resources in a private subnet, so at this point I have a basic understanding of how all the parts fit together, except for one: the Client CIDR range. This concept gave me so much trouble that I think it stretched out the time-to-build by 2 days because of all the thrashing I did trying to connect it to the other concepts Client VPN involves. But it bugs me when I don't fully understand a thing so I have some questions about it:
Does the Range benefit at all from being in the same CIDR range as the VPC it's a part of, assuming it doesn't overlap with target network(s)? Why or why not?
Why does the Range need to be of size /22, while target networks can be as small as /27? Doesn't that imply 2^5 more clients could be attempting to access a resource in a VPC as there are available addresses in a given subnet?
In setting up security groups for the private subnet I noticed that I had to use rules based on the CIDR range of the target subnet client connections landed in, rather than the Client CIDR range - why is that?
As you can probably tell from my questions, I'm not a network administrator. I'm trying to understand that world at the same time I'm trying to spin up useful infrastructure. My guess is the answers to these questions are blindingly obvious to someone with experience in that area, but I just don't get it.
Here are my attempts at clarification:
So the range shouldn't overlap the VPC CIDR supernet (and individual subnets within the VPC) or you may get routing conflicts. So I'm not sure what you are referring to? Can you provide your configuration.
From what I can tell the /16 to /22 range is just something that is not technical restriction, probably because AWS hadn't had a chance to add a feature that would allow this to have more options. I'm assuming you want a smaller range? In Azure P2S VPN, there is not such restriction - their minimum pool is a /29.
SGs are applied to resources such as EC2s and not VPCs directly but in the inbound rules you can specific CIDRs directly - so I'm not sure what you are referring to... do you have the specific example you could share?
If I set up Cloud NAT, and attach it to a network, I am charged about $0.050 per hour. This is fair since I don't have to set up my own NAT instance and I don't have to manage it myself.
Furthermore:
When reserving a static IP address on GCP, I am charged at a rate of about $0.010 per hour as long as I don't attach the IP address to an instance or a load balancer.
I understand that this is done to dissuade users from creating unused IP addresses.
However:
If I create a Regional IP address and instruct Cloud NAT to use that as its external IP address, the IP address is still marked as "unused" in the Cloud Console (In use by: None in the Web UI, and RESERVED using the gcloud command).
This leads to two things:
Confusion: It is not immediately obvious that the reserved IP address is in fact in use, and someone might try to delete it.
An unused IP address is charged, which is fair if it is indeed unused, but I would argue that it is in fact not unused, and google is running an "invisible instance" for me (even though it's just a network service feature in Andromeda, and probably does not involve a single running instance - at least according to the docs)
If anyone knows if this is a feature or a bug, I would be very thankful (and I would also be thankful if I could save $0.010 per hour :D)
Update
From the billing console I can deduce that the static IP address is not being charged for (when attached to Cloud NAT), even though it is marked as "unused".
The question is now if the bug is with the Web UI/gcloud or the billing system.
I have a bunch of servers that I want to start on Google Cloud. I have one static IP that I have reserved, that's my "public" entry point to my system.
But I also need to be able to get to all my other servers directly. I don't really care about what ephemeral IP is assigned to them, but it would be very convenient to be able to refer to them by name (rather than having to copy-and-paste the IP addresses from the console).
I see this answer, but I was hoping that there is a configuration option somewhere for this that does not involve scripting.
The link what you have provided is a comprehensive answer. You can do it in several different ways (like using deployment manager or Cloud Functions), but at the end of the day it's still scripting.
However, if your issue is the changing IP's, you can reserve the IP's and reattach them if the instance gets recreated. ( You only need to pay for unattached reserved IP's.)
However it is questionable, why do you need direct access to all of your instances in a frequent basis other than their public/internal endpoints which could be a LoadBalancer.