THE CLOUD SENTINEL: ARCHITECTING SECURITY IN AWS, AZURE AND GCP

Cloud computing has fundamentally reshaped how organisations build, deploy, and scale applications. Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) now power everything from startups to global enterprises. But with this flexibility comes a growing attack surface—and a pressing need for robust cloud security architecture. 

The Cloud Sentinel: a modern security mindset, skill set, and architecture designed to defend cloud-native environments. Unlike traditional perimeter-based security, cloud security requires a deep understanding of shared responsibilities, identity-centric controls, automation, and continuous monitoring. 

This article explores how to architect security across AWS, Azure, and GCP. It covers roles, services, threats, compliance, and learning pathways - so security professionals, architects, and DevOps teams can confidently protect cloud workloads.

The Cloud Sentinel: Architecting Security in AWS, Azure and GCP

Understanding the Shared Responsibility Model 

One of the most misunderstood concepts in cloud security is the Shared Responsibility Model. While each cloud provider implements it slightly differently, the principle remains the same. This model clearly delineates security responsibilities between your cloud provider and your organisation, but the specific division varies by service model (IaaS, PaaS, SaaS). 

For Infrastructure as a Service (IaaS), the cloud provider secures the foundational infrastructure - physical data centres, network hardware, and virtualisation layers—while you retain responsibility for everything built atop it: operating systems, applications, data, and configurations. Platform as a Service (PaaS) shifts more responsibility to the provider, who secures the platform itself, leaving you to manage your implementations and security configurations. In Software as a Service (SaaS), the provider assumes most security duties, with your organisation primarily managing application authorisation and user entitlements. 

Crucially, ultimate accountability cannot be outsourced. Even when using public cloud services, your organisation remains accountable for governance and risk management. It means that while AWS, Azure, and GCP operate, manage, and control components from the host operating system down to physical facility security, you must secure your data, configure identity and access management, define security policies, and manage encryption keys. 

The cloud provider secures the cloud; the customer secures what’s in the cloud.

 

What the Cloud Provider Is Responsible For

Across AWS, Azure, and GCP, providers handle:

Physical data centre security

Hardware, networking, and facilities

Underlying compute, storage, and database infrastructure

Hypervisor and foundational services

 

What the Customer Must Secure

Customers are responsible for:

Identity and access management (IAM)

Operating systems and patching (for IaaS)

Network configurations and firewall rules

Application security

Data protection and encryption

Compliance and governance

 

Misunderstanding this boundary is a leading cause of cloud breaches—especially misconfigured storage buckets, overly permissive IAM roles, and exposed APIs.

 

Role Interdependencies in the Cloud Security Ecosystem

Cloud security is not owned by a single role - it is an ecosystem of interdependent responsibilities.

 

Key Roles and How They Interact

Cloud Architects

Design secure, scalable architectures

Choose services and define trust boundaries

Work closely with security teams to embed controls early

 

Security Engineers / Cloud Security Engineers

Implement IAM policies, encryption, logging, and monitoring

Configure security services like AWS GuardDuty, Azure Defender, or GCP Security Command Centre

Respond to incidents and threats

 

DevOps & Platform Engineers

Build CI/CD pipelines

Implement Infrastructure as Code (IaC)

Ensure automation does not introduce security gaps

 

Developers

Write secure application code

Use cloud-native authentication mechanisms

Avoid hardcoded secrets and insecure APIs

 

Compliance & Governance Teams

Map regulatory requirements to cloud controls

Ensure audit readiness and continuous compliance

Each role depends on the other: architects rely on DevOps for secure automation; analysts depend on architects for visibility, and the compliance team need accurate monitoring data. A failure in one role often cascades into others. Strong communication, automation, and shared visibility are essential.

  

The Cloud Sentinel: Architecting Security in AWS, Azure and GCP

Core Cloud Security Services Across AWS, Azure & GCP

While all major cloud providers offer fundamental security services, their implementations differ significantly, creating challenges in multi-cloud environments.

 

Identity and Access Management (IAM)

IAM serves as your cloud's gatekeeper, defining who can access what resources under which conditions. Each provider approaches this critical function with distinct architectures:

 

AWS IAM employs a flat, granular model built around users, groups, roles, and JSON policies. It offers precision control but requires explicit management for every entity, which can become complex at scale.

 

Azure IAM leverages Microsoft Entra ID (formerly Azure AD) with a hierarchical scope system (management group → subscription → resource group → resource). This enterprise-ready model excels in conditional access policies and integrates seamlessly with existing Microsoft ecosystems.

 

