Cloud security, also known as cloud computing security, is a collection of security measures designed to protect cloud-based infrastructure, applications, and data. These measures ensure authentication of users and devices, access control for data and resources, and protection of data privacy. They also support data regulatory compliance.

But as companies move more data and applications to the cloud, IT professionals remain concerned about security, governance, and compliance issues when their content is stored in the cloud. They worry that highly sensitive business information and intellectual property may be exposed through accidental leaks or due to increasingly sophisticated cyber threats.

A crucial component of cloud security is focused on protecting data and business content, such as customer orders, secret design documents, and financial records. Preventing leaks and data theft is critical for maintaining your customers’ trust, and for protecting the assets that contribute to your competitive advantage.

Maintaining a strong cloud security posture helps organizations achieve the now widely recognized benefits of cloud computing: lower upfront costs, reduced ongoing operational and administrative costs, ease of scaling, increased reliability and availability, and a whole new way of working.

To actually reap the rewards of these benefits, the journey to the cloud must be secured in such a way, that the proliferation of connected devices coupled with today’s vanishing perimeter and ever-changing threat landscape do not overly complicate an already complex environment for organizations to secure. This is where VMware come in.

VMware allows you to access any cloud while maintaining the highest level of consistency for infrastructure, operations and developer experience. With VMware, you have the freedom to build and deploy modern applications, from the data center to multiple cloud and edge environments. Migrate seamlessly between environments and ensure that all data and applications remain secure and protected in any cloud.

Vmware also allow you to match your applications to the unique strengths of any environment. With the most hybrid cloud options—delivered with key partners like AWS, Azure, Google Cloud, IBM Cloud and Oracle Cloud—you can access the power of leading hyperscale clouds within proven VMware infrastructure.

One critical principle that VMware employ is that the measures shouldn’t be so rigid that users have to find workarounds to do their jobs. When security controls make a cloud computing solution difficult to use, users figure out ways of working around the controls, thereby rendering the system insecure. As experts point out, users are often the weakest link in any security system.

As organizations rapidly adopt cloud networks, due to flexibility, scalability, cost effectiveness and more, security needs to be at the front and centre. It is against this background that the virtual Cloud & Security Forum 2020 is designed to assist in driving an impartial and informed dialogue in the rapidly evolving information security industry. The virtual event will unfold on the 18th and 19th of March.

Having continued to create an environment for making new connections, the summit with visionary speakers at the nexus of new technologies and cyber security solutions purposes to share their insights and demonstrate their ability to safeguard customer data.

From new applications being consistently added to networks to employees taking access control shortcuts and credentials being compromised, it is clear that there are endless vulnerabilities to detect and manage.

What Is AWS Security Hub?

Amazon Web Services (AWS) operates on a shared security responsibility model: AWS secures the underlying cloud infrastructure, while subscribers are responsible for securing everything they deploy inside that infrastructure. In practice, fulfilling that subscriber responsibility is complex—AWS spans hundreds of individual services, each with its own security controls, configuration options, and threat surface.

AWS Security Hub addresses this complexity by aggregating and normalizing security findings from across AWS services into a single, unified console. Instead of juggling separate dashboards for Amazon GuardDuty, AWS Config, Amazon Inspector, and others, Security Hub collects their outputs, correlates them, and presents a coherent picture of your security posture.

Key Capabilities

• Centralized findings: Ingests security alerts from native AWS services (GuardDuty, Inspector, Macie, Firewall Manager) and supported third-party tools into a standardized format.
• Compliance scoring: Automatically runs checks against recognized security standards and gives each standard a percentage score showing how well your environment meets its controls.
• Severity classification: Findings are categorized as Informational, Low, Medium, High, or Critical, so teams can prioritize remediation effort.
• Remediation guidance: Each finding links to step-by-step remediation instructions, reducing the time between detection and resolution.
• Continuous monitoring: Checks run on an ongoing basis, so your compliance scores update as you make changes to your environment.
• Multi-account support: Security Hub can be configured to aggregate findings across all accounts in an AWS Organization.

Enabling AWS Security Hub

Security Hub is available in the AWS Management Console under Security, Identity, and Compliance. When you launch it for the first time, the setup wizard asks you to select the security standards you want to evaluate your environment against.

Supported Security Standards

At the time of the original article, the standards available included:

• AWS Foundational Security Best Practices (FSBP) – AWS-curated controls covering common misconfigurations across core services.
• CIS AWS Foundations Benchmark – The Center for Internet Security benchmark for AWS accounts.
• PCI DSS – Controls relevant to environments that handle payment card data.

Note: AWS periodically adds new standards. Check the current AWS Security Hub documentation for the latest list.

An important caveat: Security Hub uses automated checks to evaluate compliance, but not every requirement of a given standard can be validated automatically. Human review and additional audit procedures remain necessary for full compliance attestation.

After selecting your standards, click Enable Security Hub. The service activates immediately and begins running its automated checks.

Navigating the Security Hub Dashboard

Summary Screen

The default view after enabling Security Hub is a summary screen that provides a high-level overview of detected security issues across your AWS environment. In a production account with active resources, this screen will display aggregated finding counts broken down by severity and by integrated service.

Security Standards Tab

The Security Standards tab is one of Security Hub’s most actionable views. It lists each enabled standard alongside a security score—a percentage reflecting how many of the standard’s automated controls your environment currently passes. A score close to 100% indicates strong alignment; a low score (such as the 6% example from a nearly empty lab environment noted in the original article) flags significant gaps that need attention in a production context.

Drilling into a standard reveals individual controls organized by severity:

• Critical – Immediate action required; exploitation risk is high.
• High – Significant vulnerability that should be remediated promptly.
• Medium – Notable misconfiguration with moderate risk.
• Low / Informational – Best-practice recommendations with lower immediate risk.

You can filter the findings list by severity or status (Failed, Passed, Unknown, Not Available) to focus remediation work.

Remediation Instructions

Clicking any individual finding opens a detail pane that lists the specific AWS resources where the issue was detected. A Remediation Instructions link navigates directly to the AWS documentation for that control, providing step-by-step guidance for fixing the problem. Because Security Hub re-evaluates controls continuously, a resolved finding will eventually move to a Passed state and contribute positively to your compliance score.

Understanding Security Hub Costs

AWS charges for Security Hub based on the number of security checks performed per month and the number of finding ingestion events processed. While the per-unit cost is low, the volume of checks in a large, active AWS environment can accumulate meaningful charges.

To monitor your spend:

1. Open Settings inside Security Hub.
2. Select the Usage tab.
3. Review your current-month usage, the estimated monthly cost, and the applicable pricing tier.

Security Hub also offers a 30-day free trial for new accounts (verify current trial terms in the AWS pricing page, as these may change). It is possible to disable Security Hub from the General tab in Settings, though doing so is rarely advisable in production environments where continuous monitoring is essential.

Integration with the Broader AWS Security Ecosystem

Security Hub does not perform its own threat detection—it is an aggregation and normalization layer. Its value scales with the number of integrated services and partner tools feeding into it. Common integrations include:

• Amazon GuardDuty – Threat detection based on CloudTrail, VPC Flow Logs, and DNS logs.
• Amazon Inspector – Automated vulnerability assessments for EC2 instances and container images.
• Amazon Macie – Sensitive data discovery and protection for S3.
• AWS Config – Resource configuration history and compliance rules.
• AWS Firewall Manager – Centralized firewall policy management.
• Third-party SIEM and security tools – Many vendors support the AWS Security Finding Format (ASFF) for direct ingestion into Security Hub.

Getting the Most from Security Hub

• Enable all relevant integrations before reviewing your initial score. A partially integrated Security Hub will underreport findings and give a misleadingly high score.
• Prioritize Critical and High findings first. Use severity filters to create a structured remediation backlog.
• Set up EventBridge rules to route critical findings to a ticketing system or PagerDuty for automated alerting.
• Use AWS Organizations integration to aggregate findings from all member accounts into a designated administrator account for centralized visibility.
• Track score trends over time. Security Hub scores should improve as you remediate issues; a declining score signals new misconfigurations or newly enabled checks.

Video: AWS Security Hub Overview

About the Original Author

The original article was written by Brien Posey, a 16-time Microsoft MVP with decades of IT experience. Posey has written thousands of articles and contributed to dozens of books on IT topics. He previously served as CIO for a national chain of hospitals and as a network administrator for major insurance companies and for the Department of Defense. He has also pursued training as a commercial scientist-astronaut candidate. The original article appeared on virtualizationreview.com.

The Security Gap That Containers and Kubernetes Are Creating

The rapid adoption of containers and orchestration platforms like Kubernetes is outpacing the security practices designed to protect them. According to research from the Cloud Security Alliance (CSA) presented at RSA Conference 2020, development and operations teams are deploying containerized workloads at scale — but many organizations have not yet adapted their security models to match the complexity this creates.

John Yeoh, Global Vice President of Research at the CSA, summed up the core tension: segmenting applications into containers and microservices delivers clear functional and scalability benefits, but it simultaneously multiplies the number of components that must be secured and made compliant.

“As we have seen with the use of containers and micro-services and compliance, when you further segment things off, there’s a functionality benefit from that. But you also have a lot more pieces to secure or to make compliant. So the challenge is how do we grant proper access control to containers and micro-services? How do we make these environments compliant?”

— John Yeoh, Global VP of Research, Cloud Security Alliance

Why Access Control Is the Central Problem

Containers are designed to be lightweight, portable, and numerous. In a busy Kubernetes cluster, dozens or hundreds of containers may run simultaneously across many nodes. This creates a sprawling attack surface where default configurations — including default security settings and default access controls — may be far more permissive than the sensitivity of the data being handled requires.

Yeoh points to a specific and well-documented attack pattern: an adversary compromises one container and then pivots laterally to others within the same cluster. Over-provisioned permissions — whether through misconfigured Role-Based Access Control (RBAC) policies, exposed Kubernetes API servers, or overly broad service account tokens — are frequently the enabler.

“We see breaches and incidents all the time when it’s compromised credentials or something really silly like, ‘Why does the attacker have that much access when they penetrate one environment?’ If we can address that and limit that, we’re going to be much better off.”

— John Yeoh, Cloud Security Alliance

Common Access Control Failures in Container Environments

• Overpermissive RBAC policies: Granting cluster-admin or broad namespace access when narrower roles would suffice.
• Default service account tokens auto-mounted: Kubernetes mounts service account tokens by default; many workloads that don’t need API access still receive it.
• Unrestricted inter-pod communication: Without Network Policies, every pod can reach every other pod in a namespace.
• Exposed Kubernetes API server: Publicly reachable API endpoints without strong authentication have been exploited in documented incidents.
• Secrets stored in plain text: Credentials embedded in container images or environment variables rather than managed through a secrets manager.

Shifting Security Left: Building It Into the Development Cycle

The CSA’s position — consistent with the broader DevSecOps movement — is that security must be addressed as early as possible in the software development lifecycle, not bolted on after deployment. Yeoh describes a model where automated checks are embedded directly into CI/CD pipelines, and where code with security problems can be rolled back before it ever reaches production.

“You are also able to automate a lot of these [checks] as well, and you can almost create a self-healing architecture, where it rolls back, is fixed and then moves forward. We’re seeing more and more people do that in cloud environments. It’s a way to make sure that developers are held accountable.”

— John Yeoh, Cloud Security Alliance

In practical terms, this means integrating tooling at several stages of the pipeline:

• Image scanning: Scanning container images for known CVEs before they are pushed to a registry (tools such as Trivy, Clair, or Snyk Container).
• Static analysis: Linting Kubernetes manifests and Dockerfiles for security misconfigurations (tools such as kube-score, Checkov, or Kubesec).
• Admission controllers: Using Kubernetes admission webhooks (e.g., OPA/Gatekeeper, Kyverno) to block non-compliant workloads from being deployed to the cluster at all.
• Runtime security: Monitoring container behaviour at runtime to detect anomalous system calls (tools such as Falco).
• Automated rollback: GitOps workflows that can detect a failed or insecure deployment and roll back to a known-good state automatically.

Compliance in a Containerized World

Container environments present compliance teams with a challenge that traditional VM-based infrastructure did not: workloads are ephemeral. A container may run for seconds or minutes and leave no persistent audit trail unless that logging is explicitly configured. This makes meeting the audit and data-residency requirements of regulations such as the California Consumer Privacy Act (CCPA) and the New York SHIELD Act — both discussed at the CSA’s RSA 2020 sessions — significantly more complex.

Attorney Aravind Swaminathan, Global Co-Chair of the cyber, privacy and data innovation practice at Orrick Herrington & Sutcliffe LLP, highlighted a broader issue for organizations moving to cloud: users and organizations do not own the underlying infrastructure, which changes the risk model fundamentally.

“There’s tons of value in the cloud, but you have to understand the risks. We have recently seen individuals compromise the cloud environment when we thought we had protections like multifactor authentication and certain controls, and attackers were able to make end-runs around those. And that’s the challenge.”

— Aravind Swaminathan, Orrick Herrington & Sutcliffe LLP

Practical Recommendations for DevOps and Security Teams

Based on the challenges identified by the CSA and the speakers at RSA 2020, the following practices reflect the direction the industry is moving:

1. Apply least-privilege RBAC: Audit every Kubernetes role and cluster role binding. Grant only the permissions a workload genuinely needs.
2. Disable auto-mounting of service account tokens on pods that do not need to communicate with the Kubernetes API.
3. Implement Network Policies: Default-deny all ingress and egress traffic, then explicitly allow only required flows.
4. Scan images before deployment: Block images with critical or high CVEs from reaching production registries.
5. Use a secrets management solution: Avoid embedding credentials in images or manifests; use a dedicated secrets store integrated with your cluster.
6. Enable audit logging: Kubernetes audit logs and container runtime logs should be shipped to a centralized, tamper-resistant store for compliance and incident response.
7. Adopt a DevSecOps pipeline: Make security gates part of CI/CD so that developers receive fast feedback and policy is enforced consistently.
8. Plan for regulatory requirements early: Map data flows through your containerized architecture to understand where regulated data lives and how ephemeral workloads affect audit trails.

