Skip to main content
Welcome back, Solutions Architects. This lesson covers the final group of identity, detection, auditing, and encryption services — and practical ways to “turn up” security on the security services themselves. This is a concise section: focus on the core controls, operational practices, and the diagrams that illustrate them.

The power of access (IAM)

Access control is the foundation of cloud security. In AWS, Identity and Access Management (IAM) provides managed primitives for authentication and authorization: policies, roles, groups, CloudTrail auditing of API calls, Access Analyzer, and reporting. IAM is secure-by-default, but configuration and operational practices significantly increase protection. Key practices:
  • Enforce least privilege: grant only the permissions required for an identity or resource to perform its tasks.
  • Require multi-factor authentication (MFA) for interactive access and sensitive operations.
  • Audit API activity with CloudTrail and review IAM Access Analyzer reports and IAM findings regularly.
  • Avoid embedding secrets in templates or repositories — use Secrets Manager or Systems Manager Parameter Store.
Use role-based access and permission boundaries to limit blast radius. Prefer short-lived credentials and role assumption patterns for services and automation.
A slide titled "Designing for Security – IAM" showing an AWS architecture diagram where a customer launches a CloudFormation template that creates a cross-account IAM role and a custom resource sends the role ARN via Amazon SNS to your company's account. The slide also notes "Use MFA with IAM where possible."
Operational notes:
  • Defining one role-per-application or per-resource (where practical) reduces over-permissioning.
  • Use CloudTrail to investigate who assumed a role or made changes to policies and roles.
An infographic showing an AWS IAM scenario asking how to enforce least-privilege for EC2 instances, an S3 bucket, and a DynamoDB table. Four numbered answer boxes list options like creating a single admin role, defining specific roles per resource, avoiding template-specified roles, and using root credentials.
Never commit sensitive credentials to source control or embed them in CloudFormation templates. Use Secrets Manager or Systems Manager Parameter Store (SecureString) to store and retrieve secrets securely.
A presentation slide titled "Designing for Security – IAM" showing a diagram where AWS Secrets Manager supplies security credentials to CloudFormation templates and instances. The slide warns not to embed sensitive credentials in CloudFormation (CF) templates.
When a question asks where to store database credentials, the recommended answers are:
  • AWS Secrets Manager — for automatic rotation, secure retrieval, and audit logging.
  • Systems Manager Parameter Store (SecureString) — for simpler secret storage if rotation and other Secrets Manager features are not required.
A colorful infographic describing a scenario where a software company uses AWS IAM to deploy a web app and needs to securely manage database credentials. It lists four options (hardcode, AWS Secrets Manager, KMS-encrypt in the template, or store in S3) and highlights using AWS Secrets Manager as the recommended approach.
IAM integrates with CloudTrail (API call auditing) and with the CloudFormation console for stack event visibility. For auditing all IAM or CloudFormation changes, query CloudTrail events.
A slide titled "Designing for Security – IAM" showing an AWS CloudFormation console screenshot with a stack event log (CREATE/UPDATE/DELETE statuses) and a caption noting IAM reports events to CloudTrail and the CF console. The right side displays timestamps, resource types, logical IDs, and status messages for CloudFormation actions.
An infographic asking how a large enterprise should track and monitor AWS IAM stack events. It lists four options including enabling AWS Config, using Amazon CloudTrail events, exporting IAM stack events to an S3 bucket for auditing, and manually checking the IAM console.
Best-practice checklist for IAM:
  • Use least privilege and permission boundaries.
  • Use role assumption with short-lived credentials for automation (STS).
  • Enable MFA for interactive users.
  • Audit with CloudTrail and analyze with Access Analyzer.

IAM Identity Center (SSO)

IAM Identity Center centralizes identity and access across multiple AWS accounts and applications. Harden it by:
  • Applying least-privilege permission sets.
  • Requiring MFA for high-risk roles.
  • Using permission boundaries and Verified Permissions to constrain cross-account actions.
  • Integrating with AWS Organizations and Control Tower for centralized account provisioning and guardrails.
A slide diagram titled "Designing for Security – IAM Identity Center (SSO)" showing SSO federation from on‑premises (Active Directory) to AWS IAM Identity Center. It illustrates permission sets and SSO roles being assigned to workload and emergency operations accounts.

Amazon Cognito

Amazon Cognito manages authentication for web and mobile applications. Think of Cognito user pools as the user store and identity pools as the mechanism to map authenticated users to AWS credentials and IAM roles. Cognito should be treated as part of your identity fabric and integrated with IAM using least-privilege roles. Recommendations:
  • Enforce least-privilege IAM roles assigned via Cognito identity pools.
  • Ensure CloudTrail logging for Cognito to capture authentication events.
  • Secure any synchronization with external directories or identity providers.
A presentation slide titled "Designing for Security – Cognito" showing an AWS Cognito authentication architecture. It diagrams users signing in (via Google or a Cognito user pool), getting credentials through a Cognito Identity Pool, and accessing API Gateway → Lambda → DynamoDB.

AWS Directory Service

AWS Directory Service hosts managed Microsoft Active Directory and other directory types. The service is secure by design; your focus should be on trust relationships and integration patterns (federation, AD Connect, AD FS) to prevent privilege escalation and unauthorized access.
A presentation slide titled "Designing for Security – Directory Service" showing a diagram of how AWS Microsoft AD (Standard Edition) integrates with AWS apps and EC2, AD-aware workloads, Azure AD/Office 365, and on‑premises Active Directory. The diagram illustrates synchronization, federation (AD FS/ADSync), and authentication/authorization flows between cloud services and a corporate data center.

Verified Permissions

