Skip to main content
We’re on the final domain: Security and Compliance. This lesson covers shared responsibility, security foundations, protection pillars, security automation, multi-account management, and monitoring/posture management. At a high level, a secure cloud environment focuses on three core pillars:
  • Data protection (encryption, backups, retention)
  • Identity & Access Management (authentication, authorization, least privilege)
  • Infrastructure security (networking, compute hardening, edge protection)
For the exam: Domain 6 (Security and Compliance) comprises roughly 17% of the blueprint. This lesson emphasizes task 6.2: apply automation for security controls and data protection.
A slide titled "Foundations of AWS Security — Building a Secure Cloud Environment" showing a cloud and shield icon with three security pillars: Data Protection, Identity & Access Management, and Infrastructure Security. To the right is an "AWS Certified DevOps Engineer – Professional" badge.

​
Shared responsibility model — who does what?

Shared responsibility is central to designing secure systems on AWS. Understand the distinction between AWS-managed controls (“of” the cloud) and customer-managed controls (“in” the cloud):
  • AWS is responsible for the security of the cloud: physical facilities, hardware, network, hypervisor, and foundational managed services.
  • Customers are responsible for security in the cloud: data, identity & access configuration, operating system and application patching, application-level controls, and correct configuration of managed services.
Real-world examples:
  • Running an EC2 instance: you manage the OS, patches, installed software, and access control.
  • Using a fully managed database (RDS): AWS manages the underlying infrastructure and database engine patching (depending on the engine & configuration), but you must configure encryption, network access, and user permissions correctly.
A diagram titled "Shared Responsibility Model Overview" showing two columns for AWS Responsibilities and Customer Responsibilities. The left lists AWS-managed services like Amazon S3, AWS Lambda, and EC2, while the right shows customer-managed items such as AWS KMS, AWS IAM, app security, and security groups.

​
How responsibility shifts by service model

Responsibility boundaries vary with IaaS, PaaS, and SaaS. Below is a quick reference for common AWS services:
A slide titled "Service – Specific Responsibility Models" showing a three-column chart that compares AWS Services, AWS Responsibilities, and Customer Responsibilities. It lists EC2, ECS/EKS, and RDS with the corresponding responsibilities to illustrate how responsibility shifts between AWS and the customer.
Put simply: you are responsible for anything you can see, configure, or control; AWS secures the underlying platform. Example responsibilities:
  • AWS: VPC networking infrastructure, hypervisor, and physical network design/operation.
  • You: VPC subnets, routing, security groups, NACLs, WAF rules, ALB listener rules, API gateway configuration, and application-level protections.
  • Managed services like CloudFront and WAF still require customer configuration (cache behavior, rule sets, origins, and access restrictions).
Defense-in-depth, immutable infrastructure, automated patching, and secure baseline configurations are key architectural patterns. AWS provides services and features to enable these patterns, but customers must enable encryption, logging, monitoring, least-privilege access, and guardrails to avoid accidental exposure.
A schematic titled "Infrastructure Protection" showing a traffic flow from Clients through AWS WAF, Amazon CloudFront, an Application Load Balancer, Kong (IAM API GW), and Nginx to a CSP app. Below it are implementation principles like Defence in depth, Immutable infrastructure, Automated patching, and Secure baseline configurations.
Public exposure of resources (for example, S3 buckets or databases) is one of the most common misconfigurations. Always enable public access blocks, encryption, logging, and versioning where appropriate, and validate policies with policy-as-code tests before deployment.

​
Example: secure S3 bucket via CloudFormation

Below is a basic CloudFormation snippet demonstrating customer-side controls you must enable: server-side encryption, access logging, public access blocks, and versioning. These are configuration-level responsibilities.

​
Security automation — prevention, detection, remediation

Automation is essential to scale security controls consistently. Cover prevention, detection, and remediation across the entire CI/CD and infrastructure lifecycle:
  • Shift-left security: run scans and policy checks during pre-commit, build, and test stages.
  • Enforce gates: block deployments with failing security checks (vulnerable images, policy violations).
  • Remediation workflows: automate incident responses and configuration fixes (Lambda, Step Functions, Systems Manager).
A diagram titled "Implementing Security Automation Across All Pillars" showing CI/CD and cross‑pillar automation flows (Source → Build → Test → AWS) using AWS CodeBuild/CodeDeploy and AWS Lambda. The Lambda node feeds into AWS services for security and operations such as AWS Config, AWS Security Hub, AWS IAM, and AWS Systems Manager.
Common automation approaches:
  • Infrastructure as Code: CloudFormation, CDK, Terraform/OpenTofu to produce reproducible, auditable deployments.
  • Policy-as-code: CloudFormation Guard, CDK security aspects, Open Policy Agent (OPA) to enforce guardrails pre-deploy.
  • Security testing: static analysis and vulnerability scanners (Trivy, Checkov) integrated into pipelines.
  • Automated remediation: AWS Lambda, Systems Manager Automation, and Step Functions to orchestrate responses.
Implementation tools include CloudFormation Guard, CDK security aspects, Open Policy Agent, Trivy, Checkov, and automated remediation patterns. Use these tools to prevent insecure configurations, detect drift and vulnerabilities, and remediate at scale.
A presentation slide titled "Implementing Security Automation Across All Pillars" with a blue header reading "Implementation Tools." Four boxes list AWS CloudFormation Guard, AWS CDK Security Aspects, Open Policy Agent, and Security testing frameworks.

​
Multi-account strategies and centralized guardrails

Large organizations should standardize using AWS Organizations and multi-account patterns:
  • Centralized logging and monitoring (central account for CloudTrail, Config aggregator).
  • Shared services accounts for DNS, IAM provisioning, and tooling.
  • Service Control Policies (SCPs) to enforce organization-level guardrails (e.g., deny S3 bucket deletion, restrict region usage).
  • Centralized detection (GuardDuty, Security Hub, Security Lake) and incident response pipelines.
For the exam, prioritize AWS-native services and how they integrate. Third-party tools may be valid integrations, but most questions expect knowledge of AWS-provided controls and patterns.

​
Measuring security posture

A security posture dashboard tracks consistency and coverage metrics: control consistency, encryption coverage, logging coverage, incident response time, and open gaps (e.g., unencrypted buckets, missing CloudTrail). These metrics drive prioritization for remediation and compliance reporting.
An "AWS Security Posture Dashboard" slide showing a table of security metrics and gaps. It lists items like IAM policy compliance (75%), control consistency (80%), logging coverage (90%), encryption coverage (85%), incident response time (15 mins), and gaps such as 3 unencrypted S3 buckets and 2 accounts missing CloudTrail.

​
Quick summary

  • Shared responsibility: AWS secures the cloud platform; you secure resources and data in the cloud.
  • Focus on three pillars: Data protection, Identity & Access Management, and Infrastructure security.
  • Automate prevention, detection, and remediation across pipelines and accounts using IaC, policy-as-code, and security testing.
  • Use AWS-native centralized services (Organizations, SCPs, CloudTrail, Config, GuardDuty, Security Hub) for guardrails and monitoring.
  • Measure posture with dashboards and metrics and continuously close gaps.
  • AWS Documentation — Shared Responsibility Model
  • CloudFormation, CDK, Terraform/OpenTofu, CloudFormation Guard, OPA, Trivy, Checkov (see respective project pages for docs)
  • AWS services: AWS Organizations, AWS Config, AWS CloudTrail, AWS Security Hub, Amazon GuardDuty, AWS Systems Manager

Watch Video