GCP IAM utilises a clean resource hierarchy (Organisation → Folder → Project) with a binding model that associates members with roles. Its strength lies in simplicity, intuitive design, and powerful attribute-based conditions.

 

Best Practices

Enforce least privilege.

Use roles instead of long-lived credentials.

Enable MFA for all privileged accounts.

Regularly review and rotate permissions.

 

 

Network Security, Encryption, and Logging

Beyond IAM, securing your cloud environment requires robust network controls, data protection, and visibility:

 

Network Security & Segmentation

Cloud networks are software-defined, and misconfigurations are common. AWS uses Security Groups and NACLs, Azure employs Network Security Groups, and GCP implements Firewall Rules. All function as virtual firewalls but differ in rule evaluation order and granularity. 

·         Security Groups (AWS & Azure)

·         Network Security Groups (Azure)

·         VPC Firewalls (GCP)

·         Private endpoints and service endpoints

 

Key Controls

·         Zero Trust networking

·         Deny-all by default

·         Use private networking for sensitive services

·         Avoid exposing management interfaces to the internet

 

Encryption & Key Management

All major providers support encryption by default—but it must be configured correctly. Azure and GCP typically enable encryption by default for many services, while AWS often requires explicit activation. All offer customer-managed key options through AWS KMS, Azure Key Vault, and Google Cloud KMS, providing varying levels of control over encryption keys.

 

·         At Rest: KMS (AWS), Key Vault (Azure), Cloud KMS (GCP)

·         In Transit: TLS, HTTPS, private certificates

·         Customer-Managed Keys (CMK) for compliance

 

Encryption without proper key governance is a false sense of security.

 

Logging, Monitoring & Threat Detection

Visibility is non-negotiable. Each provider offers native tools—AWS CloudTrail and GuardDuty, Azure Monitor and Sentinel, GCP Cloud Audit Logs and Security Command Centre. These services provide audit trails but vary in default activation, retention periods, and integration capabilities.

 

·         AWS: CloudTrail, CloudWatch, GuardDuty

·         Azure: Monitor, Log Analytics, Defender for Cloud

·         GCP: Cloud Logging, Cloud Monitoring, SCC

 

Logs should be:

·         Centralized

·         Immutable

·         Actively monitored with alerts

 

Infrastructure as Code (IaC) Security

IaC tools like Terraform, AWS CloudFormation, and Azure ARM/Bicep enable speed—but also scale mistakes instantly.

 

Common IaC Risks

·         Overly permissive IAM roles

·         Publicly exposed resources

·         Hardcoded secrets

·         Drift between the deployed and expected state

 

Securing IaC

·         Use static analysis tools (Checkov, tfsec, Terrascan)

·         Implement policy-as-code (OPA, Sentinel)

·         Enforce code reviews and CI/CD security gates

·         Store state files securely and encrypt them

Shifting security left in the development pipeline is essential. Implement pre-commit and pre-deployment scans of IaC templates to identify misconfigurations before they reach production. For Terraform specifically, never commit .tfstate files to source control, as they may contain sensitive data. Instead, utilise secure backends like AWS S3 with versioning and encryption enabled. 

When handling secrets in IaC, avoid hardcoding credentials. Instead, leverage dedicated secret management solutions such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Modularising IaC code reduces repetitive configurations that can fuel security drift while making updates more manageable.

 

 

Container & Serverless Security

The security landscape shifts significantly when moving from traditional infrastructure to containers and serverless architectures. 

 

Container Security (Docker & Kubernetes)

Containers (Docker, Kubernetes) introduce distinct security concerns: vulnerable base images, runtime threats, and excessive permissions. Implement image scanning in CI/CD pipelines, enforce least-privilege principles for pods and services, and secure the Kubernetes control plane with proper authentication and network policies.

 

Key Risks

·         Vulnerable base images

·         Insecure Kubernetes RBAC

·         Exposed APIs and dashboards

·         Weak runtime security

 

Best Practices

·         Scan images for vulnerabilities

·         Use minimal base images

·         Secure Kubernetes control planes

·         Implement network policies

·         Monitor runtime behaviour

 

Managed Kubernetes services (EKS, AKS, GKE) reduce operational overhead—but security configuration remains the customer’s responsibility.

 

 

Serverless & Functions-as-a-Service (FaaS)