The Road Ahead

The security challenges that containers and Kubernetes introduce are not insurmountable, but they do require a deliberate shift in how security is resourced and when it is applied. The CSA’s research presented at RSA 2020 reflects a consensus view that is still relevant today: security teams must evolve from gatekeepers who review finished applications to engineers who build security requirements directly into the development process. Self-healing pipelines, automated compliance checks, and granular access control are no longer aspirational — they are operational requirements for any organization running containerized workloads in production.

Original reporting by BankInfoSecurity. Cloud Security Alliance research was presented at RSA Conference 2020, San Francisco.

Overview: Free Cloud Computing Course from IIT Kharagpur

IIT Kharagpur, under the Ministry of Human Resource Development’s (MHRD) National Programme on Technology Enhanced Learning (NPTEL) initiative, announced a free online course on cloud computing open to eligible students across India.

NPTEL is a joint initiative of MHRD and seven Indian Institutes of Technology — Bombay, Delhi, Kanpur, Kharagpur, Madras, Guwahati, and Roorkee — along with the Indian Institute of Science (IISc). Its mission is to deliver high-quality technical education to any learner interested in IIT-standard content, at no cost.

Course Details

• Duration: 8 weeks (24 February 2020 – 17 April 2020)
• Instructor: Prof. Soumya K. Ghosh, Department of Computer Science and Engineering, IIT Kharagpur
• Platform: NPTEL online learning portal
• Cost to enroll: Free

Prof. Soumya K. Ghosh has a background in satellite remote sensing and geographic information systems, having previously worked with the Indian Space Research Organization (ISRO) before joining IIT Kharagpur.

Who Is Eligible?

The course targets engineering undergraduates and postgraduate students from the following streams:

• Computer Science and Engineering
• Electronics Engineering
• Electrical Engineering

Prospective students should have foundational knowledge of:

• Computer architecture and organization
• Computer networking fundamentals

Curriculum: What the Course Covers

The 8-week course spans both foundational and advanced cloud computing topics:

1. Introduction to Cloud Computing — core concepts, definitions, and the evolution of cloud services
2. Cloud Computing Architecture — layered architecture, deployment models (public, private, hybrid)
3. Service Management in Cloud Computing — SLAs, provisioning, and lifecycle management
4. Data Management in Cloud Computing — storage models, distributed data, consistency
5. Resource Management in Cloud — scheduling, load balancing, and virtualization
6. Cloud Security — threat models, identity management, data privacy
7. Open Source and Commercial Clouds — overview of platforms such as OpenStack alongside commercial providers
8. Cloud Simulator — practical simulation tools used in cloud research
9. Research Trends in Cloud Computing — emerging directions in the field
10. Fog Computing — edge and fog computing paradigms and their relationship to cloud

How to Earn a Certificate

Enrolling in and completing the online course is entirely free. However, students who want an officially recognized certificate bearing the IIT Kharagpur and NPTEL logos — and AICTE-approved FDP credit — must follow an additional process:

Step 1: Register for the Proctored Exam

Students must register separately and appear in person at a designated examination centre. The exam fee is Rs 1,000.

• Exam date: 26 April 2020
• Morning session: 9:00 AM – 12:00 Noon
• Afternoon session: 2:00 PM – 5:00 PM

Step 2: Meet the Scoring Criteria

To qualify for the certificate, candidates must satisfy the following criteria:

• Assignment score: Minimum 25% of the average of the best 6 assignments out of 8 total
• Exam score: Minimum 75% of the proctored certification exam score (out of 100)
• Final score: Average assignment score + exam score

Candidates who meet both thresholds receive a certificate co-branded by IIT Kharagpur and NPTEL.

Why This Course Matters for DevOps and Cloud Engineers

Cloud computing is foundational to modern DevOps practice. Understanding cloud architecture, resource scheduling, data management, and security directly supports roles in platform engineering, infrastructure automation, and site reliability engineering. Courses like this one from IIT Kharagpur provide structured, academically rigorous coverage of these topics — an asset whether you are building skills from scratch or reinforcing existing knowledge with a recognized credential.

NPTEL regularly offers updated runs of popular courses. If you missed this 2020 session, visit nptel.ac.in to check for current or upcoming cloud computing courses.

Cloud Adoption Is Accelerating — But So Are the Risks

The public cloud market has been on a sustained growth trajectory, driven by major platforms from Amazon (AWS), Microsoft (Azure), and Google (GCP). Yet beneath the headline growth figures lies a more complicated story: the organizations migrating to the cloud are frequently introducing the very security vulnerabilities they hoped to avoid.

According to figures cited in the original interview, nearly half of organizations surveyed had experienced a cloud security incident, and a significant share had considered moving data back on premises as a result. With half of companies storing personally identifiable information (PII) in the cloud, and roughly a quarter storing payment data there, the stakes are high.

George Burns III, a Senior Consultant of Cloud Operations at SPR, offers a practitioner’s perspective on what those risks actually look like and how engineering and IT leadership teams should respond.

How Fast Is the Cloud Market Growing?

Burns describes cloud growth as broad and sustained across most market segments, with new workloads increasingly being born in the cloud rather than migrated to it. As that shift matures, overall growth rates are expected to stabilize into a more predictable maintenance curve for established services.

The most significant growth potential, Burns argues, lies in emerging technologies:

• Edge computing: Extending compute and data resources closer to end users and devices for lower latency and better experiences.
• IoT infrastructure: The growing fleet of Internet-connected devices and the cloud platforms that support them represent a major new deployment surface.
• AI and ML workloads: The explosion of artificial intelligence and machine learning has directly influenced hardware design — particularly GPUs — and how cloud data centers are architected.

Who Are the Major Players?

Burns identifies the three dominant public cloud providers as AWS, Microsoft Azure, and Google Cloud Platform (GCP). Beyond the hyperscalers, he notes that industry-specific players carry significant weight in their own domains — for example, Epic Systems in the electronic medical records space.

Oracle’s influence extends into cloud through its widely deployed Oracle and MySQL database products. Hardware manufacturers also play a shaping role: as data centers expand and AI workloads grow, chip design itself is being influenced by cloud infrastructure trends.

Storage is another area of active evolution. As data volumes grow and data ages, tiered storage strategies have emerged — with low-cost, high-latency solutions for cold archival data, and high-speed technologies like NVMe over network fabrics addressing the demand for sub-millisecond latency at the hot end.

The Real Source of Cloud Security Risk

Burns makes a distinction that is worth internalizing: the cloud platform itself is rarely the source of risk. The risk lives in the connective tissue — the integrations, configurations, and human decisions that tie platforms and products together.

This is a pattern that DevOps and platform engineering teams encounter repeatedly. Misconfigurations, overly permissive IAM policies, unreviewed third-party dependencies, and undocumented change processes create far more incidents than vulnerabilities in the underlying cloud infrastructure.

Burns identifies several concrete areas of focus:

• Documentation and change management: Maintaining accurate, up-to-date records of infrastructure state is foundational to security. Configuration drift is a common vector for incidents.
• Certificate authorities and trust chains: The integrity of trusted CAs matters more as cloud-connected systems multiply. Any erosion of that trust chain creates systemic exposure.
• Data flow mapping: You cannot secure what you cannot see. A complete understanding of how data moves through your infrastructure — including across third-party integrations — is a prerequisite for effective security posture.
• Vendor and partner vetting: Working with certified, knowledgeable partners is not optional. An insecure partner with access to your environment is a direct security risk to your platform.

How Many Businesses Have Been Affected?

Burns is candid: “More businesses have been impacted by cloud security issues than we’ll ever be able to accurately count.” He argues that the concept of “cloud security” now encompasses almost any data leak or breach scenario, because the cloud touches nearly every layer of modern business infrastructure.

Not every organization will detect every incident. Some breaches stem from under-resourced security teams that lack the tooling or expertise to identify threats. Others originate in failed business relationships — a compromised vendor, a poorly scoped contractor, a misconfigured SaaS integration.

Burns’s position is direct: every business will eventually experience a cloud security gap. Many already have, whether they know it or not.

Practical Steps to Reduce Cloud Security Exposure

Burns outlines a practical framework for reducing risk, applicable to both cloud providers and their customers:

1. Work with certified practitioners. Cloud platforms evolve rapidly, and the skill sets required to operate them securely are specific and often platform-dependent. Ensure the people managing your infrastructure hold current certifications and have hands-on platform experience.
2. Conduct regular security reviews and audits. One-time assessments are insufficient. Scheduled, recurring audits help surface configuration drift, access control issues, and newly introduced vulnerabilities before they become incidents.
3. Build security into your deployment processes. Integrating security review into CI/CD pipelines and infrastructure-as-code workflows reduces the window between introducing a vulnerability and detecting it.
4. Maintain visibility into your full data footprint. Know where your sensitive data lives, who has access to it, and how it flows between services and partners.

What the Future Looks Like for IT Leaders

Burns frames the challenge for IT leadership as a balancing act: “The stability of the proven versus the promise of the new.” Emerging technologies attract attention and often drive genuine competitive advantage, but they also carry unknown risk profiles and are more likely to have unpatched vulnerabilities or immature security tooling.

His prescription for successful IT leadership: embrace change, but do so within a framework of deliberate security and stability governance. Public cloud will remain the default deployment target for most organizations. The leaders who navigate this well will be those who can evaluate and adopt new capabilities without sacrificing the operational discipline that keeps their platforms secure.

Key Takeaways for DevOps and Platform Teams

• Cloud platforms are generally well-hardened. Your configuration, access controls, and integrations are the attack surface.
• Misconfiguration and human error — not infrastructure vulnerabilities — drive the majority of cloud security incidents.
• Regular audits, certified practitioners, and complete data flow documentation are non-negotiable baseline practices.
• Every organization operating in the cloud should assume they have already experienced a security gap, and invest accordingly in detection and response capabilities.
• IT leaders must balance innovation adoption with operational security discipline — neither pure conservatism nor unchecked experimentation serves the organization well.

Original interview conducted by Digital Journal. Statements attributed to George Burns III, Senior Consultant of Cloud Operations, SPR.

Cloud Computing Entering 2020: A Maturing but Still-Evolving Market

Cloud computing has been a top-tier IT trend since Amazon Web Services launched its S3 object storage service in late 2006. Before that, the Application Service Provider (ASP) model attempted to deliver hosted software, but it was fragile and unreliable. It took years of iteration, investment, and hard lessons for cloud providers to build the robust, enterprise-grade platforms we rely on today.

By 2020, cloud was no longer an emerging technology — it was foundational infrastructure. Nearly every connected device interaction touched a cloud service in some way. Yet the market was still far from fully mature, and 2020 promised meaningful changes in how cloud was delivered, secured, and consumed.

Two themes dominated the cloud conversation heading into the year: security and customisation. The following sections break down the key trends that shaped the cloud landscape in 2020.

1. Hyperscale Infrastructure Partnerships

A significant shift was underway among SaaS vendors that had historically managed their own infrastructure. Rather than competing on raw infrastructure capability — a race that only a handful of hyperscalers could realistically win — many enterprise SaaS providers began consolidating onto major public cloud platforms.

A clear example cited at the time was Infor building its CloudSuite product on AWS. Similarly, Salesforce was migrating more of its backend workloads to AWS infrastructure, and Microsoft’s Office 365 runs on Azure. The logic is straightforward: if a SaaS vendor’s competitive advantage is in application design and domain expertise, spending engineering resources on undifferentiated infrastructure is a poor use of capital.

Early regional partnerships reinforced the trend. Workday partnered with AWS in Canada, and Salesforce aligned with Alibaba Cloud in China — both deals reflecting the reality that SaaS vendors need local infrastructure presence to meet data sovereignty and latency requirements without building it themselves.

For DevOps and platform engineers, this trend meant a growing expectation to operate on hyperscale clouds rather than bespoke or co-located infrastructure.

2. Cloud-Native Applications and Microservices

The push towards cloud-native application design accelerated in 2020. Rather than lifting and shifting monolithic applications to the cloud, development teams were increasingly expected to decompose applications into smaller, independently deployable services.

This microservices approach offered several concrete benefits:

• Independent scaling: Individual services can scale horizontally based on actual demand without scaling the entire application.
• Fault isolation: A failure in one service does not necessarily cascade across the entire system.
• Technology flexibility: Teams can choose the best runtime or language for each service rather than being locked into a single stack.
• Faster deployment cycles: Smaller, decoupled units are easier to test, deploy, and roll back.

Beyond internal decomposition, SaaS vendors were beginning to co-develop complementary service packages. Where two providers served related but distinct business functions, joint offerings gave enterprise customers pre-integrated solutions rather than bespoke point-to-point integrations.

3. Software-Defined Everything and the Hybrid Cloud

Hyperconvergence — collapsing compute, storage, and networking into a single hardware appliance — had been a dominant data centre trend for several years. By 2020, a new architectural concept was gaining traction: treating the physical location of hardware as increasingly irrelevant, with software defining how all resources were provisioned, connected, and managed.

The practical expression of this shift was the rise of hybrid cloud as a first-class architecture, not a transitional state. Organisations were designing workloads with the explicit assumption that compute could run on-premises, in a public cloud, or at the edge — and that software orchestration would abstract away those differences.

For DevOps teams, this translated into investment in tooling and platforms that supported consistent deployments across environments: Kubernetes federation, infrastructure-as-code that targeted multiple providers, and unified observability across hybrid footprints.

