Cloud has transformed how organizations build, deploy, and scale applications. It has also changed what they expect from security.

Through our work with AWS, Google Cloud, and other hyperscaler partners, we’ve had the opportunity to learn from organizations operating some of the most modern and complex cloud environments. While every organization takes a different approach to cloud adoption, customers consistently highlight a common set of expectations that are shaping the future of cloud security. That work took two significant steps this year with the launch of Imperva for Google Cloud in April and Imperva for AWS in August, both designed to keep traffic inside the cloud provider’s own network while it is inspected.

To explore those expectations further, I spoke with Eyal Cohen, Manager of Product Management for Application Security, whose team works closely with our hyperscaler partners and customers.

“The biggest thing we’ve learned is that customers don’t think in terms of security products anymore. They think about how security fits into the way they build and operate in the cloud. If security creates friction, they’ll look for another way.”

Eyal Cohen, Manager of Product Management, Application Security

Working closely with hyperscale cloud providers isn’t just about expanding routes to market or supporting new deployment models. It provides valuable insights into how cloud teams operate, the challenges they face, and what they expect from the technologies they rely on every day.

Three of those expectations come up in nearly every conversation.

Lesson 1: Customers expect consistent security outcomes, regardless of where applications run

For years, security strategies often assumed that consistency came from standardization. If environments looked the same, security would be easier to manage. Modern cloud organizations have shown that assumption no longer holds.

Applications now run across different cloud providers, environments, private infrastructure, and on-premises systems. These choices are usually deliberate. Different teams, applications, and business requirements demand different architectures. Customers are not looking for identical environments. They are looking for confidence that security outcomes remain consistent across them.

Multi-cloud security is the practice of applying one set of policies, controls and visibility to applications spread across two or more cloud providers and, for most organizations, across hybrid cloud and on-premises infrastructure as well. The infrastructure is plural by design; the security outcome has to be singular.

The question is no longer whether every workload runs on the same platform. The question is whether organizations can achieve the same level of visibility, governance, protection, and risk management regardless of where workloads reside.

This expectation spans the entire organization. CISOs need a consistent view of risk across the business. Cloud architects need the flexibility to support different technology choices without creating fragmented security models. AppSec and SecOps teams need consistent policies, controls, and visibility across environments. DevOps teams need security that follows applications without introducing new processes every time infrastructure changes.

One of the clearest lessons we’ve learned from cloud customers is that architectural diversity is becoming normal. What matters is not where applications run, but whether organizations can deliver consistent security outcomes wherever they run. The infrastructure may vary. The security outcome should not.

This is the principle behind how Imperva builds for hyperscaler environments. The same Web Application Firewall, API Security and Advanced Bot Protection run from one platform across public cloud, private cloud, hybrid and on-premises environments. Imperva for AWS deploys inline with Amazon CloudFront in minutes, inspecting traffic inside AWS before it reaches origins such as an Application Load Balancer or EC2, with no architectural changes. Imperva for Google Cloud integrates directly with Google Cloud Load Balancers through Service Traffic Extension, with no DNS changes, SSL reconfigurations or routing modifications. One policy set and one console, whichever cloud the application runs in.

Lesson 2: Customers expect security to fit the way they already work

Security initiatives often struggle for a simple reason: they ask engineering and operations teams to change how they work. Modern cloud teams already use Kubernetes, Infrastructure-as-Code, CI/CD pipelines, cloud-native services, and automated workflows. If adopting a security solution means redesigning an application, disrupting a pipeline, or introducing a parallel set of manual processes, consistent adoption becomes much harder. It is the same disconnect we described in Securing Applications Anywhere: Breaking Down the Wall of Confusion.

The impact spreads across the organization: architects get more complexity, DevOps teams face disruption to established processes, and AppSec and SecOps teams gain another tool and workflow to manage. CISOs may invest in a capability that is never adopted broadly enough to deliver the intended reduction in risk.

