jain.com — data centers, connectivity and security, analyzed daily

Tag: Cloud Infrastructure

  • Cloud Firewalls Span 0% to 99.95%; AI Agent Traffic Makes the Choice Matter More

    Cloud Firewalls Span 0% to 99.95%; AI Agent Traffic Makes the Choice Matter More

    TL;DR · 30-second read

    The Short Version

    An independent testing group ran nine cloud firewalls through the same set of real attacks. A cloud firewall is the software gatekeeper that screens traffic before it reaches a company’s systems in the cloud.

    Results ranged from blocking nearly everything to scoring zero. The built-in firewalls from Amazon and Microsoft scored zero on the test’s protection measure. Four products from specialist security companies scored above 99.7 percent.

    The lesson: having a firewall is not the same as being protected. That matters more as companies let automated artificial intelligence assistants pass information to each other inside their networks.

    On September 29, 2026, CyberRatings.org, a non-profit cybersecurity testing organization based in Austin, Texas, published its 2026 Cloud Network Firewall (CNFW) results, with testing carried out by NSS Labs. Nine products were evaluated. Four earned a Recommended rating, and each scored 99.7% or higher in Security Effectiveness: Fortinet FortiGate, HPE Juniper Networking vSRX, Palo Alto Networks VM-Series and Versa Networks Next Generation Firewall.

    Check Point CloudGuard posted the highest score at 99.95% but was rated Neutral because of its above-average price per Mbps. AWS Network Firewall and Microsoft Azure Firewall each scored 0% and were rated Caution. Google Cloud Platform NGFW Enterprise (77.45%) and Cisco Secure Firewall Threat Defense Virtual (66.10%) were also rated Caution. The reports are free on the CyberRatings.org website.

    Executive Summary

    The headline finding is the spread. Products sold into the same category and tested under identical conditions landed anywhere from 0% to 99.95% on the same security measure. In practice, the label “cloud firewall” says little about what a product will stop. The specific product, and how it handles disguised and encrypted traffic, does.

    The results also split along a line many cloud buyers care about. The firewalls built into cloud platforms were far less consistent than dedicated third-party products, which were deployed on Amazon Web Services for the test. Native firewalls are the path of least resistance for many teams because they are already inside the cloud account. CyberRatings’ advice is to treat them as a baseline, not a finish line, and to validate them before relying on them as a primary control.

    The organization also flagged a forward-looking concern. AI models and agentic workflows, meaning software agents that take actions and call other agents, are expected to consume more network resources and require larger, more complex firewall policies. That includes more “east-west” traffic moving between internal systems. As that traffic grows, how well a firewall inspects it becomes a larger share of an organization’s actual exposure.

    Native Convenience Versus Tested Protection

    Of the nine products, the four rated Recommended all came from dedicated security vendors, and all cleared 99.7% Security Effectiveness. The three native offerings from the major cloud platforms scored 0% (AWS), 0% (Microsoft Azure) and 77.45% (Google Cloud). The split is not purely native versus third-party, though. Cisco’s virtual firewall, a third-party product, scored 66.10% and was also rated Caution. The more accurate reading is that results vary widely by product. Among the natives, none reached the level of the top group.

    This matters because native firewalls have real structural advantages. They are billed through the same cloud account, managed through the same console and require no separate virtual appliance. For a team under deadline, that often decides the purchase. The test results suggest that convenience and protection are separate questions, and buyers should answer both rather than assume the first settles the second.

    The ratings also weigh cost. Check Point scored highest of all at 99.95% but received a Neutral rating because of its above-average price per Mbps, a measure of cost per megabit per second of inspected throughput. A top score with a middling rating shows the ratings are a value judgment, not only a ranking of effectiveness. Buyers with different budgets or throughput needs may reasonably weigh that trade-off differently.

    Why AI Agent Traffic Raises the Stakes of the Pick

    The case for the title rests on three facts from the results. First, CyberRatings expects local AI models and agentic workflows to consume more network resources and to drive “larger, more complex policies, including east-west agent-to-agent traffic.” East-west traffic moves between systems inside a network, as opposed to north-south traffic entering or leaving it. Agents that call tools, query data stores and hand work to other agents generate exactly this kind of internal chatter. That means more flows, and more rules governing them, pass through whatever firewall sits in the path.

    Second, the test showed how much depends on evasion handling. Evasions are techniques that disguise malicious traffic so inspection misses it. NSS Labs used 5,004 evasion attacks spanning 43 techniques across OSI Layers 3, 4 and 7: the network addressing layer, the transport layer that manages connections, and the application layer where web and API traffic lives. The organization notes that a single successful evasion can enable an entire class of exploits or malware. A firewall that is strong on average but weak against one evasion technique is therefore not partly protective against that class. It may not be protective at all.

    Third, CyberRatings tells buyers to require TLS inspection, the ability to decrypt and inspect encrypted traffic, because a firewall that cannot do this leaves a substantial blind spot. Agent-to-agent and API traffic is commonly encrypted. Put together, more internal traffic, more complex policies and a large share of encrypted flows make the gap between a 99.7% product and a 0% product more consequential. The groups most affected are platform and security teams running AI workloads in public clouds, particularly those that have defaulted to the firewall their cloud provider supplies. The test did not measure AI traffic directly. The conclusion is an extrapolation from how the tested weaknesses interact with the traffic patterns CyberRatings expects agents to create.

    Reading a 0% Score Carefully

    A 0% Security Effectiveness score is striking, and it deserves precise interpretation rather than amplification. It reflects performance under one specific methodology, NSS Labs Cloud Network Firewall Test Methodology v4.1. That methodology used real-world exploits, evasions, malware, false-positive samples and sustained enterprise traffic loads. It measures how a product performed as configured for that test, at that point in time. It does not describe every possible deployment, and cloud providers frequently update their services.

    CyberRatings itself points to that dynamism. Its first recommendation to buyers is to test regularly, because continuous delivery pipelines let vendors ship fixes quickly but can also introduce regressions that quietly erode protection. The same logic cuts both ways: a low score today can improve, and a high score is not permanent. The organization’s advice to hold vendors accountable, and to treat a lack of transparency as a red flag, applies to every product on the list, including the Recommended ones.

    The practical takeaway is modest and concrete. Organizations relying on a native cloud firewall as their primary network control should validate exploit blocking, malware blocking, evasion resistance and TLS inspection against their own requirements. They should not treat the presence of the service as evidence of protection.

    Background

    CyberRatings.org is a non-profit membership organization that publishes independent ratings of security products, with NSS Labs generating its test results and reports. NSS Labs methodologies evaluate products against real-world attacks, evasions, malware and false-positive samples under sustained traffic loads. The resulting ratings of Recommended, Neutral and Caution combine protection results with value considerations such as price.

    Organizations running workloads in public clouds generally choose between two kinds of network firewall. One is the native service offered by the cloud provider, such as AWS Network Firewall, Azure Firewall or Google Cloud NGFW. The other is a third-party vendor’s virtual firewall deployed inside the cloud account. Native services integrate closely with the provider’s billing and management tools. Third-party products often mirror features that security teams already run in their own data centers.

    Sources

    Source: CyberRatings.org and NSS Labs Announce 2026 Cloud Network Firewall Test Results, CyberRatings.org’s announcement of its 2026 comparative test of nine cloud network firewalls, conducted by NSS Labs.

  • Google Breaks Ground in Kronstorf: Austria Joins the Map

    Google Breaks Ground in Kronstorf: Austria Joins the Map

    Google has begun construction on a data center in Kronstorf, a municipality in the Linz-Land district of Upper Austria, according to a groundbreaking announcement posted to the Google Cloud Press Corner and distributed on 23 April 2026. The item marks the start of physical work on the site.

    The release as circulated is a headline announcement. It does not, in the version distributed through news syndication, state the campus size, planned power capacity, capital commitment, construction timeline, staffing, or whether the facility will underpin a new Google Cloud region for Austria.

    Executive Summary

    Groundbreaking is the point at which a data center stops being a land holding and becomes a construction project. For a hyperscaler — an operator running compute at global scale, such as Google, Amazon Web Services, Microsoft or Meta — it normally implies that land control, planning permission and, critically, a grid connection agreement are already settled. Those are the hard parts. Steel and concrete are comparatively easy.

    The significance of Kronstorf is geographic more than technical. Europe’s data center industry has historically concentrated in five markets known as FLAP-D: Frankfurt, London, Amsterdam, Paris and Dublin. Those markets are now constrained less by demand than by electricity — grid connection queues, local moratoria and planning resistance have pushed new capacity outward into secondary markets with available power. Upper Austria, sitting on a hydro-heavy generation mix and on fiber routes between Munich, Vienna and northern Italy, fits that pattern.

    What the announcement does not do is tell buyers anything actionable. Google has not, as far as the distributed release states, committed to a launch date or to an Austrian cloud region. Enterprises with Austrian data residency requirements should treat this as an encouraging signal about Google’s intentions, not as a procurement input.

    Why Austria, and Why Now

    The proximate driver of hyperscale expansion into new European markets is power availability, not proximity to customers. Latency between Kronstorf and Frankfurt is a rounding error for most workloads; the difference that matters is whether a transmission operator can deliver tens of megawatts on a schedule the builder can plan around. In several established hubs it cannot. Dublin’s grid operator has restricted new data center connections in the Greater Dublin area for years, and Amsterdam imposed a construction pause that reshaped Dutch development. Frankfurt and London face their own queue and land pressures.

    Austria offers a different profile. Its electricity generation is unusually hydro-weighted by European standards, which is attractive both for carbon accounting and for price stability relative to gas-linked markets. Upper Austria is an industrial region with existing heavy-load infrastructure — the kind of grid that was built for manufacturing and can, in principle, be repurposed for compute. Kronstorf sits between Linz and Steyr, close to that industrial corridor.

    None of this is stated in the release. It is the standard site-selection logic of the sector, and it is the most plausible reading of the decision. Readers should hold it as inference, not as a company claim.

    What a Groundbreaking Actually Signals

    Announcements of this kind are frequently over-read in both directions. A groundbreaking is a stronger signal than a land purchase or a memorandum of understanding: capital has been committed, contractors are mobilised, and the permitting and interconnection work that typically consumes years has largely concluded. Hyperscalers do not break ground on sites they intend to abandon, and the sunk cost from this point forward rises steeply.

    It is a weaker signal than a service commitment. Large data center builds commonly run two to four years from groundbreaking to first customer traffic, and campuses are usually delivered in phases, with later buildings contingent on demand and on the operator’s capital plan at the time. A groundbreaking therefore says a facility is being built; it does not say when it will serve traffic, at what capacity, or which Google products will run on it.

    The distinction matters most for the question of a Google Cloud region in Austria. A physical data center and a published cloud region are related but separate things — regions require multiple availability zones, a defined service catalogue and a launch commitment. The release, as distributed, does not make that commitment, and the absence should not be filled in by assumption.

    Winners, Losers, and the Local Ledger

    The clearest beneficiaries are Austrian enterprises and public-sector bodies with data residency obligations, who gain a credible prospect of in-country hyperscale capacity, and the regional construction and electrical trades, who capture the build phase — the largest and shortest-lived share of employment any data center generates. Local landowners and the municipal tax base typically benefit as well.

    The competitive read is that Google is buying optionality in the DACH region rather than responding to a single anchor customer. Microsoft and AWS both hold established positions in German-language markets, and Vienna already hosts commercial colocation from international operators. Entering Austria with owned capacity changes Google’s cost structure and its sovereignty story simultaneously — owned facilities are cheaper at scale than leased ones and easier to make claims about.

    The costs land locally and are worth stating plainly rather than defensively. Large sites consume grid capacity, land and, depending on the cooling design, water; operational employment is modest relative to capital deployed. Communities that raise these points are asking legitimate questions, and the honest answer is that this release provides no basis to evaluate them in either direction. When Google publishes capacity, cooling method and water sourcing, those figures should be tested — and so should any counter-claims made about them.

    Reading a Thin Announcement Fairly

    It would be unfair to characterise this release as evasive. Groundbreaking announcements are ceremonial by convention across the industry, and operators routinely withhold capacity figures for competitive and security reasons. Google’s more detailed European disclosures have historically followed at launch rather than at first excavation.

    It would be equally unfair to present the announcement as more than it is. What is substantiated: construction has started at Kronstorf, and Google is the party announcing it. What is not substantiated by the release text: megawatts, euros, jobs, dates, cooling design, power procurement, and any regional service commitment. Coverage that supplies those numbers should be checked against a primary source.

    For infrastructure buyers, the practical posture is patience. Treat Kronstorf as evidence of Google’s medium-term intent in Central Europe, factor it into three-to-five-year architecture planning, and revisit when the operator publishes a launch date or a region announcement.

    Background

    Google operates a global network of owned data centers supporting Search, YouTube, Workspace and Google Cloud, with a substantial European footprint including sites in Ireland, the Netherlands, Belgium, Finland and Denmark. Its cloud business competes with Amazon Web Services and Microsoft Azure, where physical proximity and in-country capacity increasingly matter for regulated customers subject to data residency rules.

    Austria has hosted commercial colocation and enterprise data centers for years, largely concentrated around Vienna, but has not been a primary hyperscale construction market. The wider shift of European capacity toward secondary markets has been driven principally by electricity: as grid connections in Dublin, Amsterdam and Frankfurt became constrained, operators moved toward regions with spare transmission capacity and favourable generation mixes. Upper Austria, with its hydro-heavy power supply and existing industrial grid, sits squarely in that category.

    Source: Google Breaks Ground on Data Center in Kronstorf, Austria – Google Cloud Press Corner — Google’s groundbreaking announcement for a data center site in Upper Austria, published 23 April 2026.