4. Cloud Security: From Checkbox to Core Capability

Cloud security was already a pressing concern before 2020, and a series of high-profile breaches — including incidents involving major cloud service providers — brought the issue into sharp focus. The lesson was clear: traditional perimeter security controls such as firewalls and basic access controls were insufficient in cloud-scale, multi-tenant environments.

The areas where cloud providers and their customers were expected to invest more heavily in 2020 included:

• Multi-factor authentication (MFA): Moving beyond single-factor credential access, especially for privileged accounts and APIs.
• Network segmentation: Enforcing strict boundaries between workloads and tenants, even within the same cloud account or VPC.
• Encryption in transit and at rest: Applying cryptographic controls to all data paths, not just external-facing ones.
• Threat intelligence and behavioural analysis: Using machine learning and telemetry to detect anomalous access patterns before a breach is confirmed.
• Role-based access control (RBAC): Segmenting data and control planes so that each user or service has only the minimum permissions required.

Even a single significant breach carried reputational damage far beyond the directly affected organisation — it raised questions about cloud trust across the entire market. Cloud security was therefore framed not just as risk management but as a commercial imperative for providers wanting to attract risk-averse enterprise customers.

5. High-Performance Computing (HPC) Moves to the Cloud

High-performance computing workloads — traditionally the domain of on-premises supercomputing clusters and specialised hardware — were beginning to migrate to the public cloud by 2020. For years, HPC in the cloud was considered impractical: the infrastructure requirements were enormous, the demand was bursty and unpredictable, and building out dedicated clusters for short job runs was cost-prohibitive.

That changed as AWS, Microsoft Azure, and Google Cloud all added HPC-specific services and instance families, enabling organisations to provision massive compute capacity on demand and decommission it when the job was finished. Use cases driving this shift included:

• Weather forecasting and climate modelling
• Financial risk analysis and Monte Carlo simulations
• Genomics research and drug discovery
• Precision agriculture (e.g., analysing sensor data to optimise planting decisions)
• Computational fluid dynamics in engineering

The economics of cloud-based HPC are compelling: rather than purchasing and depreciating expensive specialised hardware that sits idle between jobs, teams pay only for the compute time they use.

The original source cited a claim that HPC cloud usage was expected to increase by approximately 40% in 2020, and that around 36% of infrastructure decision-makers ran HPC workloads in the cloud in 2018. These figures were attributed to a Forrester report but could not be independently verified for this article.

Looking Back: What These Trends Tell Us

Reviewing these 2020 predictions from a post-hoc perspective, most held up well. Hyperscale partnerships between SaaS vendors and major cloud providers deepened significantly. Cloud-native and microservices architectures became the default for greenfield development. Security investment increased across the industry, driven by continued high-profile incidents. And HPC workloads did migrate to the cloud in meaningful numbers, accelerated further by the pandemic-era surge in remote scientific computing.

For DevOps practitioners, the overarching theme is consistent: the cloud is not a destination but an operating model. The teams that thrived were those that built for cloud-native patterns from the start, automated security controls into their delivery pipelines, and treated infrastructure as software — manageable, testable, and version-controlled.

The Comfort Problem

Postman’s annual developer survey has consistently found that developers feel broadly comfortable with the level of API security their organization has implemented. On the surface, that sounds reassuring. In practice, it should set off alarm bells.

The core issue is structural: most organizations place API security and management responsibilities squarely in the hands of developers. In a fast-moving Agile or DevOps environment — where code ships continuously, infrastructure changes daily, and complexity compounds at every layer — that sense of comfort can become a liability. Feeling secure is not the same as being secure.

You Are Only as Secure as Your Weakest Link

API security does not exist in isolation. A modern API-driven system involves a long chain of components, each of which can become a point of failure:

• User credentials and session tokens
• TLS/SSL configuration and certificate management
• Authentication and authorization logic in client applications
• Server-side credential storage and secret management
• Third-party APIs and external service integrations
• Code injection and input validation weaknesses
• Access control policies in API gateways

It only takes one vulnerable code iteration in one client instance to expose every API that instance has access to — regardless of how robust your access control layer appears to be at a higher level.

The Trust Problem: APIs Have to Trust Someone

Every API, by design, must trust something — or it becomes useless. In most production systems, that trusted entity is a server-side application running on an instance that end users connect to. That application typically holds its own credentials to call downstream APIs. This raises a set of critical questions that teams rarely ask explicitly:

• How are server-side credentials stored? Are they hardcoded, injected via environment variables, or managed through a secrets manager?
• How are they rotated and audited?
• What happens to security posture when that instance receives an update?

A Concrete Attack Scenario

Consider this realistic scenario:

1. User A has permission to call a ShowMeCriticalData API.
2. That API is invoked from a server application running on Instance B.
3. The server app authenticates User A and then calls the API — either passing through the user’s own credentials (preferable for auditability) or using its own application-level credentials (problematic for tracking).
4. An update is deployed to Instance B that introduces a vulnerability.

Best case: The API still requires User A’s credentials. As long as User A protects those credentials, the API remains relatively secure — though the compromised instance is still a risk vector.

Worst case: The server app on Instance B is proxying requests using its own credentials. A successful exploit of the instance vulnerability allows an attacker to call the API without authenticating as any user at all. If User A is also careless with their authentication information, there is very little the organization can do to prevent misuse.

This is not a hypothetical edge case — it is a pattern that plays out regularly in dynamic DevOps environments where deployment velocity outpaces security review.

What Controls Actually Help

API Gateways and Management Tools

API gateways — when properly configured — provide meaningful protection: rate limiting, authentication enforcement, request validation, and centralized logging. However, they are not a silver bullet. Because incoming connections must be trusted at some point, and outgoing connections are assumed clean, the gateway’s effectiveness depends entirely on the correctness of its configuration and the integrity of the infrastructure behind it.

API Logging and Anomaly Detection

Logging API activity by username and flagging anomalous behavior can serve as an early warning system when a user’s credentials have been compromised. This will catch many issues — but not all. It is a detection control, not a prevention control, and it requires someone to act on the signals it generates.

Rate Limiting Third-Party API Calls

Rate limiting is not just a cost-control mechanism — it is a security control. Consider an application that calls a third-party API such as Google Places. Your application may never approach the provider’s usage caps under normal conditions. But if a portion of your infrastructure is compromised, an attacker could trigger an enormous number of API calls in a short window, resulting in significant unexpected costs or service disruption. A few lines of rate-limiting code can take that scenario from possible to mitigated.

Key Security Controls Every DevOps Team Should Have in Place

• Secrets management: Use a dedicated secrets manager (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) rather than storing credentials in environment variables, config files, or source code.
• Least-privilege access: Service accounts and application credentials should have the minimum permissions required. Avoid using shared or overly broad credentials.
• Credential pass-through where possible: Prefer passing authenticated user credentials through to downstream APIs rather than using application-level credentials. This preserves auditability and limits blast radius.
• Dependency and patch management: In fast-moving DevOps pipelines, instance updates can introduce vulnerabilities as easily as they fix them. Automated vulnerability scanning of dependencies and container images should be integrated into CI/CD pipelines.
• TLS everywhere: Enforce TLS on all internal and external API traffic. Regularly audit certificate configurations and stay current on known TLS weaknesses.
• Input validation and output encoding: Injection attacks and cross-site scripting remain relevant API attack vectors. Validate all inputs server-side and encode outputs appropriately.
• Rate limiting on all endpoints: Apply rate limits to both inbound and outbound API calls to limit the impact of compromised instances or credential abuse.
• Centralized logging and alerting: Aggregate API logs into a central platform and set up alerts for anomalous usage patterns, not just errors.

Assume a Fatal Flaw — Then Work to Reduce It

The most dangerous posture in API security is assuming your current implementation is adequate. In a DevOps environment — where code ships continuously, infrastructure is ephemeral, and teams move fast — the attack surface evolves with every deployment.

For public APIs especially, risk cannot be fully eliminated. The entire purpose of a public API is to be used — and that exposure is inherently a vector for abuse. The goal is not zero risk; it is minimized, well-understood, and actively monitored risk.

Operate with the assumption that there is a flaw somewhere in your system. Then systematically identify and reduce vulnerabilities at each access point. Review your credential management. Audit your gateway configurations. Challenge your logging coverage. Ask what would happen if Instance B were compromised tomorrow.

Comfort is not a security posture. Vigilance is.

1. Kubernetes Official Blog

Twitter: @kubernetesio

The official Kubernetes blog is the authoritative source for project news, feature announcements, and deep technical content. It covers official documentation updates, real-world case studies from adopting organizations, integration tutorials, and community governance discussions. Contributors include engineers from Google, VMware, Red Hat, and the Linux Foundation, as well as independent community members. Topics range from beginner-friendly introductions to advanced SIG (Special Interest Group) discussions such as the future of cloud provider integrations.

Post frequency: Every few days

2. Google Cloud Blog & Podcast

Twitter: @googlecloud

The Google Cloud blog blends product announcements with practical how-to content and analytical pieces based on research from teams like DORA (DevOps Research and Assessment). Engineers will find step-by-step guides for Google Cloud services alongside broader DevOps industry insights. The accompanying weekly podcast features rotating hosts interviewing engineers and thought leaders from inside and outside Google, making it useful for commutes and background learning.

Post frequency: Several times a day

3. AWS Blog — Jeff Barr

Twitter: @awscloud | @jeffbarr

Jeff Barr is AWS’s chief evangelist and the most prolific author on the AWS blog. His posts provide in-depth coverage of new AWS features and explore emerging technologies such as quantum computing. The blog’s well-organized category structure makes it straightforward to filter content by topic — DevOps, containers, serverless, and more — without getting lost in overly granular subcategories. Subscribing to Barr’s feed or following him on Twitter is a reliable way to stay on top of AWS announcements as they ship.

Post frequency: Several times a day

4. Microsoft Azure Blog

Twitter: @Azure

Microsoft’s Azure blog serves both technical practitioners and decision-makers. Engineers will find detailed how-to articles covering Azure-specific services and integrations. Business and compliance-focused readers will appreciate posts on cloud budget management and governance. The breadth of coverage — from IoT architecture to API management to hybrid cloud strategies — means most Azure practitioners will find relevant content regardless of their specialization.

Post frequency: Several times a day

5. IBM Cloud Blog

Twitter: @IBMcloud

IBM’s cloud blog is essential reading for teams working on IBM platforms or integrating IBM tools into broader architectures. Coverage spans technical tutorials, product announcements, compliance guidance, and hybrid cloud strategy. The blog publishes a mix of written articles, videos, and podcast episodes, making it accessible across different learning styles. Key topic categories include cloud-native development, DevOps toolchains, and AI integration.

Post frequency: Every few days

6. Docker Blog

Twitter: @docker

The official Docker blog is the primary source for container runtime updates, best practices, and integration guides. It covers Docker’s own tooling in depth while also addressing how containers interact with orchestrators, CI/CD pipelines, and cloud environments. Whether you are looking for release notes, security advisories, or hands-on tutorials for integrating Docker with specific tools, this blog is a necessary bookmark for anyone working with containers.

Post frequency: Several times a day

7. F5 Blog

Twitter: @F5networks

F5’s blog focuses on application security, multi-cloud management, and network infrastructure. It publishes a mix of thought leadership pieces — such as discussions on shifting security left in a DevOps workflow — and structured technical series covering cloud architecture and avoiding technical debt. Engineers working on application delivery, load balancing, or API security will find particularly relevant content here.

Post frequency: Several times a day

8. DZone (DevOps Zone)

Twitter: @DZoneInc

DZone is a large community-driven information portal with over one million registered members. Its DevOps zone aggregates articles from practitioners across the industry, covering topics from team culture and job satisfaction to detailed technical case studies. The volume of new content published daily means it rewards regular visits, and its tagging and filtering system makes it practical to focus on specific topics like CI/CD, Kubernetes, or monitoring without wading through unrelated posts.

Post frequency: Several times a day

9. r/devops — DevOps Subreddit

The DevOps subreddit is a community discussion forum for practitioners. Unlike a traditional blog, it provides peer commentary and curation alongside links to external content. The community rules require posters to add their own analysis or questions rather than simply dropping links, which generally raises the quality of discussion. Topics regularly covered include Kubernetes operations, CI/CD tooling comparisons, and incident post-mortems. It is a useful venue for gauging community sentiment on tools and practices.

Note: Subreddit membership figures change over time; verify the current subscriber count directly on Reddit.

10. CloudTech News

Twitter: @cloud_comp_news

CloudTech News is an online journal covering the business and technical dimensions of cloud computing. It aggregates perspectives from industry experts including practitioners at major cloud vendors and ISVs. For engineers who need to stay aware of broader market trends — not just technical how-tos — CloudTech provides useful context on where the cloud industry is moving.

Post frequency: Nearly every day

11. eSecurity Planet

Twitter: @eSecurityP

eSecurity Planet focuses specifically on information security, making it particularly valuable for DevSecOps practitioners. Coverage includes cloud security trends, compliance requirements, and application security best practices. Its tool overviews and trend analysis posts are thorough and often link out to deeper reference material, making them useful starting points for researching unfamiliar security domains.

Post frequency: Variable; typically a few times per month in-depth pieces

12. CSO — Cloud Security Coverage

Twitter: @CSOonline

CSO Online aggregates security content pitched at both technical practitioners and security leadership. Its cloud security section covers topics like decentralized cloud models, zero-trust architecture, and the strategic dimensions of security investment. The publication draws on contributions from cybersecurity executives, analysts, and practitioners, making it useful for engineers who need to communicate security decisions upward to non-technical stakeholders.

Post frequency: Nearly every day

