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.
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.
I'm working with CDK/CloudFormation and recently started getting this error when attempting to create a new stack:
The maximum number of addresses has been reached.
Looking in the AWS Management Console, there is a limit of 40 VPC IP addresses and there are exactly 40 in the list - but some of these have neither an Associated Instance ID nor an Association ID set:
My understanding is the ones that have neither of these set aren't being used for anything so would like to make them usable to get past the error on stack creation. But unsure how to do this - would "Release Elastic IP address" do the trick or do they need to remain in the account but be marked as reusable in some other way?
The maximum number of addresses has been reached.
You get this error because you associate public IP addresses to your instances. As you may know, the number of public IPv4 ip addresses is limited. This means that AWS, by default, allows you to allocate at most 5 Elastic IPs per region. This is a soft limit, you can ask for an increase. There are ways around having to attach public IP addresses to everything, so it is not really recommended to ask for an increase.
But unsure how to do this - would "Release Elastic IP address" do the trick or do they need to remain in the account but be marked as reusable in some other way?
First you have to dissociate the IP address from the instance. Afterwards, you will be able to press Release Elastic IP address. So yes, that would do the trick.
I'm working with AWS CDK and Kubernetes and I had to request a quota increase from 5 to 10, and I got it approved in 15 minutes.
Go to https://us-east-1.console.aws.amazon.com/servicequotas/home/services/ec2/quotas and search for "IP". Then, choose "EC2-VPC Elastic IPs".
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?
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.
Here's what's bothering me. Is there a better way than sending emails to devs that the ip address for their dev server has changed after the instance is stopped and started?
I was thinking of a single small instance that has an elastic ip which the devs can log in using terminal, and ssh again to the internal ip address of the dev server. Is that effective?
Does it mean that the devs need to be informed of the change every time?
It's unclear exactly what you are saying "there's a new public dns for the server"? -thanks for the comment, that's clearer what you mean! It's the aws domain name in the format "ec2-54-222-213-143.eu-west-1.compute.amazonaws.com" you are referring to
You are asking how can these name/address changes be managed?
Generally speaking for fixing these kinds of problems there are a couple of things to be aware of
Firstly, if it is the public ip address that is changing instead of an ephemeral public ip address use an elastic ip. This will stay the same and can be transferred from an old instance to a new instance. Please read http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html about the differences between "Elastic IP" and normal public IP addresses on AWS
Secondly, if you are concerned about maintenance of the dns records that map the ip addresses to the domain names then it is possible to automate the updates to aws route53. I have used the aws cli command "route53 change-resource-record-sets" for this and also CloudFormation
Automating events to occur on instance start up does take a little research of the available APIs and hooks for example see this answer with a simple use of cloud-init Using cloud-init user data