Security cannot sit outside the cloud operating model. It must integrate with the architectures, services, and workflows customers already use. That applies to deployment as much as day-to-day operation. Infrastructure-as-Code and automation are now standard practices for many cloud teams. Security must become part of those repeatable processes rather than depend on separate, manual tasks.

The strongest security does not force teams to choose between protection and operational efficiency. It makes protection part of how they already work.

That is why Imperva treats automation as a first-class deployment path rather than an afterthought. Imperva’s Terraform provider lets teams define Cloud WAF protection as code alongside the rest of their infrastructure. Imperva for Google Cloud is API-first and integrates with Terraform and existing DevOps workflows. And Imperva Elastic WAF deploys on Kubernetes, so protection ships inside the CI/CD pipeline rather than around it.

Lesson 3: Customers expect security to be easy to adopt, operate, and scale

Effective protection remains fundamental, but customers increasingly evaluate security across the entire lifecycle: how easily it can be evaluated, purchased, deployed, operated and scaled as requirements evolve.

Every stakeholder experiences that friction differently. CISOs need confidence that security investments will be adopted broadly enough to deliver meaningful risk reduction. Cloud architects need solutions that integrate cleanly with existing environments rather than creating new technology silos. DevOps teams want deployment models that align with automation, Infrastructure-as-Code, and existing delivery pipelines. AppSec and SecOps teams need strong protection without adding significant operational overhead.

Cloud marketplaces are one example of how customer expectations are changing. They can simplify procurement and help align security investments with existing cloud commitments. However, customers increasingly expect simplicity across the entire journey, from evaluation and deployment through day-to-day operations and long-term scale.

Imperva for AWS is available on AWS Marketplace as a SaaS offering with pay-as-you-go pricing, and Imperva for Google Cloud is available through Google Cloud Marketplace, so both can be procured alongside existing cloud commitments. Each deploys in minutes without architectural changes and is managed from the same console as every other Imperva-protected application. That is what turns “easy to adopt, operate and scale” from a slogan into a deployment plan.

The same principle applies at every stage. Security that is difficult to evaluate, deploy, operate, or scale will struggle to gain traction, regardless of its technical capabilities. The solutions most likely to succeed are the ones that fit naturally into how organizations already work.

When friction prevents security from being adopted consistently, it becomes more than an operational challenge. It becomes a security challenge.

Looking ahead

The most important lesson from working with cloud customers hasn’t been about any individual product, feature, or integration. It’s been understanding how expectations are evolving.

Modern cloud organizations expect consistent security outcomes regardless of where applications run. They expect security to fit naturally into the architectures and operating models they’ve already built. And they increasingly expect experiences that make security easy to adopt, operate, and scale.

As cloud environments continue to evolve, our focus is on helping customers maintain consistent security outcomes without limiting how or where they choose to build. Security should adapt to the realities of modern cloud operations, not require organizations to adapt to security.

That means helping customers protect applications across diverse environments, integrate security into existing workflows, and reduce the friction that can slow adoption and innovation.

The lesson isn’t that every organization should follow the same cloud strategy. It’s that regardless of the platforms, architectures, or operating models they choose, security should help them achieve the outcomes they need with the flexibility they expect.

“The cloud journey is still evolving, and so is security. By working closely with leading cloud providers and listening to the organizations using them every day, we’re continually learning what it takes to deliver security that supports innovation rather than standing in its way.”

– Eyal Cohen

Find out more about Imperva for Google Cloud and Imperva for AWS. Read the launch announcements: Thales Introduces Imperva for Google Cloud and Thales Launches Imperva for AWS. Running on Azure, in a private cloud or on-premises? The same protection is available through Imperva Web Application Firewall.

Multi-Cloud Security FAQ

What is multi-cloud security?

Multi-cloud security is the practice of applying consistent protection, visibility and policy to applications and APIs that run across more than one cloud provider, and usually across hybrid and on-premises infrastructure as well. The goal is the same security outcome regardless of where a workload runs, rather than a separate toolset and policy for each environment.

What are the biggest multi-cloud security challenges?