Amazon Verified Permissions (Cedar policy language) helps author, validate, and test fine-grained authorization rules. It integrates with identity services like Cognito and is valuable for programmatically asserting that authorization behavior matches policy templates.
A presentation slide titled "Designing for Security – Verified Permissions" explaining Amazon Verified Permissions and how it works with Cognito. It shows a flow diagram for creating schemas, managing policies, and authorizing access for AWS services (API Gateway, Lambda, AppSync) and identity providers.

The power of auditing: CloudTrail, CloudWatch, and AWS Config

Auditing and observability are essential for detection, incident response, and compliance.
  • CloudWatch — application and infrastructure metrics, logs, and alarms.
  • CloudTrail — API-level auditing; the primary source-of-record for AWS API calls and user activity.
  • AWS Config — records resource configurations and evaluates compliance against rules.
Best practices:
  • Export and encrypt CloudTrail logs (S3) with KMS-managed keys.
  • Use CloudTrail Lake for queryable event analytics.
  • Implement AWS Config rules for drift detection and automate remediation with EventBridge/Lambda or Systems Manager Automation.
  • Ensure alerts and runbooks connect findings into your incident response pipeline.
A presentation slide titled "Designing for Security – AWS Config" showing the AWS Config console General settings screen with options for recording strategy, resource types, and data retention. The left side includes the note "AWS Config captures all changes.." and a KodeKloud copyright.
Quick distinctions:

AWS Artifact

AWS Artifact provides on-demand access to AWS compliance reports and attestations (ISO, SOC, PCI, etc.). Artifact does not change your security posture — it supplies evidence for audits and assessments.
A presentation slide titled "Designing for Security – Artifact" stating that artifacts have no security implications because they share AWS compliance and agreement documents. The slide shows a screenshot of the AWS Artifact reports list with example report entries (e.g., HDS Certification, ABS Cloud Computing, APRA CPG 234).
Use Artifact when auditors request AWS compliance documentation to support evidence collection.

The power of detection

Detection services provide the telemetry and analysis to surface suspicious or malicious activity. Key managed services:
  • Amazon GuardDuty — threat detection across CloudTrail, VPC flow logs, DNS logs, and other telemetry.
  • Amazon Inspector — vulnerability assessment for hosts, containers, and serverless functions.
  • Amazon Macie — discovery and classification of sensitive data (PII) in S3.
  • AWS Security Hub — centralized aggregation, normalization, and prioritization of findings and compliance checks.

Amazon GuardDuty

GuardDuty analyzes telemetry, applies threat intelligence and ML, and produces actionable findings. Enable GuardDuty across accounts (Organization integration) and ensure findings flow to Security Hub or automated remediation processes.
A presentation slide titled "Designing for Security – GuardDuty" describing Amazon GuardDuty as a managed threat detection service. A diagram shows the workflow: enable GuardDuty, continuously analyze CloudTrail/VPC/DNS logs, intelligently detect threats, and take automated or manual remediation actions.
An infographic describing how AWS GuardDuty helps a financial services company improve security, with a blue header question and four numbered summary points about GuardDuty’s capabilities (threat detection, network insights, security best-practice checks, and identifying security gaps). The layout uses colored boxes and icons to present each key capability.

Amazon Inspector

Inspector scans images, instances, and supported runtimes for known CVEs and insecure configurations. Ensure the right resource coverage and integrate findings with ticketing or automated remediation playbooks.

Amazon Macie

Macie discovers and classifies sensitive objects in S3 and can initiate workflows (EventBridge → Lambda) to quarantine or remediate exposures.
A diagram titled "Designing for Security – Macie" showing an AWS architecture where Amazon Macie scans S3 buckets for sensitive data (like PII) and triggers EventBridge/Kinesis/Lambda workflows. The workflow classifies objects, moves them between S3 buckets, and either archives them to S3 Glacier or marks them to expire.

AWS Security Hub

Security Hub aggregates findings from GuardDuty, Inspector, Macie, and partners. Treat Security Hub as a central dashboard — control access via IAM and ensure findings feed into prioritization and remediation workflows. Summary table — Detection services:

The power of encryption: KMS and CloudHSM

Key management and HSM choices:
  • AWS KMS — managed key service (AWS-managed or customer-managed CMKs), integrated with AWS services for envelope encryption and centralized key policies.
  • AWS CloudHSM — single-tenant hardware security modules for customers needing dedicated hardware and direct HSM control.
Access to keys is enforced by IAM and KMS key policies. Choose CloudHSM if single-tenancy or direct HSM control is required for compliance; otherwise, KMS meets most use cases and integrates across AWS services.
A presentation slide titled "Designing for Security – AWS Encryptions" showing a KMS key diagram that converts an encrypted data key into a plaintext data key via a decryption algorithm. The slide also notes that KMS and CloudHSM handle data protection and that encryption keys can be software or physical appliances.
Decision summary:
A slide titled "Designing for Security – KMS/CloudHSM" showing a diagram of AWS CloudHSM certificate hierarchy and hardware components (root certificates, HSM hardware, cluster HSM) and how a customer private key/certificate is signed. On the left is a note stating CloudHSM is a hardware appliance at AWS providing single-tenancy, hardware-based cryptography.
If a question asks which service creates and controls encryption keys used by S3, RDS, etc., the standard answer is KMS. Choose CloudHSM when dedicated HSM hardware is a compliance or technical requirement.
This completes Part 1 of turning up security on security services. The recurring theme: most AWS security services are secure-by-default and fully managed — your role as a solutions architect is to enable the right services, enforce least-privilege access, ensure logging and monitoring (CloudTrail / CloudWatch / AWS Config), and wire findings into remediation and governance workflows.

Watch Video