Skip to main content
Welcome back to Solutions Architect Associate. Instructor: Michael Forrester. This guide summarizes seven practical domains of cloud security you should design for and verify. Unlike high-level design principles, these domains map directly to services, controls, and operational responsibilities: Security Foundations, Identity and Access Management, Detection, Infrastructure Protection, Data Protection, Application Security, and Incident Response. Use them to ask the right design questions: Do we have this? Who owns it? How is it measured?
A slide titled "Areas of Cloud Security." It shows seven numbered colored tiles listing Foundations; Identity and Access Management; Detection; Infrastructure Protection; Data Protection; Application Security; and Incident Response.
Why these areas matter
  • They categorize controls and services so teams can assign ownership and design targeted mitigations.
  • For any security request, identify the domain first (e.g., data protection vs. detection) and then pick the correct service or control to implement.
Security Foundations
  • Purpose: Establish governance, responsibilities, and baseline practices across the cloud environment.
  • Key concerns: Ownership (who is responsible), asset inventory, patch/update cadence, and threat identification workflows.
  • Typical controls: Account management (AWS Organizations), patching strategies, metadata and asset inventories, and documented security objectives and SLAs.
A presentation slide titled "Security Foundations" with a colorful bullseye target and arrow on the left. On the right are bullet points listing pre-work questions (who, what, when, where, how) and security objectives like updating and identifying threats.
Identity and Access Management (IAM)
  • Purpose: Control who or what can access resources and what actions they can perform.
  • Key practices: Least privilege, role separation, short-lived credentials, federated identity, and policy governance.
  • AWS examples: AWS IAM (users, groups, roles, policies), AWS Organizations (account-level controls), and external identity providers for SSO/federation.
A presentation slide titled "Identity and Access Management" with a user icon, gear, and denial symbol linked to a device graphic. Two bullet points note having a strong identity management process and that this area governs identity and permissions.
Detection
  • Purpose: Discover security-relevant events (configuration changes, suspicious activity, anomalies, or confirmed compromises).
  • Key elements: Centralized logging, metrics, event collection, automated analysis, and alerting.
  • AWS examples: CloudTrail (API activity and data events), Amazon CloudWatch (metrics/alarms), AWS Config (resource configuration history), Amazon GuardDuty (threat detection), Amazon Inspector (vulnerability assessment), and AWS Security Hub (centralized findings).
  • Outcomes: Alerts, automated remediation, or escalation to incident response processes.
A presentation slide titled "Detection" showing a dashed "Central Location" box with circular icons (a bell and an "Action" button) and bullet points about detecting unexpected configuration changes and actions. The slide also notes centralizing logs, metrics and responses for analysis.
Infrastructure Protection
  • Purpose: Harden networking, compute, and storage to prevent unauthorized access or lateral movement.
  • Key practices: Network segmentation, perimeter and host controls, patch management, and runtime protections.
  • AWS examples: VPC design (subnets, routing, NACLs, security groups), AWS WAF / AWS Shield, AWS Network Firewall, and vulnerability scanning with Amazon Inspector.
Application Security
  • Purpose: Secure software across the development lifecycle (build, test, deploy, run).
  • Key practices: Secure coding, dependency management, CI/CD pipeline security, static/dynamic analysis, trusted base images, and runtime protection.
  • Integrate security into development: code reviews, SCA (software composition analysis), and automated scans in the pipeline.
Data Protection
  • Purpose: Protect data at rest, in transit, and throughout its lifecycle (classification, retention, deletion).
  • Key controls: Encryption, key management, access controls, tokenization, data classification, and proper backup protections.
  • AWS examples: AWS KMS for key management, server-side encryption options for S3 (SSE-S3, SSE-KMS), client-side encryption, and discovery tools like Amazon Macie for sensitive data discovery.
A slide titled "Data Protection" with a stylized cabinet icon and bullet points about protecting data at rest, data in transit, and data classification. It also lists related practices like encryption, key management, and data lifecycle.
Incident Response
  • Purpose: Prepare for and execute the operational steps when a security event occurs.
  • Core activities: Maintain an incident response plan, define roles/runbooks, practice tabletop exercises and simulations, preserve forensic tooling and access, and run post-incident reviews for continuous improvement.
  • Objective: Reduce detection-to-remediation time and ensure repeatable, tested response workflows.
A slide titled "Incident Response" showing three colored circles labeled Knowledge, Practice, and Preparation. The right side lists implementation steps and practices like security education, preparation, simulation, and setting response objectives.
Quick reference table — Security areas, intent, and AWS examples Applying the areas to real requirements (S3 examples)
  • Map a requirement to the area first, then pick the right service or feature to implement.
Examples:
  • “I need to increase protection of my S3 data.” — Data Protection: enable bucket/object encryption (SSE-S3, SSE-KMS, or client-side encryption) and manage keys with AWS KMS.
  • “I need logs about who is accessing my S3 objects.” — Detection: enable S3 server access logging and CloudTrail data events for S3; centralize logs for analysis and alerting.
  • “I need to control who can access my S3 buckets.” — Identity and Access Management: implement least-privilege IAM policies and roles, use bucket policies for resource-level controls; avoid ACLs unless maintaining legacy behavior.
A diagram titled "Applying the Areas of Security" showing an Amazon S3 bucket on the left with three requirements (increase data protection, get access logs, control access) mapped to security areas (Data Protection, Detection, Identity & Access Management) and corresponding S3 features (bucket/object encryption, S3 access logs, AWS IAM/ACLs).
Summary and practical guidance
  • Use these seven security areas alongside cloud design principles. First identify the area of concern, then map to service features that address it (encryption, logging, IAM policies, threat detection, pipeline security, etc.).
  • Some domains (like incident response) are process- and people-focused but are as crucial as technical controls in real-world practice.
  • When asked for a change, ask: Which security area does this concern belong to? Who owns it? How will we measure effectiveness?
Tip: Start every security design conversation by naming the domain (one of these seven). That prevents applying the wrong control for the wrong problem and helps you select the right AWS services.
If you have questions, contact me.

Watch Video