The challenges customers raise most often are fragmented visibility (a different console and policy per cloud), inconsistent controls that leave gaps between environments, security that does not fit Infrastructure-as-Code and CI/CD workflows, and the operational overhead of evaluating, deploying and scaling a separate solution in each cloud.

How does Imperva deliver consistent security across AWS, Google Cloud and on-premises?

Imperva delivers WAF, API Security and bot protection from one platform and one console. Imperva for AWS inspects traffic inline with Amazon CloudFront, Imperva for Google Cloud integrates with Google Cloud Load Balancers through Service Traffic Extension, and the same protection is available for private cloud and on-premises applications, so one policy applies everywhere.

Can Imperva be purchased through cloud marketplaces?

Yes. Imperva for AWS is available on AWS Marketplace as a SaaS offering with pay-as-you-go pricing, and Imperva for Google Cloud is available through Google Cloud Marketplace, which helps align security purchases with existing cloud commitments.

The post Three Lessons Cloud Customers Have Taught Us About Multi-Cloud Security appeared first on Blog.

Readiness is a visibility problem, and it’s one many organizations don’t know they have.

Most security controls tell you when they’re broken. A bad firewall rule lets traffic through that shouldn’t be there. An expired certificate generates alerts. A misconfigured WAF starts blocking legitimate users and someone notices pretty quickly.

DDoS protection is different. A service can be configured, licensed, and technically available, yet not actually be protecting your traffic. Worse, it often looks exactly the same as a fully functioning service until the moment an attack arrives.

That’s the challenge with DDoS readiness: confirming, continuously, that your traffic is actually flowing through your DDoS protection rather than assuming it is.

Attacks are loud. Protection gaps are silent.

DDoS readiness: why “protected” isn’t the same as “ready”

Ask an organization whether it’s protected from DDoS attacks and the answer is often based on two things:

• We have a DDoS protection service.
• It’s been configured.

Both may be true. Neither proves your traffic is actually protected. Readiness isn’t a checkbox. It’s an operational state that needs continuous validation. At Imperva, we view DDoS readiness through three simple questions:

1. Is traffic being advertised the way you expect?
2. Are the connections carrying protected traffic healthy?
3. Is traffic actually arriving where it should?

If you can’t answer all three, you’re making assumptions about your protection posture. That gap is behind many of the reasons DDoS protection fails just when it matters most.

This is different from DDoS testing. An attack simulation shows whether mitigation holds under load on the day you run it. Readiness monitoring answers a different question: whether the path to that mitigation is still intact today, and every day between tests. You need both.

1. Is your traffic being advertised correctly?

Whether you use always-on or on-demand protection, traffic has to be routed through the protection service, usually by advertising your network prefixes to it over BGP. Problems often emerge through gradual drift rather than obvious failures.

A prefix that should be advertised is no longer being announced. A routing change made during another project alters the traffic path. An on-demand configuration hasn’t been tested since the day it was set up. Nothing appears broken, no alarms sound, but traffic may no longer be following the path you think it is. And if an attack happens tomorrow, that’s the worst possible moment to discover it.

How to check: in Imperva DDoS Protection for Networks, the Connectivity dashboard shows the advertisement status of every protected prefix. Received means it reaches Imperva on at least two connections at two different PoPs. Received with issues flags problems such as a prefix advertised to a single PoP, or an on-demand prefix missing its no-export community. Not received means Imperva isn’t getting the advertisement at all. Status changes can be sent to you by email or to your SIEM.

2. Are your connections healthy?

Protecting traffic is only half the equation. Once traffic has been inspected and scrubbed, it still needs to reach your environment. The health of tunnels and connections plays a critical role in that process. A tunnel that’s technically up but suffering from packet loss, latency, or instability isn’t delivering the same outcome as a healthy connection.

Many organizations don’t discover these issues until traffic volumes increase or operational pressure rises. In other words, exactly when they need those connections most.