Serverless architectures (AWS Lambda, Azure Functions, Google Cloud Functions) reduce your attack surface by offloading infrastructure management to providers. According to security analyses, serverless is inherently more secure than containers for two primary reasons: it transfers patching responsibilities to the cloud provider and significantly reduces configuration surface area. However, serverless introduces new concerns such as injection attacks, event data tampering, and over-privileged function roles.

 

Common Issues

·         Over-permissioned execution roles

·         Insecure event triggers

·         Unvalidated input

·         Poor logging

 

Security here is identity-driven and event-driven, requiring tight IAM and observability.

 

 

Cloud-Specific Threats and Mitigation

Understanding the threat landscape is essential for effective cloud defense. Recent analyses reveal that most cloud attacks begin with compromised identities. Adversaries increasingly target cloud environments through three primary vectors:

1. Misconfigurations: Publicly accessible storage, overly permissive IAM roles, and disabled logging create opportunities for attackers.

2. Credential Theft: Through phishing, exposed API keys, or stealer malware, adversaries gain footholds in cloud environments.

3. Insecure APIs: Poorly protected management and application interfaces provide direct pathways to cloud resources. 

Adversaries employ specific techniques once they gain access:

• Impairing Defenses: Disabling or modifying logging and firewall rules to operate undetected.

• Account Manipulation: Adding privileged roles to compromised identities to escalate privileges.

• AI Service Abuse: With cloud providers offering AI services, adversaries can exploit these for high-cost attacks, reputational damage, or intellectual property theft.

 

Essential Skills for The Modern Cloud Sentinel

To succeed in cloud security, professionals must blend multiple disciplines:

 

Cloud Architecture: Deep understanding of AWS, Azure, or GCP services

Automation & Scripting: Python, Bash, PowerShell

DevOps Mindset: CI/CD, GitOps, continuous improvement

Security Fundamentals: IAM, encryption, networking

Threat Modelling: Thinking like an attacker

For structured learning, consider certifications such as AWS Certified Security - Speciality, Microsoft Certified: Azure Security Engineer Associate, or Google Professional Cloud Security Engineer. Organisations like SANS Institute offer specialised courses such as SEC510: Cloud Security Engineering and Controls and SEC549: Cloud Security Architecture. Cloud security rewards those who can design, automate, and secure at scale.

 

 

Learning Pathways: Courses, Certifications & Hands-On Practice

 

Certifications

AWS Certified Security – Speciality

Microsoft Azure Security Engineer (AZ-500)

Google Professional Cloud Security Engineer

CCSK (Cloud Security Alliance)

 

Hands-On Learning

Build labs using free-tier accounts

Practice with intentionally vulnerable cloud environments

Participate in cloud security CTFs

Secure real-world projects using IaC

 

Theory matters—but hands-on experience is non-negotiable.

 

Navigating Compliance Frameworks

Compliance in the cloud follows the shared responsibility model, with ultimate responsibility resting with your organisation. Cloud providers offer compliance enablers - AWS provides functionality and legal agreements to support customer compliance, while Azure and GCP offer similar frameworks aligned with standards such as GDPR, NIST 800-53, ISO 27001, SOC 2, HIPAA, and PCI DSS.

 

Implementing compliance requires:

1. Mapping cloud controls to regulatory requirements using provider documentation

2. Implementing continuous compliance monitoring rather than point-in-time assessments

3. Leveraging native tools like AWS Security Hub, Azure Policy, and GCP Security Command Centre

 

 

Common Challenges—and How to Overcome Them

 

Challenge: Complexity

Solution: Standardise architectures and use reference designs

 

Challenge: Skill Gaps

Solution: Continuous learning and cross-team collaboration

 

Challenge: Visibility

Solution: Centralised logging and SIEM integration

 

Challenge: Speed vs Security

Solution: Shift-left security and automation

 

For all roles, human error remains the overwhelming factor in cloud breaches. Addressing this requires security education tailored to specific responsibilities, not generic security awareness training. Cloud security is not about slowing innovation - it’s about enabling it safely.

 

 

Conclusion: Becoming the Cloud Sentinel

Architecting security in AWS, Azure, and GCP is no longer optional—it’s foundational. The Cloud Sentinel mindset embraces shared responsibility, identity-first security, automation, and continuous vigilance. 

Organisations that succeed in the cloud treat security as:

• Built-in, not bolted-on

• Automated, not manual

• Collaborative, not siloed

As cloud adoption accelerates, the demand for skilled cloud security professionals will always grow. Whether you're an architect, engineer, or aspiring defender, mastering cloud security today positions you at the forefront of cybersecurity tomorrow. 

Stay vigilant. Stay automated. Be the Cloud Sentinel.