13. DevOps.com

Twitter: @devopsdotcom

DevOps.com is one of the most comprehensive independent resources for DevOps practitioners. It covers strategy, tooling, case studies, and industry events across a wide range of categories including DevSecOps, AI-driven operations, continuous testing, and observability. The site also lists upcoming webinars and industry events on its front page, making it a single-stop resource for both learning and professional development. The volume of content is high enough that daily visits will rarely exhaust new material.

Post frequency: Several times a day

14. DevOpsCube

Twitter: @devopscube

DevOpsCube functions as both a technical blog and a practitioner community. Its content is organized around four primary areas: CI/CD, Cloud, Containers, and Monitoring. Tutorials are written with varying levels of assumed expertise, making the site useful whether you are learning Kubernetes for the first time or optimizing an existing production setup. The site’s forum provides a space for practitioners to ask questions and share experiences directly with peers.

Post frequency: Infrequent but in-depth

Building Your Reading Rotation

No single source covers everything. The most effective approach is to combine a vendor blog or two relevant to your stack (AWS, Azure, Google Cloud, IBM) with community-driven sources like DZone and the DevOps subreddit, and at least one dedicated security publication such as eSecurity Planet or CSO Online. Use an RSS reader or a tool like Feedly to aggregate these feeds in one place rather than visiting each site individually.

The list above is a starting point, not an exhaustive index. The DevOps and cloud security landscape evolves quickly, and new high-quality publications emerge regularly. If you have a resource that belongs on this list, share it in the comments below.

Automation Strategy Rethink
Hybrid IT Versus Disaster Recovery (DR) Confidence
Scaling DevOps Agility
Infrastructure Is Everywhere — So Is Your Data
Overwhelming Impact of IoT
Distributed Cloud
Immersive Experience
Democratization of IT
Networking — What’s Next?
Hybrid Digital Infrastructure Management (HDIM)
Splunk also published its list, which looks like this:

AI/ML/NLP
Blockchain
IoT/5G
Dark Data
IT Security
Social Engineering
Critical Infrastructure
Cloud Security
Threat Intelligence
IT Operations
Automation
UX/Consumerization
McKinsey also has a list:

Today In: Innovation
“As-a-Service” Consumption for Everything from Software to Hardware.
Mainstream Public Cloud
Increased Use of Open-Source Offerings, Up & Down the Stack
Cybersecurity
Mainstream Comfort with “White Box” Hardware
Internet of Things
Shift of the Hardware Infrastructure Market to Asia
DevOps for Software & Hardware
Container-First Architectures
Artificial intelligence & Machine-Learning
PROMOTED

Grads of Life BRANDVOICE
| Paid Program
Designing To Create An Equitable And Inclusive Talent Marketplace
ABB BRANDVOICE
| Paid Program
The Art Of A Smart City
Insights – Teradata BRANDVOICE
| Paid Program
How Pandora Knows What You Want To Hear Next
It’s helpful to look at these three lists and draw some insight into how three major vendors see the world. It would be difficult to find three vendors that have less in common than Gartner, Splunk and McKinsey, which is in itself valuable. Gartner “equips executives across the enterprise to make the right decisions and stay ahead of change.” Splunk “is the world’s first Data-to-Everything Platform.” McKinsey “help(s) organizations across the private, public, and social sectors create the change that matters.” Very different missions, to put it mildly. But all three have thought about what’s likely to happen to 2020 computing and communications infrastructures. So what do they think?

Here’s a chart that compares the areas according to who likes what:

Comparison Among Gartner, Splunk & McKinsey
Comparison Among Gartner, Splunk & McKinseySJA
Analysis

Industrial technology concept.
Industrial technology concept.GETTY
Automation is a favorite. Nothing surprising here. Blockchain is not. Nothing surprising here either. Hybrid IT Versus disaster recovery is interesting. According to Ross Winser (Senior Research Director at Gartner), as reported by Russ Weldon: “organizations are left potentially exposed when their heritage DR plans designed for traditional systems have not been reviewed with new hybrid infrastructures in mind. Resilience requirements must be evaluated at design stages rather than treated as an afterthought two years after deployment.” Good advice. DevOps is still popular. Everybody loves IOT and, though to a slightly lesser extent, AI/machine learning and natural language processing. Obviously.

The emphasis on cloud development platforms – Infrastructure as a Service (IaaS) – is growing – as it should. The very definition of infrastructure provisioning and management will grow as more “as-a-service” models emerge. In fact, we can expect the full integration of software-as-a-service, platform-as-a-service and infrastructure-as-a-service – along with all of the other as-a-service models that are now available and will be available soon. The overall movement toward – and therefore dependency upon – cloud providers describes an enormous opportunity and a corresponding risk – which is why cyber/cloud security is so important to cloud clients: cybersecurity, including cloud security, should preoccupy every infrastructure manager on the planet.

The cloud is also expanding to the edges of networks, so IT infrastructure managers (and CISOs) have to adjust their responsibilities (and SLAs) outward. Edge and hybrid cloud deployments only exacerbate infrastructure challenges – which should be front and center.

We can agree that the public cloud will grow, and more open source software will become part of the mainstream infrastructure architecture. But we should also agree that the spaghetti API world that lubricates infrastructure and applications will eventually crash under its own weight. Standardization should be a goal, though, as we all know, it’s impossible to achieve.

The Asian hardware invasion that only McKinsey predicts is unlikely. There are growing national security concerns and industry cross-pressures about products that might threaten the integrity of US networks and communications devices. It was reported as recently as November 22, 2019 that “American regulators voted to impose new restrictions on subsidies for American telecom companies Friday. The ruling is designed to constrain Chinese companies, including Huawei and ZTE.” This is techno-politico quicksand. CIOs and CTOs would do well to avoid stepping in it – even if their vendor choice is off the blacklisted vendor list – today.

Gartner’s emphasis on the democratization of IT is surprisingly ignored by Splunk and McKinsey. If we believe that PaaS will grow via cloud platforms, then the importance of low code/no code development capabilities increases. Gartner has this exactly right. Platforms like Microsoft’s Power Platform now enable near-no-code development of, for example, applications in robotic process automation (RPA). This is an irreversible trend and consistent with the growing infrastructure role that cloud-delivered PaaS will play going forward – and forever.

As suggested, everyone agrees that the management and support of the Internet-of-Things (IOT) and eventually the Internet-of-Everything (IOE) will impact infrastructure. Clearly, this makes sense. But the larger infrastructure requirements around IOT ecosystems should be anticipated as well. Connected devices will signal into the cloud where structured and unstructured sensor data meets analytics, which will increasingly integrate and process exploding volumes of (especially unstructured) data. A corresponding emphasis on data and analytics infrastructure is therefore appropriate.

The Return of Enterprise Architecture

barrier Under construction
Road barrier with the words Under construction. 3d render.GETTY
So where is all this going? The predictions Gartner, Splunk and McKinsey make all have some merit. First and foremost, infrastructure is going to the cloud. We also know that security is a must have – as the auditors love to tell us. But infrastructure should not be designed in a vacuum. It may be time to resurrect your outdated Enterprise Architecture and re-architect your infrastructure as part of an integrated business, applications, data and technology architecture.

Investment Strategies

Ultimately, this is all about resource allocation. The three vendors offer insight and advice which should be assessed in the context of your industry, your competition, your company, your leadership and your culture. Your appetite for digital transformation is the ultimate driver of change. If it’s low then discussions like these may be fun, but unproductive. But if the appetite is large then insights from companies like Gartner, Splunk and McKinsey – and others – can be extremely helpful.

Why Cloud Storage Comparisons Matter More Than Ever

A common sentiment among enterprise IT professionals is that cloud storage costs more than equivalent on-premises infrastructure — but that the premium is justified by the agility gained and the operational overhead eliminated. That trade-off perception is strong enough that many organizations have planned significant year-over-year increases in cloud storage spending.

Yet cloud storage is not simply on-premises storage delivered over a network. It is a fundamentally different acquisition and operational model with its own performance tuning levers, cost optimization strategies, and automation primitives. Understanding those differences before making long-term architectural commitments can mean the difference between a well-optimized environment and one that silently drains budget.

The Mandate Problem: Speed vs. Thoughtfulness

Enterprise IT departments are frequently handed top-down mandates to migrate a target percentage of their application portfolio to the cloud by a fixed deadline. The instinct under deadline pressure is to move applications and data first and optimize later. This approach routinely leads to:

• Unnecessary spending on over-provisioned or poorly matched storage tiers
• Security gaps caused by default configurations that were never revisited
• Application performance problems from mismatched I/O profiles
• Architectural decisions that are expensive or disruptive to reverse

A better approach is to understand the cloud storage landscape — including how each major provider structures its services, prices its offerings, and handles security — before workloads are committed.

Key Differences Between AWS, Azure, and Google Cloud Storage

A comparative analysis of the three major public cloud providers — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) — surfaced several meaningful distinctions across cost models, storage categories, and security capabilities.

1. Billing Models Differ Significantly

All three providers calculate monthly storage bills differently, and those differences grow more consequential as usage becomes more sophisticated.

• AWS tends to charge separately for incremental services — snapshots, I/O operations, data transfer, and so on each appear as discrete line items.
• Azure is more likely to bundle related costs into the base price of a service, which can result in a lower effective cost as usage patterns become more complex.
• Google Cloud also itemizes costs, though its pricing structure for storage has historically been competitive, particularly for egress within Google’s network.

The practical implication: a side-by-side sticker price comparison is often misleading. Total cost of ownership calculations should account for snapshot frequency, I/O volume, replication requirements, and data egress patterns.

2. Block Storage: AWS and Azure Are Closely Matched

For block storage — the storage type most directly analogous to traditional SAN/DAS used by databases and VM boot volumes — AWS and Azure are broadly competitive. Key points:

• AWS EBS (Elastic Block Store) offers a wider range of volume types (e.g., gp2/gp3 general-purpose SSD, io1/io2 provisioned IOPS SSD, st1 throughput-optimized HDD, sc1 cold HDD), giving architects more granular control over cost and performance trade-offs.
• Azure Managed Disks covers similar tiers (Standard HDD, Standard SSD, Premium SSD, and Ultra Disk). At the time of the original analysis, Ultra Disk was in preview; it has since reached general availability.
• Google Persistent Disk provides standard and SSD tiers, along with Extreme Persistent Disk for high-IOPS workloads, though the overall range of options is narrower than AWS.

3. File Storage: AWS Leads in Breadth of Options

Managed file storage — services that expose a shared filesystem over NFS or SMB protocols — shows more meaningful differentiation between providers.

• AWS offers Amazon EFS (Elastic File System) for Linux/NFS workloads, Amazon FSx for Windows File Server, Amazon FSx for Lustre (high-performance computing), and Amazon FSx for NetApp ONTAP and OpenZFS — the broadest portfolio.
• Azure offers Azure Files (SMB and NFS), with Azure NetApp Files as a premium option for enterprise NAS workloads.
• Google Cloud offers Filestore at multiple tiers (Basic, Enterprise, High Scale) but with fewer specialized variants than AWS.

4. Object Storage: The Most Mature Category Across All Three

Object storage — AWS S3, Azure Blob Storage, and Google Cloud Storage — is the most developed and feature-complete storage category offered by all three providers. It is also where the largest volumes of raw data typically reside, making its security posture especially important.

All three providers now offer a comparable set of security controls for object storage:

• Object locking (WORM — Write Once Read Many) to prevent deletion or modification
• Access control lists (ACLs) and bucket/container-level policies
• Audit and access logs for compliance and forensics
• Customer-managed key management (AWS KMS, Azure Key Vault, Google Cloud KMS)
• Encryption at rest and in transit enabled by default on all three platforms

The convergence on security features is meaningful: it reflects both regulatory pressure and the volume of sensitive data organizations store in object form. That said, the configuration defaults and the depth of integration with identity and access management systems differ — review each provider’s shared responsibility model carefully.

5. Transparency and Documentation Quality

The comparative analysis noted that AWS and Azure are generally more forthcoming with detailed technical documentation, pricing calculators, and performance benchmarks than Google Cloud. Organizations evaluating GCP for storage-heavy workloads may find they need to engage Google’s sales and solutions engineering teams earlier in the process to get comparable depth of information.

Practical Guidance Before You Commit

Given the differences outlined above, here are concrete steps teams should take before selecting a cloud storage strategy:

1. Profile your workloads first. Distinguish which applications need block, file, or object storage. Mixing up storage types is a common and costly mistake.
2. Model your total cost of ownership. Use each provider’s pricing calculator, but also account for snapshot frequency, data transfer costs, and IOPS charges — not just raw capacity pricing.
3. Test performance against your actual I/O profiles. Published throughput and IOPS figures are ceilings, not guarantees. Benchmarking against representative workloads before production commitment avoids surprises.
4. Audit security defaults immediately. Default configurations on object storage have historically been a source of data exposure incidents. Review bucket/container permissions, logging, and encryption settings on day one.
5. Plan for egress costs. Moving data out of any cloud provider incurs charges. If your architecture requires frequent large data transfers — to on-premises systems, to analytics platforms, or between regions — model those costs explicitly.

The Bottom Line

AWS, Azure, and Google Cloud each offer mature, capable cloud storage portfolios, but they are not interchangeable. Billing structures, storage service breadth, and documentation depth differ in ways that matter at scale. Organizations that invest time in understanding those differences before migrating — rather than after hitting an unexpected invoice or a performance ceiling — consistently get better outcomes.

Cloud storage delivered as a service requires a different evaluation discipline than purchasing a storage array. The flexibility is real, but so is the complexity. Outside, vendor-neutral analysis remains valuable precisely because providers naturally present information in ways that favor their own offerings.

