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.