I think this nets to a < 0.01% delta to our bill. Is this really that big an issue in practice? For hobbyist projects, maybe? But for larger customers, this is a drop in the ocean.
I actually think this is a (somewhat) smart move. It incentivizes you to use a NAT gateway to egress traffic to your instances. You can either run your own fleet (it's very easy - but you gotta fix it if it breaks), or use their managed NAT solution (more expensive, but with less worry hopefully) - and not just tack on a public IP to every instance that needs internet connectivity. We did this from the get-go (running our own NATs) - and only have a few public IPs relative to the # of instances we run.
If it’s 0.01% then why should google bother with it? All it does is cost goodwill for a negligible amount of money.
We have vm external ips turned off at the org level. It feels like every day we have to explain to a new person that no, that google written tutorial doesn’t work because it assumes public ips are available. Entire services don’t work with this flag on.
The other shitty thing is it feels like at least once a month we get some email of a price increase or deprecation that causes some fire drill, and then we ask our tam to tell us the actual cost and he can’t because he has no idea it’s happening so the burden falls on us
my experince with GCP support during the free trial (with the advertising explictly saying that they provide "Technical Support for free trials") was:
1. create ticket
2. immediately receive email telling me I'm barred from free technical support and told I need to purchase a "Silver, Gold or Platinum Cloud Platform Support package"
Hah, the best part is I legitimately had to deal with GCP actually being broken (resource refused to delete) that could only be fixed by Google internally (both portal and cli returned http 500). Imagine the joy I had not having "technical support" as a benefit.
AWS support is indeed pretty crappy. $500 is not a fixed price. You pay 10% for the first 10K/month, 7% of $10K-$80K and so on. The Developer plan is 3%, but is pretty worthless - it should be renamed to rookie-plan or similar - you can get the same answers on SO for free within minutes instead of waiting days. Getting past first-level support on the Dev plan with harder technical issues takes weeks in my experience.
Setting up an inbound proxy VM that NATs all your other machines is not "difficult".
There are plenty of tutorials online for doing this with nginx or Apache, and even a junior dev ops person should be able to do this in a few hours' work.
I highly doubt this requires hiring another engineer.
It's not about the cost. Every Internet connected system(at least in cloud. Ideally every system) should be publicly accessible but instead of providing it by default they are providing it as feature. If you don't want to show VM to the world then you use NAT but they have got this backward.
This is slippery slope. One day they might charge you to open a port to external world.
"Every Internet-connected system should be publicly accessible"
That sounds like a security or data leak nightmare waiting to happen. I would prefer not entrust my data with a company that feels there's value in having all of their instances publicly addressable.
Actually, Google professes in their "BeyondCorp" security model a zero-trust architecture. You shouldn't be assuming that just because your instance isn't publicly accessible that it is secure. (See: https://cloud.google.com/beyondcorp/)
Which makes this move even more surprising, because GCP reference architectures have traditionally been focused around public facing Internet access. Unless, it is a sign that GCP is getting more traction and Google is running out of public IPs to be handing out like candy. This could be an economic incentive to encourage people to conserve these IPs.
This is not what BeyondCorp means. It doesn't mean everything is publicly accessible. It means you don't make trust decisions based on "approved networks", but instead at the device level. It DOES NOT mean that you don't segment services, restrict access to systems that don't need public access, or follow any of the other appropriate security guidelines.
> You shouldn't be assuming that just because your instance isn't publicly accessible that it is secure
No one thinks this, and no one said anything of the sort. But likewise, making everything public because Google has a site called BeyondCorp, doesn't make it secure. There is a lot of effort to adopt a BeyondCorp model. None of which includes "make everything publicly routable".
Zero-trust architecture seem nice idea, and one you can implement when you’re Google and probably spend more on security than the gross revenue of most other companies reading your whitepaper.
I think the notion most infrastructure is not publicly addressed is prevalent, even in Google, i.e. you can’t SSH to the hypervisor hosting customer instances in GCP directly, it doesn’t have SSH sat on the public internet.
Public addresses are readily available on the secondary market but a /12 probably runs somewhere around $20MM.
Charging for IPv4 seems like a move designed to make all the smallest customers who care about $3/mo leave, GCP ends up with less customers and ARPU goes up probably significantly.
If you use IAP (Google's BeyondCorp secure proxy product) then your instances don't have a public IP; they are behind a firewall rule.
Also there is a big difference between BeyondCorp's "all internal services are on the public internet" and "all instances are on the internet". You don't want to put your DB server on the internet, for example.
NAT has messed up Internet so much that people can't even ensure security without it. You have firewall for security. If we had not relied on NAT for security we would have actually configured them.
Anyways, we are gonna have to configure firewalls for IPv6 because there is no NAT.
I actually think this is a (somewhat) smart move. It incentivizes you to use a NAT gateway to egress traffic to your instances. You can either run your own fleet (it's very easy - but you gotta fix it if it breaks), or use their managed NAT solution (more expensive, but with less worry hopefully) - and not just tack on a public IP to every instance that needs internet connectivity. We did this from the get-go (running our own NATs) - and only have a few public IPs relative to the # of instances we run.