The cloud is a complex environment in which different groups manage different services and environments simultaneously. At the most fundamental level, there is a division between the cloud provider—who supplies core infrastructure—and the customer, who builds applications or consumes services on leased resources. Inside larger enterprises, individual lines of business may each own their own cloud accounts, budgets, and development teams, making a unified security strategy surprisingly difficult to achieve.

From a security perspective, this fragmented ownership model creates serious challenges around end-to-end visibility, access control, and regulatory compliance. The cloud is inherently a shared infrastructure, and security incidents rarely respect organisational boundaries. Without a centralised security strategy and consistent policies across every cloud environment, grey areas of responsibility emerge—and those grey areas become the gaps attackers exploit.

Cloud Provider vs. Customer Responsibility

A recurring theme in cloud security research is widespread confusion about who is responsible when a vulnerability or security event occurs. According to survey data cited by IHS Markit, even in scenarios where responsibility should be straightforward—such as a vulnerability in the cloud platform itself—only roughly half of respondents could correctly identify the root cause and the responsible party.

The confusion is compounded by the sheer number of security tools available within modern cloud ecosystems:

• Provider-native security services built directly into the cloud platform (identity management, encryption, logging, threat detection).
• Third-party security products available through cloud provider marketplaces.
• Security capabilities embedded in cloud management platforms, hypervisors, and orchestration tools.

The critical point here is that under the shared responsibility model, as soon as a customer applies a configuration to any of these tools or services, responsibility for that configuration shifts to the customer. In practice, however, those boundaries are rarely communicated clearly—and that ambiguity is dangerous.

Building a Root Cause Analysis Playbook

The most effective mitigation is to apply security best practices to every resource and service consumed in the cloud, and to document them explicitly. A well-constructed root cause analysis (RCA) playbook should:

1. Identify plausible threat scenarios and map them to likely responsible parties (provider, vendor, or customer).
2. Name all key stakeholders who must be contacted in each scenario.
3. Catalogue the investigation and forensic tools available for each cloud environment.
4. Define processes for coordinating incident response across all parties—provider, third-party vendors, and internal teams.
5. Map those processes directly to actual cloud technologies and accounts.
6. Automate response actions wherever possible to reduce mean time to contain.

Security Responsibilities Within the Customer Domain

Even after the provider/vendor/customer boundary is clarified, most organisations still face a second, equally difficult challenge: defining who owns security inside their own organisation. Large enterprises commonly operate multiple cloud environments—often five or more—with additional environments in active development. Each environment may be owned by a separate line of business, and those business units typically guard their autonomy fiercely.

Two conflicting dynamics make this problem hard to resolve:

• Central IT security teams often lack deep cloud expertise. Security tools they recommend can create bottlenecks that slow down deployment pipelines—directly threatening the speed-first ethos of DevOps.
• DevOps teams have the cloud expertise but typically have limited formal security training. Expecting them to correctly configure intrusion detection, tune WAF rules, manage certificate lifecycles, and eliminate false positives—on top of their delivery commitments—is an unrealistic ask.

The result is a security vacuum: neither team fully owns the problem, and critical configuration decisions get made by whoever happens to be available, without the right expertise.

Shifting from DevOps to DevSecOps

The structural fix is straightforward to describe, if not always easy to execute: embed a cybersecurity specialist directly into each DevOps team. The result is a DevSecOps team that integrates security into the development lifecycle from day one rather than bolting it on at the end.

A properly embedded DevSecOps engineer can:

• Navigate the shared responsibility model and clarify who owns what for each tool and environment.
• Enforce consistent security policies across multiple cloud instances and accounts.
• Select and integrate security tooling that complements rather than obstructs the delivery pipeline.
• Balance protection requirements against performance and speed-to-market objectives.

Choosing Tools That Support Both Speed and Security

Tool selection is a core DevSecOps competency. SaaS-delivered security solutions—web application firewalls (WAFs) being a common example—can auto-scale alongside the applications they protect, removing the need for manual capacity planning. The best options in this category are designed to integrate into application traffic flows with minimal configuration overhead and include built-in deployment, maintenance, and tuning capabilities.

Automation is equally important. Manual configuration audits and malware scans are among the first tasks to be skipped when delivery pressure increases. Automated cloud security solutions, designed and overseen by the DevSecOps team, can provide:

• Continuous configuration assessment against defined baselines and compliance frameworks.
• Dynamic encryption and protection of data at rest.
• Automatic scanning for known public cloud vulnerabilities and misconfigurations.
• File scanning for malware stored in cloud object storage.
• Data loss prevention (DLP) controls to block unauthorised exfiltration of sensitive information.

Building a DevSecOps Team Requires Executive Support

DevOps has earned its place in C-suite and board-level conversations as a driver of digital transformation and competitive advantage. But executives who champion cloud adoption and aggressive delivery timelines sometimes underestimate the attack surface that rapid, unsecured cloud expansion creates.

Closing that knowledge gap at the executive level is a prerequisite for sustained DevSecOps success. Business leaders need to understand:

• Each new cloud environment and digital touchpoint increases the organisation’s potential attack surface.
• Security debt accumulated during fast-moving cloud projects is a measurable business risk—not just an IT concern.
• Regulatory violations arising from insecure cloud deployments carry real financial and reputational penalties.

With executive backing, DevSecOps programmes can ensure security is integrated into new cloud environments from the start, that RCA playbooks are created and maintained, and that security tooling is funded and managed appropriately. Without it, DevSecOps engineers become lone voices in teams optimised for speed—and security remains an afterthought.

Key Takeaways

• The cloud shared responsibility model is widely misunderstood; document exactly who owns what for every service and configuration in your environment.
• Neither central IT security teams nor DevOps teams alone have all the skills needed to secure complex multi-cloud environments—DevSecOps bridges that gap.
• Embedding security specialists inside DevOps teams is the most effective structural change an organisation can make to improve cloud security posture.
• Automation of configuration assessment, vulnerability scanning, and incident response reduces security debt without slowing delivery.
• Executive education and sponsorship are non-negotiable for building a sustainable DevSecOps culture.

The State of Cloud in Early 2019

By 2019, enterprise migration from legacy on-premises infrastructure to cloud platforms had shifted from experimental to mainstream. Organizations across sectors were pursuing cloud adoption not just for storage and cost savings, but as a foundational pillar of business automation, application availability, and global scalability.

With that backdrop, several patterns were emerging that analysts expected to define the cloud computing landscape throughout the year. Below are five predictions that reflected the key pressures and opportunities facing DevOps and IT teams in 2019.

1. Multi-Cloud Adoption Would Accelerate and Terminology Would Matter More

The cloud market in 2019 was no longer a binary choice between “cloud” and “on-premises.” Organizations were deploying across public cloud, private cloud, and hybrid configurations — often simultaneously. The term multi-cloud gained traction to describe environments that combine more than one cloud provider or model.

• Public cloud: Resources hosted and managed by a third-party provider, shared across multiple tenants (e.g., AWS, Azure, Google Cloud).
• Private cloud: Dedicated virtualized infrastructure operated for a single organization, either on-premises or hosted.
• Hybrid cloud: An integrated environment combining on-premises or private infrastructure with public cloud services.

A recurring challenge was the inconsistent use of these terms — vendors and teams often applied them interchangeably or incorrectly, complicating procurement, architecture decisions, and vendor comparisons. As multi-cloud strategies matured, precise terminology became operationally important.

2. Non-US Cloud Providers Would Gain Ground

The major US-based hyperscalers — AWS, Microsoft Azure, and Google Cloud Platform — dominated the global market, but 2019 signaled growing competition from non-US providers. Alibaba Cloud, the cloud arm of Alibaba Group, was frequently cited as a significant challenger, particularly in Asia-Pacific markets.

For small and medium-sized businesses evaluating cloud costs, non-US providers offered competitive pricing that made them worth consideration alongside the established players. Meanwhile, regulatory factors — including data sovereignty requirements in the EU and elsewhere — were already pushing some organizations toward regional providers regardless of cost.

The expectation was that incumbents and regulators would respond, whether through pricing adjustments, expanded regional infrastructure, or policy measures. This dynamic has since played out significantly in the years following 2019.

3. The Cloud Skills Gap Would Worsen Before It Improved

One of the most persistent challenges accompanying rapid cloud adoption was — and remains — a shortage of skilled practitioners. The pace of change across cloud platforms, the breadth of services, and the number of competing certification tracks made it difficult for organizations to find engineers with the right combination of skills.

Two responses were identified as practical paths forward:

• Retraining existing staff: Rather than competing exclusively for scarce external talent, organizations could invest in upskilling their current workforce — focusing on cloud fundamentals, infrastructure-as-code, and cloud-native development practices.
• Hiring for learning agility: Given how quickly cloud platforms evolve, the ability to learn rapidly became as important as existing cloud-specific knowledge.

This prediction has proven accurate. Cloud skills shortages have remained a consistent concern in DevOps hiring through the years following 2019, and internal training programs have become a standard part of cloud transformation initiatives.

4. Public Cloud Would Outpace On-Premises Innovation, Forcing Migration

In 2019, many enterprises still maintained on-premises data centers as their primary infrastructure, treating public cloud as a supplement or a future aspiration rather than an immediate priority. However, the pace at which AWS, Azure, and GCP were releasing new managed services — spanning AI/ML, serverless computing, container orchestration, and more — was creating a growing capability gap.

The prediction was that organizations clinging to on-premises-first strategies would increasingly find themselves unable to match the innovation velocity of competitors who had embraced public cloud. This would accelerate the adoption of public-cloud-first policies, where new workloads default to public cloud unless there is a specific regulatory, latency, or security reason not to.

For DevOps teams, this meant the pressure to support hybrid pipelines — CI/CD workflows that span on-premises and cloud environments — would intensify during the transition period.

5. Cloud Security Would Demand Greater Investment and Sophistication

As cloud infrastructure became more critical to business operations, it also became a more attractive target. The prediction for 2019 was that threat actors would deploy increasingly sophisticated techniques against cloud environments, requiring a corresponding upgrade in defensive capabilities across both public and private sectors.

Key areas identified for investment included:

• SIEM tools (Security Information and Event Management): Platforms that aggregate and correlate log data across cloud services to detect anomalies and respond to threats in near real time.
• Detection and response capabilities: Moving beyond perimeter-based security toward continuous monitoring of cloud workloads, identities, and configurations.
• Shared responsibility awareness: A recurring security gap was the misunderstanding of cloud providers’ shared responsibility models — where the provider secures the infrastructure, but the customer is responsible for securing their data, access controls, and application configurations.

Cloud security has since grown into one of the largest and most active segments of the cybersecurity industry, validating this directional prediction.

Looking Back: How These Predictions Held Up

Reviewing these predictions from a later vantage point, most of the directional trends proved accurate. Multi-cloud is now the norm rather than the exception. Non-US providers — particularly Alibaba Cloud — have carved out significant regional market share. The cloud skills gap has remained a persistent challenge. Public cloud adoption accelerated well beyond 2019 expectations, and cloud security has become one of the top priorities for security and engineering teams alike.

For DevOps engineers, the practical takeaway from this period is that cloud adoption is not a one-time migration project — it is an ongoing operational discipline requiring continuous upskilling, architectural adaptation, and security vigilance.

The State of Enterprise Cloud Heading into 2019

By the start of 2019, enterprise cloud computing had moved far beyond its origins as a simple server hosting platform. Driven by digital transformation initiatives, cloud adoption was accelerating across organizations of every size. Analyst firm Gartner projected the worldwide public cloud market would grow 17.3%, reaching approximately $206.2 billion in 2019—a figure that reflected both expanding workload migration and the proliferation of cloud-native services.

A LogicMonitor survey from that period identified digital transformation as the primary driver behind public cloud engagement, with the same research forecasting that 41% of all enterprise workloads would run on public cloud platforms by 2020. When public, private, and hybrid deployments were counted together, roughly 83% of enterprises were expected to rely on cloud infrastructure by the end of the decade.

The IDG 2018 Cloud Computing Survey added further weight to these projections, reporting that 73% of organizations had already shifted mission-critical workloads and computing infrastructure into the public cloud, while approximately 17% planned a full migration to public cloud platforms within the year.

Hybrid and Multi-Cloud Solutions Dominate Enterprise Strategy

A full lift-and-shift to a single public cloud proved difficult and costly for most enterprises. Hybrid cloud—combining the scalability of public cloud with the control of on-premises or private infrastructure—emerged as the pragmatic middle path. It allowed organizations to migrate resources incrementally, manage risk, and maintain compliance requirements for sensitive workloads.

At the same time, enterprises were not confining themselves to a single vendor. According to the RightScale 2018 State of the Cloud Survey, 81% of enterprises had adopted a multi-cloud strategy, spreading workloads across providers such as AWS, Microsoft Azure, and Google Cloud. This vendor diversification reduced lock-in risk and allowed teams to select best-of-breed services for specific use cases.

The practical outcome was a cloud architecture for most large organizations that blended on-premises infrastructure, private cloud resources, and multiple public cloud vendors—a pattern that has only deepened in the years since.

Cloud Service Models: SaaS, IaaS, and BPaaS Growth Projections

Gartner’s worldwide public cloud service revenue forecast for 2019 broke down growth expectations by service model:

• IaaS (Infrastructure as a Service) was the fastest-growing segment, with projected growth of 27.6%, expected to reach approximately $39.5 billion in revenue.
• SaaS (Software as a Service) remained the largest segment overall, with 17.8% projected growth to reach roughly $85.1 billion.
• BPaaS (Business Process as a Service) was forecast to achieve around 7.9% growth, reaching approximately $50.3 billion.

