Modernizing perimeter security: Scalable perimeters with VPC Service Controls
Agents represent a fundamental shift in cloud operations. They can act on behalf of users or autonomously, make non-deterministic decisions, and request data across projects at unprecedented speed and scale.
Agents represent a fundamental shift in cloud operations. They can act on behalf of users or autonomously, make non-deterministic decisions, and request data across projects at unprecedented speed and scale.
Traditional, manually-operated network perimeters are vulnerable to today’s machine-speed attacks. Overly permissive perimeters, built to avoid blocked connections, increase the risk of unauthorized data theft, but overly strict perimeters stall development under a flood of access denials.
Today, we're excited to announce key enhancements to VPC Service Controls (VPC-SC) that make perimeters easier to create, maintain, and scale. You can now add folders to perimeter membership, so that projects contained in them inherit policy. You can also manage granular exceptions and resolve denials with guided, scoped remediation.
The result is data protected by default, so you can scale autonomous agents across your enterprise without letting data leave your perimeter. This update is generally available, and at no additional cost.
Perimeters aligned to your architecture VPC-SC provides a context-aware network security perimeter around your Google Cloud deployment, designed to secure your organization against data theft, even in the event of compromised credentials, identity and access management (IAM) misconfigurations, and insider threats. By extending network-layer protection across service-to-service interactions in Google Cloud's infrastructure, VPC-SC goes beyond traditional firewalls and creates an additional layer of defense that prevents access outside your corporate network — and is now easier for your organization to manage.
In context
- Topic: Cloud y Arquitectura — Nube pública, híbrida, costos y decisiones de infraestructura.
- Source: Google Cloud Blog
- Published: 15/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
After a few years, nearly every organisation that migrated discovers the same thing: the bill grows faster than the business. Not because the cloud is expensive, but because nobody switches off what is no longer used and nobody has the incentive to check.
My reading goes through who sees the bill. In organisations where cloud cost reaches the team that generates it, spend organises itself. Where only finance sees the bill, spend grows and the discussion becomes a blind cut every year end.
What usually goes wrong
What I see fail most is the literal migration. The system gets moved exactly as it was, nothing redesigned, and you end up paying hourly for what used to be paid once. It works the same, costs more, and two years later somebody asks why it was done. Lift and shift is not modernising.
What to watch
- Who sees the bill and in what detail: with no owner for the spend, the spend grows on its own.
- Where the data physically sits and what local regulation demands about that.
- What happens when the provider has an outage, because it will, and what keeps running meanwhile.
How I read this entry
I would read it thinking about the exit before the entry. Not because anyone plans to leave, but because the conversation about how you would leave is the one that reveals how much you are locking in. If nobody at the table can describe that path, the dependency is already deeper than they think.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