How to check: with performance monitoring enabled on a GRE tunnel connection, Imperva tracks latency, jitter and packet loss between its PoP and your network. You set the thresholds. When one is crossed, Imperva logs a “connection performance degraded” event and notifies you, with automated ping and traceroute results attached to the event.

3. Is traffic actually arriving?

This is often the most overlooked readiness check; many organizations monitor overall traffic levels and see healthy numbers across the environment. The dashboard looks green, total volume looks normal, but aggregate metrics can hide local problems.

A single point of presence (PoP) may receive significantly less traffic than expected because of routing changes, connection issues, or path degradation. In a global environment, that reduction might represent only a small percentage of total traffic and easily disappear into normal variation.

The dashboard stays green, while users in that region experience a very different reality. Monitoring expected traffic levels at the PoP level helps uncover these issues before they impact users or complicate response during an attack.

How to check: Imperva PoP Traffic Monitoring does exactly this. You set a minimum level of legitimate traffic for each protected network or IP (0–100 Mbps) and a minimum share of traffic for each PoP or group of PoPs. When traffic stays below a threshold for five minutes (the default), Imperva logs a “traffic dropped below threshold” event and notifies you.

Watch for too little, not just too much

Most DDoS detection systems are designed to identify excess: more traffic, more requests, more connections and more anomalies. The assumption is simple: when something goes wrong, volume increases, but readiness issues often present in the opposite way. Traffic stops arriving where expected, advertisements change, routes shift and connections degrade. But nothing spikes, nothing triggers traditional attack alerts.

The only signal is an absence. That’s why DDoS readiness requires a different mindset. Instead of asking:

“Is too much traffic arriving?”

you also need to ask:

“Is the expected traffic still arriving everywhere it should?”

That question can reveal problems long before an attacker does.

What changes when readiness becomes visible?

When readiness becomes visible, three things change. First, readiness becomes an operational consideration rather than an emergency discovery. Teams can identify issues during routine monitoring instead of during an active incident.

Second, on-demand protection becomes easier to validate. If attack-path activation is something you’ll depend on during a crisis, you need confidence that it will work before the crisis arrives. For on-demand ranges, Imperva also raises an event if flow monitoring data stops arriving, because DDoS detection for that range is inactive until it resumes.

Third, incident response improves. When an attack begins, teams aren’t wasting precious time figuring out whether protection was actually in place. They can focus immediately on responding to the threat.

The bottom line

Protection you can’t verify is protection you’re assuming.

That assumption can survive for months or even years because most days are quiet. Every uneventful day reinforces the belief that everything is working as expected. Then an attack arrives and turns that assumption into a test.

At Thales, we believe DDoS readiness is fundamentally a visibility problem. By continuously monitoring advertisement state, connection health, and traffic flow across locations, organizations can answer the critical question before an attacker forces it: is our DDoS protection actually on, everywhere it should be?

Discover how Thales Imperva DDoS Protection helps defend your applications and networks against increasingly sophisticated DDoS attacks while keeping critical services available.

DDoS readiness FAQ

What is DDoS readiness?

DDoS readiness is the verified, ongoing state in which your traffic is actually routed through, delivered by and arriving at your DDoS protection service, as opposed to a service that is only licensed and configured. It rests on three checks: route advertisement, connection health and traffic arrival at each PoP.

How can I tell if my DDoS protection is actually working?

Check three things continuously: that your prefixes are advertised to and received by the provider, that the tunnels or connections back to your network are healthy (latency, jitter, packet loss), and that expected traffic keeps reaching each PoP. Alert on drops, not just spikes.

How is DDoS readiness different from DDoS testing?

DDoS testing simulates an attack to check whether mitigation holds at one point in time. Readiness monitoring checks, every day, that the routing and connections mitigation depends on are still intact. One complements the other.

Does on-demand DDoS protection need readiness checks?

Yes, even more than always-on. On-demand protection only matters if activation works during an attack, so verify that your advertisements are correct (with Imperva, including the no-export community) and that flow monitoring data is still arriving. If it stops, attack detection for that range is inactive.

The post Is Your DDoS Protection Actually On? appeared first on Blog.