A KPMG report titled Journey to the Cloud projected that enterprise investments in PaaS (Platform as a Service) would grow to 56% in 2019. Together, these forecasts pointed to a cloud services market expanding in both breadth and depth, with enterprises consuming a broader mix of delivery models rather than converging on a single one.

GDPR and the Intensifying Focus on Cloud Security

Security consistently ranked as the top concern for enterprises moving workloads to public cloud platforms—a finding LogicMonitor reported in its research. The introduction of the EU General Data Protection Regulation (GDPR) in May 2018 significantly raised the stakes. With substantial fines for non-compliance and breach notification requirements, organizations operating in or serving customers in the EU had strong regulatory incentives to audit their cloud security posture.

Key security considerations for enterprise cloud teams in 2019 included:

• Data residency and sovereignty — ensuring data was stored and processed in jurisdictions that met GDPR requirements.
• Shared responsibility clarity — understanding where the cloud provider’s security obligations ended and the customer’s began.
• Access management — enforcing least-privilege access controls, multi-factor authentication, and robust identity management across multi-cloud environments.
• Breach detection and response — implementing monitoring and incident response plans aligned with GDPR’s 72-hour breach notification window.

While major cloud vendors incorporate enterprise-grade security capabilities into their platforms, compliance responsibility under GDPR ultimately rests with the data controller—typically the enterprise itself. CIOs and security architects needed to verify that their chosen platforms and configurations genuinely met regulatory requirements, not simply assume vendor defaults were sufficient.

Quantum Computing: Edging Toward Enterprise Relevance

Quantum computing was a major topic of discussion heading into 2019, even if commercially viable enterprise applications remained years away. Several technology companies had made notable investments and announced concrete milestones:

• IBM had released a 20-qubit quantum system in 2017 and made it accessible to researchers via IBM Q Experience.
• Alibaba, in collaboration with the Chinese Academy of Sciences, had developed an 11-qubit quantum computing system.
• Intel, Microsoft, and Google were all actively investing in quantum hardware and algorithms research.

The most compelling near-term opportunity lay in the intersection of quantum computing and cloud infrastructure. If cloud providers could offer quantum processing as a cloud service, enterprises could access quantum capabilities for specific computationally intensive problems—such as optimization, cryptographic research, molecular simulation for drug discovery, or financial modeling—without needing to own or operate quantum hardware directly.

In 2019, quantum cloud computing was still largely experimental, but the trajectory was clearly set toward offering it as a managed cloud service, a direction AWS (Braket), IBM (Q Network), and Microsoft (Azure Quantum) would all pursue in subsequent years.

What These Trends Meant for CIOs and DevOps Teams

The convergence of these trends placed clear demands on enterprise technology leaders and engineering teams:

• Adopt a multi-cloud architecture mindset — design systems to be portable and interoperable across providers rather than deeply coupled to a single vendor’s proprietary services.
• Treat security as a first-class engineering concern — bake compliance requirements such as GDPR into cloud architecture decisions from the start, not as an afterthought.
• Evaluate the full spectrum of service models — IaaS, PaaS, SaaS, and BPaaS each offer different trade-offs in control, cost, and operational overhead; choose per use case rather than defaulting to a single model.
• Monitor emerging capabilities — quantum computing and AI-powered cloud services were beginning to move from research labs toward early commercial availability, and staying informed positioned teams to evaluate them when ready.

Summary

The enterprise cloud landscape entering 2019 was characterized by rapid adoption, increasing architectural complexity, and mounting regulatory pressure. Hybrid and multi-cloud strategies emerged as the dominant approach, cloud service revenues across IaaS, SaaS, and BPaaS were on strong growth trajectories, GDPR was forcing a more rigorous approach to cloud security, and quantum computing was transitioning from research curiosity to a nascent cloud service category. For organizations that engaged thoughtfully with these trends, 2019 offered a genuine opportunity to mature their cloud strategy and build a more resilient, capable infrastructure for the years ahead.

In 2018, more organizations adopted cloud computing, and at a rapidly growing pace. The main drivers for cloud were high efficiency, easier and faster deployments, and, of course, scalability. But from a security perspective, the speedy adoption of cloud computing is forcing security professionals to learn about new challenges, cloud-specific risks, and relevant mitigations as well as to develop more modern cybersecurity strategies.

The past year also brought with it a greater number of security incidents related to misconfigured cloud accounts, which is a trend that I expect to increase as more organizations adopt cloud computing without growing their cloud security teams or hiring professionals with a deep understanding of cloud security issues.

What do those recent trends portend for the future? Here are six cloud security predictions for 2019:

Prediction 1: Serverless adoption will drive cloud security automation.
As organizations increasingly move to serverless architectures, they are also discovering more use cases for cloud security automation because serverless functions provide a means to launch security logic as a response to cloud events. Examples include: when there are spikes or anomalies in cloud account billing expenses as a result of service abuse, denial-of-service attacks, or crypto mining; when someone attempts to deploy new cloud assets/services or code outside the normal deployment pipeline; or running compliance checks on new code or cloud resources as part of the deployment pipeline.

Prediction 2: Cloud providers will take on a major role in security.
With serverless adoption skyrocketing in 2018, more teams are choosing to either switch from container-based architectures to serverless, or simply skip containers altogether. The reason? An increasing number of system components are now abstracted and, subsequently, they require less management. This is also the case for cloud security. Serverless architectures are the highest abstraction of cloud computing to date, which makes application owners only responsible for security at the application layer and in cloud configurations. As a result, much of an organizations’ security responsibility has now passed to the cloud provider. This includes physical security, operating system security configurations and patches, network security, and a virtual machine or container security.

Prediction 3: Expect to see more cloud-native guidelines and research.
In 2018, several industry analysts released research papers and recommendations around cloud-native technologies, with Neil MacDonald of Gartner spearheading into the serverless domain with his research on Security Considerations and Best Practices for Securing Serverless PaaS. I expect analysts will pay even more attention in 2019 to cloud-native security in general and serverless security in particular, as organizations continue to modernize their applications and seek help in determining the right security strategy.

Prediction 4: Declining demand for security support in multi-cloud deployments.
In 2017 and 2018, much attention was given to the topic of cloud vendor lock-in. As a result, cloud security vendors were required to answer inquiries regarding their support for multi-cloud deployments. In late 2018, several thought leaders in the cloud computing industry called out the fact that cloud vendor lock-in is mostly fear, uncertainty, and doubt (FUD)! As Simon Wardley, a UK researcher for Leading Edge Forum and the lead practitioner for Wardley Maps, stated: “It would be nice to have a competitive environment with different providers you can switch between. But that is secondary to usefulness and functionality.” We expect to see less and less attention being given to this topic, and cloud security vendors will see less demand for supporting multi-cloud deployments.

Prediction 5: Security will shift even more to the left.
As an increasing number of system components become the responsibility of cloud providers, application owners will find themselves dealing less with infrastructure, operating system, and networking security. This shift in security responsibility is maximized in serverless architectures, where the only responsibility for application owners is in the application layer. As a result, organizations will see an internal shift, with a lot less involvement from traditional corporate IT security teams in corporatewide high-level security strategies. On the other hand, expect development teams to become more involved and responsible for security, which will push the adoption of the DevSecOps movement.

Prediction 6: Traditional security vendors will move into cloud-native security.
In 2018, traditional security vendors started making strategic efforts to modernize their security offerings and adapt to cloud-native environments. Recent examples include Palo Alto Networks, which acquired Evident.io and RedLock, and Check Point, which recently acquired Dome9. This trend is expected to continue in 2019, as vendors realize that cloud computing is not just the domain of startup companies but is also being adopted by large corporations, financial services, healthcare, and even government offices. Bottom line: Organizations now recognize that public cloud infrastructure is not less secure than on-premises, and those cloud vendors provide a high level of security.

Here’s a good example of how security underlines – or should underline – pretty much everything in the cloud: Cisco has announced it is to acquire Michigan-based Duo Security for upwards of $2.3 billion (£1.8bn).

The deal, which expects to close during the first quarter of Cisco’s fiscal year 2019, aims to help give the networking giant’s customers straightforward and secure access to any application on any networked device through Duo’s platform.

Duo Security offers a trusted access platform with two-factor, multi-factor and zero trust authentication. The platform verifies the identity of users by checking the health of their device before granting access to company applications.

In a letter to employees, Duo CEO Dug Song cited the traditional reasons why the acquisition made sense – deploying the technology at scale, gaining Cisco’s long-standing enterprise security experience, as well as a nice payoff for shareholders. “This is an important next chapter for Duo and there is much more we can accomplish together to position Cisco for enduring success,” wrote Song. “I am incredibly proud of the company we have built and look forward to our future with our friends at Cisco.”

Song also noted the importance of Cisco’s recent security-based acquisitions – such as OpenDNS, Sourcefire and Cloudlock – and how they were integrated into the wider business. “They are a company evolving themselves under new leadership, new momentum, and a new focus on innovation in the cloud era,” Song added. “Cisco views our leadership in zero trust security as transformational to their business, bringing cloud-based user and device trustworthiness to an already impressive security product portfolio.”

From Cisco’s perspective, the continued prevalence of multi-cloud initiatives was key to the acquisition. “IT teams are responsible for protecting hundreds of different perimeters that span anywhere a user makes an access decision,” said David Goeckeler, EVP and general manager of networking and security at Cisco. “Duo’s zero trust authentication and access products integrated with our network, device and cloud security platforms will enable our customers to address the complexity and challenges that stem from multi- and hybrid cloud environments.”

When security professionals gathered for the “Innovating With Cloud Security” breakout session at the IBM Security Summit in London, a clear picture emerged: cloud adoption is near-universal, but a mature security strategy is not. Audience polls revealed that all attendees used cloud services, with the majority relying on public multi-cloud environments — yet fewer than 10 percent had a formal, policy-backed strategy for cloud security.

That gap between usage and governance reflects a broader industry tension. On one side is the belief that the cloud is inherently too insecure for enterprise workloads. On the other is the equally dangerous assumption that cloud providers handle security automatically. Neither extreme serves the business well. What follows are the key themes from that discussion, reframed as actionable guidance for DevOps and security teams.

Cloud Security: For vs. From

One of the most useful conceptual distinctions in cloud security is the difference between security for the cloud and security from the cloud. These are not interchangeable terms, and conflating them leads to gaps in coverage.

• Security for the cloud means protecting cloud workloads themselves. This includes native cloud controls and off-the-shelf products for identity and access management (IAM), patch management, and data encryption applied to cloud-hosted resources.
• Security from the cloud means using cloud-delivered services to protect other infrastructure — whether that’s other cloud workloads or on-premises systems. Security-as-a-Service (SECaaS) offerings such as cloud-delivered SIEM, IAM platforms, and vulnerability or application scanning tools fall into this category.

Both dimensions are necessary. Organisations that focus only on securing their cloud environments while ignoring how cloud-based services can extend protection to the rest of the estate are leaving significant coverage gaps.

Regulatory Requirements and the Cloud

Moving workloads to the cloud does not move them outside the reach of compliance obligations. Standards, regulations, and legislation that applied to on-premises environments continue to apply when those same workloads are migrated or rebuilt in the cloud. This is a point that auditors and regulators have increasingly made explicit.

Security leaders should expect auditors to scrutinise the following areas in a cloud context:

• Data sovereignty — where data physically resides and which legal jurisdiction governs it
• Identity and access management — who can access what, under what conditions, and how that access is monitored
• Auditability — whether logs are complete, tamper-evident, and retained appropriately
• Availability — SLA commitments from cloud providers and their alignment with business continuity requirements
• Data classification and encryption — whether sensitive data is identified, labelled, and protected in transit and at rest
• Incident management and response — defined processes for detecting, reporting, and recovering from security incidents in a cloud environment

Where compliance controls have already been documented for on-premises environments, the practical step is to review each control and assess whether it remains applicable, needs to be re-implemented differently, or can be replaced by a cloud-native equivalent that achieves the same outcome more efficiently.

Map Your Cloud Transformation Journey

Cloud transformation is not a single path. Most organisations operate across a mix of transformation contexts simultaneously:

• Migration — lifting and shifting (or re-platforming) existing workloads to a cloud provider
• Hybrid cloud — maintaining on-premises infrastructure alongside cloud resources, often with workloads spanning both
• Cloud-native — designing applications and services specifically to take advantage of cloud capabilities, including containers, serverless functions, and managed services

Migration and hybrid approaches tend to dominate in established enterprises, with cloud-native as the longer-term direction of travel. Regardless of where an organisation sits on this spectrum, the recommended approach is the same:

1. Conduct a current-state security assessment to understand your existing controls, policies, and procedures.
2. Map that assessment to your target cloud environment to identify gaps, overlaps, and opportunities.
3. Develop or refresh a cloud security strategy that reflects the specific deployment model you are using.
4. Look for opportunities to use the cloud environment to automate or improve security-enforcing functions — not just replicate what you had on-premises.

That last point is important. The cloud introduces automation capabilities that can make security controls faster, more consistent, and more scalable than their on-premises equivalents. Treating cloud migration purely as a like-for-like port misses this opportunity.

Infusing Cloud Security Into DevOps

The cloud has fundamentally changed how software is built and operated. DevOps practices — tightly integrated development and operations teams working in continuous delivery cycles — have flourished in cloud environments. But this shift also creates new security challenges that traditional security models were not designed to address.

In many organisations, DevOps engineers now have direct access to cloud environments and the ability to provision infrastructure, configure services, and deploy applications — all at a pace that outstrips traditional security review cycles. If security is positioned as an external gate, it will either slow delivery unacceptably or be bypassed entirely.

The answer is to integrate security into the DevOps workflow itself. Practically, this means:

