This article draws on survey data and commentary originally reported by networksasia.net, based on Barracuda Networks’ Firewalls and the Cloud report published in March 2018. While some statistics are now dated, the architectural challenges they describe remain relevant to cloud security strategy today.
Cloud Adoption Has Outpaced Traditional Security Thinking
Cloud computing is no longer an emerging trend — it is the operational baseline for most modern enterprises. Public cloud functionality expanded dramatically in the years following 2017, and with that growth came an urgent need to rethink how network security is designed, deployed, and managed.
The challenge is not simply technical. Organizations moving workloads from traditional data centers to public cloud environments often carry legacy assumptions about security architecture — assumptions that no longer hold in dynamic, API-driven infrastructure.
“For organizations that are used to operating under traditional data center architecture, moving to the cloud will require a new way of thinking when they approach security. Using security tools specifically designed for the public cloud can actually make a business more secure than they were when they operated purely on-premises.”
— Tim Jefferson, VP of Public Cloud, Barracuda Networks
What the Survey Data Revealed
Barracuda Networks’ Firewalls and the Cloud report, released in March 2018, surveyed over 600 IT professionals worldwide about their attitudes toward cloud security. Several findings stood out:
- 83% of respondents expressed concern about deploying traditional firewalls in the cloud. Their top pain points were pricing and licensing models that do not suit cloud economics, and a lack of integration that blocks cloud automation workflows.
- 74% of respondents identified integration with cloud management, monitoring, and automation capabilities as the single most important cloud-specific firewall capability.
- 59% of respondents said ease of deployment and configuration by cloud developers was a key requirement.
- 93% of organizations that had adopted DevOps, DevSecOps, or CI/CD pipelines reported challenges integrating security into those practices.
These numbers point to a structural mismatch: security tools designed for static, perimeter-based environments struggle to keep pace with the speed and flexibility that cloud-native development demands.
Why Traditional Firewalls Struggle in the Cloud
Perimeter-based firewall architectures are highly effective in conventional data centers, where network boundaries are well-defined and relatively static. In a public cloud environment, however, those assumptions break down quickly:
- Infrastructure is ephemeral. Virtual machines, containers, and serverless functions spin up and down dynamically. A firewall that requires manual configuration for each new resource becomes a bottleneck rather than a safeguard.
- Licensing models do not scale. Many traditional firewall vendors charge per appliance or per seat — models that are incompatible with elastic cloud environments where capacity fluctuates constantly.
- API-driven operations are the norm. DevOps teams expect security controls to be programmable via API, scriptable in infrastructure-as-code tools, and integrated into CI/CD pipelines. A firewall that requires a GUI-based workflow is an obstacle to delivery velocity.
- Multi-vector attacks demand layered defenses. Modern threats — including ransomware delivered via email, malicious downloads, or typo-squatted URLs — exploit multiple attack vectors simultaneously. Signature-based detection alone is insufficient; behavioral analysis and sandboxing are now baseline requirements.
What a Cloud-Generation Firewall Actually Needs
A firewall built for cloud environments needs to meet a different set of requirements than its data center counterpart. Based on the survey findings and vendor commentary, the key characteristics include:
- Native IaaS integration. The firewall should integrate directly with the management fabric of major cloud platforms (AWS, Azure, Google Cloud Platform), enabling automated provisioning and policy enforcement through native APIs.
- Consumption-based licensing. Licensing costs should only apply when resources are actively handling production traffic, not for standby or auto-scaled instances that are not yet in use.
- API-first design. Security teams and DevOps engineers should be able to deploy, configure, and manage firewall policies programmatically — using the same tools (Terraform, Ansible, Puppet, etc.) they use for the rest of their infrastructure.
- Multi-layer threat detection. Effective cloud firewalls combine signature-based detection, static analysis, behavioral analysis, and cloud-based sandboxing to catch polymorphic and zero-day attacks without degrading network throughput.
- Centralized management across environments. Organizations running hybrid architectures — with workloads spread across on-premises data centers and multiple cloud providers — need a single management interface to maintain a consistent security posture everywhere.
Integrating Security into DevOps and CI/CD Pipelines
The 93% figure — organizations with DevOps or CI/CD practices that struggled to integrate security — reflects a well-documented tension in the industry. Security has historically been treated as a gate at the end of the delivery process, while DevOps culture prioritizes continuous, incremental delivery.
Closing this gap requires security tools that can participate in the same automated workflows developers already use. For example, integrating a Web Application Firewall (WAF) with infrastructure automation tools — such as using a REST API to configure WAF rules as part of a deployment pipeline — allows security controls to be version-controlled, tested, and deployed alongside application code rather than bolted on afterward.
This approach, often described as DevSecOps, shifts security left in the development lifecycle: policy definitions live in code repositories, firewall rules are validated in staging before reaching production, and automated scans run as part of every build.
Understanding the Shared Responsibility Model
One of the most consequential — and frequently misunderstood — aspects of cloud security is the shared responsibility model. All major cloud providers (AWS, Azure, GCP) clearly delineate what security controls they manage and what remains the customer’s responsibility.
In general terms:
- The cloud provider is responsible for the security of the cloud — physical infrastructure, hypervisors, and core platform services.
- The customer is responsible for security in the cloud — operating systems, applications, data, identity and access management, and network controls.
This means that moving a workload to a public cloud does not transfer the security obligation to the provider. Organizations must still apply appropriate firewall rules, patch their operating systems, manage access credentials, and monitor for threats — the cloud simply changes where and how those controls are implemented.
“All the major cloud providers clearly state the security controls that customers inherit with their platforms. It’s important to understand that if your data and applications are in the cloud, it’s your responsibility to secure them.”
— Tim Jefferson, VP of Public Cloud, Barracuda Networks
Key Takeaways for DevOps and Platform Engineering Teams
- Audit your current firewall and network security tooling against your actual cloud deployment model. If your tools require manual, GUI-based configuration, they are likely slowing down delivery and creating gaps in coverage.
- Evaluate firewall solutions on their API capabilities and native cloud platform integrations, not just their feature set in isolation.
- Make the shared responsibility model explicit in your team’s documentation and runbooks. Assumptions about what the cloud provider secures by default are a common source of misconfiguration incidents.
- Treat security policy as code. Firewall rules, WAF configurations, and access control lists should live in version-controlled repositories and be subject to the same review and testing processes as application code.
- Adopt a multi-layer defense posture. No single control — firewall, WAF, EDR, SIEM — is sufficient on its own. Layering controls that share threat intelligence reduces the risk from multi-vector attacks.