• Security-as-code — encoding security controls, policies, and compliance checks as code that lives alongside application and infrastructure code in version control. Just as developers write application code and operations teams write infrastructure-as-code (IaC), security requirements can be expressed in the same way.
• Shift-left security — moving security testing, scanning, and policy checks earlier in the development pipeline, so issues are caught before they reach production rather than after.
• Security culture in DevOps teams — helping developers and operations engineers adopt a security mindset, so they identify risks and design controls proactively rather than waiting for a security team to review their work.

This approach — sometimes called DevSecOps — does not replace dedicated security expertise. It extends security thinking throughout the team and allows security professionals to focus on harder problems while automated controls handle routine enforcement.

Different Techniques, Same Outcomes

Across all of these themes, one thing remains constant: the security outcomes organisations are trying to achieve have not fundamentally changed. Confidentiality, integrity, availability, accountability, and compliance are still the goals. What has changed is the tooling, the delivery mechanisms, and the speed at which everything moves.

More automation, faster feedback loops, and greater operational efficiency are not ends in themselves — they are means to delivering those outcomes more reliably and at scale. Cloud security, done well, is not a constraint on innovation. It is a capability that enables the business to move faster with confidence.

Organisations that embed security into their cloud strategy from the start — rather than bolting it on after adoption — are better positioned to use the cloud as a competitive advantage, not just an infrastructure decision.

Originally based on a session summary from the IBM Security Summit, London. Source: securityintelligence.com.

The following five skill areas represent a strong foundation for cloud-focused DevOps engineers, platform engineers, and architects. They are not exhaustive, but they map closely to where employers are spending budget and where hiring demand has been consistently strong.

1. Cloud Security

Security is arguably the most critical cloud skill you can develop, and it is also one of the most misunderstood. A widespread misconception is that once workloads move to a major public cloud provider, security becomes the provider’s problem. This is not how it works.

Every major cloud provider — AWS, Microsoft Azure, and Google Cloud — operates under a shared responsibility model. The provider secures the underlying infrastructure: physical hardware, hypervisors, networking fabric, and the managed services layer. The customer remains responsible for everything built on top: data classification, identity and access management (IAM), network security groups, encryption at rest and in transit, and application-level controls.

Practically, this means cloud engineers need to understand how to configure and use the native security tooling offered by each platform — for example, AWS IAM policies, AWS Security Hub, Azure Security Center, and Azure Policy. Mistakes in these areas are a leading cause of cloud data breaches.

For professionals seeking a vendor-neutral, industry-recognised credential in this space, (ISC)² CCSP (Certified Cloud Security Professional) is well-regarded. It builds on concepts covered in the CISSP and addresses cloud-specific domains including cloud data security, infrastructure security, and legal compliance.

2. Machine Learning and AI on Cloud Platforms

Machine learning and AI have moved well beyond buzzword status. All three major cloud platforms now offer managed ML services that remove much of the infrastructure overhead from model training and deployment. AWS provides SageMaker, Azure offers Azure Machine Learning, and Google Cloud provides Vertex AI.

These managed services lower the barrier to entry significantly. Tutorials, sample notebooks, and pre-built model endpoints make it possible to get a first experiment running quickly. However, extracting real business value from these tools requires a grounding in data science fundamentals: understanding data preparation and feature engineering, evaluating model performance, and avoiding common pitfalls like overfitting.

For DevOps engineers, the adjacent skill of MLOps — applying CI/CD, version control, and monitoring practices to machine learning pipelines — is increasingly valuable. Being the engineer who can reliably deploy and maintain an ML model in production is a distinct and sought-after capability.

3. Serverless Architecture

Serverless computing allows developers to deploy code without managing servers, operating system patches, or capacity planning. The cloud provider handles scaling automatically — including scaling to zero when there is no traffic, which directly reduces cost.

AWS Lambda is the most widely deployed serverless compute service, and its ecosystem of integrations (API Gateway, S3 event triggers, DynamoDB Streams, EventBridge) makes it a realistic foundation for production workloads. Azure Functions and Google Cloud Functions offer comparable models.

Early concerns around vendor lock-in with serverless were valid. If all of your business logic is written against platform-specific bindings, migrating to another provider is painful. The practical mitigation is to keep function logic thin and isolate provider-specific integration code at the edges of your application. Frameworks like the Serverless Framework and AWS SAM provide some abstraction and improve portability.

Key skills to develop in this area include: event-driven design patterns, cold start mitigation strategies, distributed tracing (AWS X-Ray, Azure Application Insights), and infrastructure-as-code deployment of serverless resources.

4. Cloud Migration and Multi-Cloud Deployment

Moving existing workloads to the cloud is rarely straightforward. Applications built for on-premises environments often assume local networking, specific OS configurations, or monolithic deployment models that do not translate directly to cloud-native patterns. Engineers who can assess workloads, design migration strategies, and execute them with minimal downtime are consistently in demand.

Common migration approaches include lift-and-shift (rehosting), re-platforming (moving to managed services like RDS or Azure SQL), and refactoring (redesigning for cloud-native architecture). Each carries different risk and cost profiles, and selecting the right approach for a given workload requires both technical and business judgment.

At enterprise scale, multi-cloud deployments are increasingly common. Organisations may use AWS for compute-heavy workloads, Azure for Active Directory integration and Microsoft 365 connectivity, and Google Cloud for data analytics and AI services. This means engineers who hold knowledge and certifications across multiple platforms — rather than being deeply siloed in one — are better positioned to support enterprise architecture decisions.

Relevant certifications to consider: AWS Solutions Architect, Azure Administrator (AZ-104), and Google Cloud Professional Cloud Architect. Holding two or more of these demonstrates genuine cross-platform capability.

5. Automation and Infrastructure as Code

Automation is the skill that ties everything else together. Cloud infrastructure that is provisioned manually is difficult to reproduce, audit, or scale. Infrastructure as Code (IaC) — defining your infrastructure in version-controlled configuration files — is now a baseline expectation in professional cloud engineering roles.

The core tools to know include:

• Terraform — the most widely adopted cloud-agnostic IaC tool, supporting AWS, Azure, GCP, and dozens of other providers through a consistent HCL syntax.
• AWS CloudFormation / Azure Bicep / Google Cloud Deployment Manager — native IaC options that offer deep platform integration at the cost of portability.
• Ansible and Chef — configuration management tools useful for managing the state of compute instances and automating application deployment.
• Jenkins, GitHub Actions, GitLab CI — CI/CD pipelines that automate testing, building, and deploying cloud workloads.

Auto-scaling policies, automated monitoring and alerting (CloudWatch, Azure Monitor, Grafana), and self-healing infrastructure patterns all fall under this umbrella. Engineers who can design systems that operate reliably without manual intervention are valuable to any team running cloud workloads at scale.

Building Marketable, Cross-Platform Cloud Skills

The clearest pattern in cloud hiring is that cross-platform breadth combined with depth in at least one area is more valuable than narrow specialisation in a single provider. Engineers who understand the shared responsibility model on AWS but can also configure Azure networking or deploy a Terraform module against Google Cloud are easier to integrate into diverse teams and projects.

A practical learning path for a DevOps engineer looking to strengthen their cloud skills might look like this:

1. Gain a foundational certification on your primary platform (AWS SAA, AZ-104, or equivalent).
2. Learn Terraform to at least an intermediate level — provision real infrastructure, use remote state, and manage modules.
3. Build a serverless project end-to-end: an event-driven pipeline or a REST API backed by Lambda or Azure Functions.
4. Study the shared responsibility model and platform-specific security tooling for your primary provider.
5. Add a second platform certification to broaden your market appeal.

The cloud skills gap remains real and persistent. Engineers who invest consistently in these areas position themselves well regardless of which specific technologies dominate any given hiring cycle.

Original article sourced from cloudcomputing-news.net (2018), updated and expanded for current relevance.

The Security Challenge Driving These Announcements

Data visibility is a persistent concern for organizations migrating workloads to the cloud. As Sam Ramji, then Vice President of Google Cloud product development, argued in his keynote at InteropITX, the explosive growth of connected software has created both enormous opportunity and significant security risk. Businesses across every industry are under pressure to ship software faster, yet they must do so with fewer experienced developers and security engineers than the work demands.

Ramji framed the challenge plainly: any system that cannot connect and scale easily will become a liability. The corollary is that any system that cannot be secured at scale will become a liability even faster. Against that backdrop, Google announced two distinct but complementary security initiatives targeting container workloads and cloud-native DevOps pipelines.

Asylo: An Open-Source Framework for Trusted Execution Environments

The first announcement was Asylo, an open-source framework and SDK designed to make Trusted Execution Environments (TEEs) accessible to a broader range of developers.

What Are Trusted Execution Environments?

A TEE is an isolated, hardware-backed execution context — sometimes called an enclave — that protects code and data from threats targeting layers below the application itself: the operating system, hypervisor, firmware, device drivers, and other infrastructure components. Code running inside an enclave is shielded even from privileged software on the host. In practice, this means:

• Sensitive data is encrypted at runtime, not just at rest or in transit.
• The integrity of the running code can be verified, providing assurance that the enclave has not been tampered with.
• Malicious insiders or compromised infrastructure components are prevented from reading enclave contents.

Ramji summarized the goal: “The actual running code in the cloud — I want it to be completely opaque to the provider. I want it to be encrypted in runtime.”

What Problem Did Asylo Solve?

Before Asylo, using a TEE required specialized hardware knowledge, purpose-built toolchains, and significant code changes. TEE implementations were typically tied to specific hardware environments, limiting portability across on-premises and cloud deployments. This meant TEE adoption was largely confined to teams with dedicated security engineering resources.

Asylo lowered that barrier in two meaningful ways:

1. No hardware lock-in. Asylo abstracts away the underlying TEE implementation, so applications are not tied to a specific processor or cloud provider’s enclave technology.
2. No source code rewrite required. Developers can run existing containerized applications in secure mode without restructuring their codebase or acquiring deep expertise in enclave internals.

Google distributed Asylo as a Docker image through the Google Container Registry, giving teams the dependencies they need to run TEE-protected containers anywhere Docker is supported.

Why This Matters for DevOps Teams

Container-based workloads have a broad attack surface. Even if your application code is sound, a compromised host OS or hypervisor can expose secrets. TEEs push the trust boundary down to hardware, which is particularly valuable for workloads handling cryptographic keys, personally identifiable information, financial data, or regulated health records. Asylo aimed to make that protection available to teams without a dedicated security engineering function.

Cloud Security Command Center: Unified Visibility for Container Security

The second announcement — Cloud Security Command Center (Cloud SCC) — addressed a different but related problem: observability. As Ramji put it, “The medium is abundant. What’s scarce is observability.”

Cloud SCC is a centralized security management dashboard within Google Cloud Platform. It aggregates security data from across an organization’s GCP resources, giving administrators a single pane of glass for security posture assessment.

Container Security Integrations at Launch

At the time of the InteropITX keynote, Ramji noted that five container security vendors had integrated their tools with Cloud SCC to surface security data for workloads running on Google Kubernetes Engine (GKE). These integrations enabled administrators to:

• View consolidated security alerts for GKE clusters in a single interface.
• Inventory and organize cluster assets across projects and business units.
• Establish a baseline of normal cluster behavior and detect anomalous activity using defined rules.

Why Observability Is the Core Container Security Problem

Kubernetes environments are inherently dynamic. Pods are created and destroyed frequently, workloads scale horizontally, and network policies change rapidly. Without centralized visibility, detecting a compromised container, a misconfigured RBAC policy, or unexpected outbound network traffic requires correlating logs from multiple disconnected sources. Cloud SCC attempted to collapse that complexity into a structured, queryable view of an organization’s security state.

Effective container security generally requires two things that Cloud SCC was designed to support: a defined baseline of expected behavior, and real-time alerting when observed activity deviates from that baseline. Neither is achievable without comprehensive, centralized data collection.

The Broader Takeaway for DevOps and Platform Engineers

These two announcements reflected a consistent theme in Google Cloud’s 2018 security posture: security controls should be built into the platform and made accessible to developers who are not security specialists, rather than bolted on by dedicated teams after the fact.

• Shift left on trust boundaries. Asylo pushed security guarantees down to the hardware level without requiring developers to reason about enclave internals.
• Centralize observability. Cloud SCC aggregated signals from heterogeneous security tools into a single operational view, reducing the risk of alerts being missed across siloed dashboards.
• Reduce dependency on scarce expertise. Both tools were explicitly designed to be usable without deep security specialization — a practical response to the documented shortage of security-trained engineers in the industry.

For teams running containerized workloads on GCP, evaluating both Asylo and Cloud SCC in the context of your threat model and compliance requirements remains worthwhile. The tools have evolved significantly since 2018; consult current Google Cloud documentation for up-to-date capabilities, supported TEE backends, and pricing.

Original reporting: Dark Reading, May 2018. Keynote: Sam Ramji at InteropITX, 2018.

The Compliance Gap: What the Surveys Found

When the EU’s General Data Protection Regulation (GDPR) took effect on 25 May 2018, most organizations were not fully compliant. Multiple independent surveys, conducted in the months before the deadline, painted a consistent picture: awareness was high, but concrete readiness was not.

The Cloud Security Alliance (CSA) and Netskope released survey results drawn from more than 1,000 respondents. Key findings included:

• 83 percent of respondents said their organization was not very prepared for GDPR.
• 85 percent had taken some steps toward compliance, but only 31 percent had a well-defined plan for meeting GDPR provisions.

A separate survey of 700 network security and IT professionals by Enterprise Strategy Group (ESG) found:

• Only 11 percent of firms were completely ready ahead of the May 25 deadline.
• 33 percent said they were prepared to disclose data breaches within the GDPR-mandated 72-hour window.
• An additional 33 percent were mostly prepared, and 44 percent were somewhat prepared for breach disclosure requirements.
• While only 10 percent had made or planned major GDPR investments, 63 percent committed to incremental investments.

Analyst firm Varonis surveyed 500 IT security professionals across the United States, UK, France, and Germany in October 2017. Their findings showed:

• 60 percent of EU respondents and 50 percent of US respondents faced serious challenges before they could achieve GDPR compliance.
• Despite that, 70 percent of represented firms believed GDPR compliance would give them a competitive advantage.

Where Is the Data? The Fundamental Visibility Problem

A core reason organizations struggled with GDPR was a basic failure to understand where their data actually lives. Compliance with regulations like the right to erasure or data portability is impossible if you cannot locate and inventory personal data in the first place.

Varonis data highlighted the scale of this internal data governance problem:

• 21 percent of organizations’ electronic folders were open to all employees — with no access controls in place.
• 54 percent of surveyed organizations’ data was classified as stale — not actively used but still stored and potentially subject to GDPR obligations.

The shift to hybrid infrastructure — where data is spread across on-premises servers, private clouds, and public cloud providers — compounded the problem. Tracing the origin of customer data and determining whether it is subject to GDPR protection becomes significantly harder in a distributed environment.

“We live in a hybrid world in which data isn’t stored entirely on-premises or completely in the cloud. The hybrid model creates additional challenges and potential risk from a security and data governance standpoint. You can’t assume your data is safe in the cloud. If your cloud environment isn’t secure, your data won’t just be in danger of being exposed to your entire organization — it could be accessible to the world.”

— Ken Spinner, Vice President of Global Field Engineering, Varonis

Uncertainty About GDPR Scope Slowed Progress

Beyond data visibility, legal and regulatory uncertainty was a significant blocker. Key questions that remained unresolved ahead of enforcement included:

• Whether GDPR protections apply to EU citizens only, EU residents, or any individual physically present in EU territory at the time of data collection.
• How the EU would practically enforce fines against non-EU organisations that process EU personal data.
• Which specific technical and organisational measures would satisfy requirements like “data protection by design and by default.”

According to ESG data, fewer than one-third of surveyed organisations fully understood all of GDPR’s requirements. Legal departments were waiting for further regulatory guidance before greenlighting compliance projects — creating a bottleneck that delayed DevOps and engineering teams from doing the work they were already positioned to do.

The CSA/Netskope survey identified the three biggest compliance stumbling blocks:

• Right to erasure — cited by 53 percent of respondents as a major challenge.
• Data protection by design and by default — cited by 42 percent.
• Records of processing activities — cited by 39 percent.

The Stakes: GDPR Penalties

Non-compliance with GDPR carries significant financial penalties. Under the regulation, supervisory authorities can issue fines of up to 4 percent of an organisation’s annual global revenue or €20 million, whichever is higher, for the most serious violations. Lower-tier violations carry fines of up to 2 percent of annual global revenue or €10 million. The scale of potential fines made GDPR a board-level concern, not just an IT one.

Where DevOps Fits In the Compliance Picture

DevOps practices offer genuine capabilities for building and sustaining GDPR compliance — but only after legal and business stakeholders define what compliance actually requires for their specific context. The bottleneck in 2018 was not technical; it was organisational.

Once requirements are defined, DevOps teams can contribute in concrete ways:

• Shifting compliance left: Embedding data protection requirements into the design phase of new applications, rather than retrofitting them after deployment.
• Automated data discovery and classification: Using tooling to continuously scan and classify personal data across hybrid environments, reducing manual audit effort.
• Pipeline controls: Adding automated checks to CI/CD pipelines that flag code or infrastructure changes that could violate data protection policies before they reach production.
• Audit logging and monitoring: Implementing automated audit trails to support both internal governance and regulatory reporting requirements.
• Handling data subject requests at scale: Automating responses to rights requests (access, erasure, portability) — critical for large organisations with millions of data records.

“DevOps can assist companies in complying with regulations like GDPR by ensuring that key regulatory requirements are part of the initial design criteria, and taken into account when applications are updated. GDPR manual methods of enforcing data policy aren’t realistic solutions because large organisations could have millions of files. DevOps can support GDPR requests with processes and solutions that ensure personal data that falls under the new regulations is protected and used appropriately.”

— Ken Spinner, Vice President of Global Field Engineering, Varonis

Key Takeaways for DevOps and Engineering Teams

The 2018 GDPR experience highlighted a recurring pattern in compliance initiatives: technical teams are often ready and able to execute, but they are blocked by organisational, legal, or budget decisions made upstream. For DevOps engineers, the practical lessons are:

• You cannot protect data you cannot find. Data inventory and classification are prerequisites to any compliance programme, and automation is essential at scale.
• Hybrid environments require deliberate governance. Assuming cloud providers handle data security on your behalf is a compliance risk.
• Compliance is not a one-time project. GDPR requires ongoing processes — continuous monitoring, regular audits, and repeatable workflows for handling data subject requests.
• Cross-functional alignment is non-negotiable. Legal, security, product, and engineering teams must define requirements together. DevOps cannot automate what has not been defined.

GDPR enforcement has continued to evolve since 2018, with regulators issuing fines and guidance that have clarified many of the early ambiguities. Organisations building compliance programmes today have more precedent to draw on — but the fundamental challenge of data visibility and cross-team coordination remains.

The following is an excerpt from The Official (ISC)2 Guide to the CCSP CBK, Second Edition, by Adam Gordon, CISSP-ISSAP, ISSMP, SSCP. This section from Domain 1 describes nine cloud security threats waiting to pounce on unsuspecting enterprises. Whether you’re managing a public, private or hybrid cloud, it’s essential for information security professionals to understand where vulnerabilities lie and how to mitigate them.

Threats form a real and ever-evolving challenge for organizations to counteract and defend against. Whether they are specifically cloud security threats or general disruptions to business and technology, threats can cause significant issues, outages, poor performance, and catastrophic impacts should they materialize.

Many of the top risks identified in the research paper The Notorious Nine: Cloud Computing Top Threats, published by the Cloud Security Alliance’s Top Threats Working Group, remain a challenge for non-cloud-based environments and organizations alike. What this illustrates is the consistent challenges faced by entities today, altered and amplified by different technology deployments, such as cloud computing.

Data Breaches
Not new to the security practitioner and company leaders, this age-old challenge continues to dominate headlines and new stories around the world. Whether it is a lost laptop that is unencrypted or side channel timing attacks on VMs, what cloud computing has done is widen the scope and coverage for data breaches.

Given the nature of cloud deployments and multitenancy, VMs, shared databases, application design, integration, APIs, cryptography deployments, key management, and multiple locations of data all combine to provide a highly amplified and dispersed attack surface, leading to greater opportunity for cloud security threats and data breaches.

Cloud security professionals can expect to be facing far more data breaches and loss of organizational and personal information as the adoption of the cloud and further use of mobile devices continue to increase. This is in large measure due to the rise of smart devices, tablets, increased workforce mobility, bring your own device (BYOD), and other factors, such as the historical challenge of lost devices, compromised systems, and traditional forms of attacks, coupled with the previously listed factors related to the cloud.

Depending on the data and information classification types, any data breaches or suspected breaches of systems security controls may require mandatory breach reporting to relevant agencies, entities, or bodies. This can include healthcare information (HIPAA), personally identifiable information (Directive 95/46/EC of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data), and credit card information (PCI DSS).

Significant fines may be imposed on organizations that cannot illustrate sufficient duty of care or security controls being implemented to prevent such data breaches. These vary greatly depending on the industry, sector, geographic location, and nature of the information.

Data Loss
Not to be confused with a data breach, data loss refers to the loss of information, deletion, overwriting, corruption, or integrity related to the information stored, processed, or transmitted within cloud environments.

Data loss within cloud environments can present a significant threat and challenge to organizations. The reasons for its relevance to cloud security threats can be illustrated by the following questions:

Does the provider or customer have responsibility for data backup?
If backup media containing the data is obtained, does this include all data or only a portion of the information?
Where data has become corrupt or overwritten, can an import or restore be performed?
Where accidental data deletion has occurred from the customer side, will the provider facilitate the restoration of systems and information in multitenancy environments or on shared platforms?
Note that when the customer uploads encrypted information to the cloud environment, the encryption keys become a critical component to ensure data is not lost and remains available. The loss of the relevant encryption keys constitutes data loss because the information will no longer be available for use in the absence of the keys.

Security can from time to time come back to haunt you if it is not owned, operated, and maintained effectively and efficiently.

Account or service traffic hacking
This is not a cloud security threat specifically but one that has been a constant thorn and challenge for relevant security professionals to combat through the years. Account and service traffic hijacking has long been targeted by attackers, using methods such as phishing, more recently smishing (SMS phishing), spear phishing (targeted phishing attacks), and exploitation of software and other application-related vulnerabilities.

The key component of these attack methods, when successful, allows for the attackers to monitor and eavesdrop on communications, sniff and track traffic, capture relevant credentials, and access and alter account and user profile characteristics (changing passwords and more).

Of late, attackers are utilizing compromised systems, accounts, and domains as a smokescreen to launch attacks against other organizations and entities, making the source of the attack appear to be from suppliers, third parties, competitors, or other legitimate organizations that have no knowledge or awareness of having been compromised.

Insecure Interfaces and APIs
For users to access cloud computing assets and resources, they utilize the APIs made available by the CSP. Key functions of the APIs, including the provisioning, management, and monitoring, are performed utilizing the provider interfaces. For the security controls and availability of resources to function in the way that they were designed, use of the provider APIs is required to prevent against deliberate and accidental attempts to circumvent policies and controls.

Sounds simple enough, right? In an ideal world, that may be true, but for the modern and evolving landscape riddled with cloud security threats, that challenge is amplified with relevant third parties, organizations, and customers (depending on deployment) building additional interfaces and “bolt on” components to the API, which significantly increase the complexity, resulting in a multilayered API. This can result in credentials being passed to third parties or consumed insecurely across the API and relevant stack components.

Note that most providers make concerted efforts to ensure the security of their interfaces and APIs to minimize cloud security threats; however, any variations or additional components added on from the consumer or other providers can reduce the overall security posture and stance.

Denial of Service
By their nature, denial-of-service (DoS) attacks prevent users from accessing services and resources from a specified system or location. This can be done using any number of attack vectors available but typically look to target buffers, memory, network bandwidth, or processor power.

With cloud services relying ultimately on availability to service and enable connectivity to resources from customers, DoS attacks can become significant cloud security threats. When DoS attacks are targeted at cloud environments, they can create significant challenges for the provider and customer alike.

Distributed denial-of-service (DDoS) attacks are launched from multiple locations against a single target Work with the cloud security architect to ensure that system design and implementation do not create an single point of failure that can expose an entire system to failure if a DoS or DDoS attack is successfully launched against a system.

Note that although it’s widely touted by the media and feared by organizations worldwide, many believe that DoS attacks require large volumes of traffic to be successful. This is not always the case; asymmetric application-level payload attacks have measured success with as little at 100-150 Kbps packets.

Malicious insiders
When looking to secure the key assets of any organization, three primary components are essential—people, processes, and technology. People tend to present the single largest challenge to security due to the possibility of a disgruntled, rogue, or simply careless employee or contractor exposing sensitive data either by accident or on purpose.

According to CERT, malicious insider threats to an organization can come from “a current or former employee, contractor, or other business partner who has or had authorized access to an organization’s network, system, or data and intentionally exceeded or misused that access in a manner that negatively affected the confidentiality, integrity, or availability of the organization’s information or information systems.

Abuse of cloud services
Think of the ability to have previously unobtainable and unaffordable computing resources available for a couple of dollars an hour. Well, that is exactly what cloud computing provides—an opportunity for businesses to have almost unlimited scalability and flexibility. The challenge for many organizations is that this scalability and flexibility are provided across the same platforms or resources that attackers can access and use to execute dictionary attacks, execute DoS attacks, crack encryption passwords, host illegal software and materials for widespread distribution, or implement many other types of cloud security threats. Note that the power of the cloud is not always used in the manner for which it is offered to users.

Insufficient Due Diligence
Cloud computing has created a revolution among many users and companies with regard to how they utilize technology-based solutions and architectures. As with many such technology changes and revolutions, some have acted before giving the appropriate thought and due care to what a secure architecture would look like and what would be required to implement one.

Cloud computing has, for many organizations, become that rash decision—intentionally or unintentionally. The change in roles, focus, governance, auditing, reporting, strategy, and other operational elements requires a considerable investment on the part of the business in a thorough risk-review process, as well as amendments to business processes.

Given the immaturity of the cloud computing market, many entities and providers are still altering and refining the way they operate. There will be acquisitions, changes, amendments, and revisions in the way in which entities offer services, which can influence both customers and partners.

Finally, when the dust settles in the race for cloud space, pricing may vary significantly, rates and offerings may be reduced or inflated, and cloud security threats could force customers to review and revise their selection of a CSP. Should your provider go bankrupt are you in a position to change CSPs in a timely and seamless manner?

It is incumbent upon the cloud security professional to ensure that both due care and due diligence are being exercised in the drive to the cloud.

Due diligence is the act of investigating and understanding the risks a company faces.

Due care is the development and implementation of policies and procedures to aid in protecting the company, its assets, and its people from threats.

Note that cloud companies may merge, be acquired, go bust, change services, and ultimately change their pricing model. Those that fail to carry out the appropriate due diligence activities may in fact be left with nowhere to go or turn to unless they introduce compensating controls to offset such risks (potentially resulting in less financial benefit).

Shared Technology Vulnerabilities
For CSPs to effectively and efficiently deliver their services in a scalable way, they share infrastructure, platforms, and applications among tenants and potentially with other providers. This can include the underlying components of the infrastructure, resulting in shared threats and vulnerabilities.