Security

AWS Firewall Manager – Centralized Security Policies

~ Last updated on : ~ Kiro Agent ~ Leave a comment

AWS Firewall Manager

  • AWS Firewall Manager is a security management service that simplifies administration and maintenance tasks across multiple accounts and resources for a variety of protections.
  • Firewall Manager enables centrally configuring and managing firewall rules across accounts and applications in an AWS Organization.
  • With Firewall Manager, protections are set up once and the service automatically applies them across accounts and resources, even as new accounts and resources are added.
  • Firewall Manager is particularly useful when protecting an entire organization rather than a small number of specific accounts, or when frequently adding new resources that need protection.
  • Firewall Manager provides centralized monitoring of DDoS attacks across the organization.
  • A Firewall Manager administrator account (delegated from the Organizations management account) manages all policies centrally.

AWS Firewall Manager Key Features

  • Centralized Security Policy Management
    • Create and enforce security policies across all accounts in an AWS Organization from a single administrator account.
    • Policies are applied automatically to existing resources and to new resources as they are created.
    • Supports hierarchical rule enforcement — centrally applied rules are constantly monitored for accidental removal or mishandling.
  • Auto-Remediation of Non-Compliant Resources
    • Automatically bring non-compliant resources into compliance by deploying protections (e.g., creating WAF Web ACLs, associating security groups, deploying Network Firewall endpoints).
    • Can be configured to either auto-remediate or notify only, allowing a phased rollout.
    • Best practice is to start without auto-remediation to identify resources requiring manual handling, then enable auto-remediation when confidence is established.
  • Cross-Account Protection Policies
    • Integrated with AWS Organizations to automatically discover all accounts.
    • Policies can be scoped to all accounts or specific OUs and accounts.
    • New in-scope accounts that join the organization are automatically protected.
  • Compliance Dashboard with Notifications
    • Visual dashboard to quickly view protected AWS resources, identify non-compliant resources, and take action.
    • SNS notification streams for configuration changes.
    • Reports non-compliant issues including VPCs and accounts missing protections.
  • Hierarchical Rule Enforcement
    • Allows applying protection policies hierarchically — centrally mandated rules can be enforced while delegating application-specific rule creation to individual accounts.
    • For WAF policies, first and last rule groups are enforced centrally, while account owners can add rules in between.
  • Third-Party Firewall Support
    • Centrally deploy and monitor AWS Marketplace subscribed third-party cloud firewalls (e.g., Palo Alto Networks Cloud NGFW, Fortinet) across all VPCs in the organization.
    • Automates cross-account deployment of firewalls, association of rules, and VPC route configuration.

AWS Firewall Manager Supported Policy Types

  • Firewall Manager supports multiple types of protection policies, similar to how Amazon RDS supports multiple database engines.

AWS WAF Policy

  • Centrally deploys AWS WAF Web ACLs with rule groups across Application Load Balancers, API Gateways, Amazon CloudFront distributions, AWS AppSync GraphQL APIs, Amazon Cognito user pools, AWS App Runner services, and AWS Verified Access instances.
  • Defines first and last rule groups that are enforced centrally — individual accounts can add rules between them.
  • Supports AWS Managed Rules and Marketplace managed rule groups.
  • Automatically creates Web ACLs in member accounts and associates them with in-scope resources.

AWS Shield Advanced Policy

  • Applies Shield Advanced protections across the organization for specified resource types.
  • Protects Application Load Balancers, Classic Load Balancers, Elastic IP addresses, CloudFront distributions, and Global Accelerator accelerators.
  • Automatically subscribes in-scope accounts to Shield Advanced.
  • Associates empty WAF Web ACLs with resources for DDoS mitigation layer.

Amazon VPC Security Group Policy

  • Three types of security group policies:
    • Common security groups — Creates and applies a baseline security group across EC2 instances, ENIs, and Elastic Load Balancers in VPCs.
    • Auditing security groups — Defines guardrails for what security group rules are allowed/disallowed, detects overly permissive rules.
    • Usage auditing security groups — Identifies unused and redundant security groups for cleanup.
  • Continuously monitors security groups for compliance and can auto-remediate violations.

Amazon VPC Network ACL (NACL) Policy

  • Centrally manages VPC network access control lists across the organization (added April 2024).
  • Defines first and last rules for inbound and outbound traffic — individual accounts can create custom rules in between.
  • Enforces presence and ordering of rules in network ACLs within policy scope.
  • Reports non-compliance for NACLs that don’t match the policy configuration.

AWS Network Firewall Policy

  • Centrally deploys AWS Network Firewall endpoints across VPCs in the organization.
  • Supports three deployment models:
    • Distributed — Firewall endpoints deployed in each VPC within policy scope.
    • Centralized — Single firewall in an inspection VPC.
    • Import existing firewalls — Import existing Network Firewalls for centralized management.
  • Automatically manages VPC route tables to route traffic through firewall endpoints.
  • Changes to centrally configured rules are automatically deployed to all accounts and VPCs.

Amazon Route 53 Resolver DNS Firewall Policy

  • Centrally associates VPCs with Route 53 Resolver DNS Firewall rule groups across the organization.
  • Filters DNS queries to block resolution of known malicious domains.
  • Supports shared domain lists for consistent DNS filtering across all accounts.
  • Prevents DNS exfiltration and C2 communications.

Palo Alto Networks Cloud NGFW Policy (Third-Party)

  • Centrally deploys Palo Alto Networks Cloud NGFW resources and rulestacks across all accounts.
  • Supports both distributed and centralized deployment models.
  • Provides advanced threat prevention capabilities including App-ID, URL filtering, DNS Security, WildFire, and Enterprise DLP.
  • Managed through either AWS Firewall Manager native policy or Panorama Cloud Device Groups.
  • Requires active Cloud NGFW subscription from AWS Marketplace.

Fortinet FortiGate Cloud Native Firewall Policy (Third-Party)

  • Centrally deploys Fortinet FortiGate firewalls across VPCs using Firewall Manager.
  • Available through AWS Marketplace subscription.

AWS Firewall Manager Prerequisites

  • AWS Organizations
    • Accounts must be part of an AWS Organization with all features enabled.
    • Organization management account designates a Firewall Manager administrator (delegated administrator).
  • AWS Config
    • AWS Config must be enabled in all accounts and Regions where Firewall Manager policies will be applied.
    • Config records resource configuration changes that Firewall Manager uses to track compliance.
    • Firewall Manager creates Config rules automatically per policy per account to monitor compliance.
  • Firewall Manager Administrator Account
    • Must be a member account in the organization (or management account).
    • Designated by the Organizations management account.
    • Uses a delegated administrator model — can be the management account or a dedicated security account.
    • Best practice: Use a dedicated security account (not the management account) as the Firewall Manager administrator.
  • AWS WAF (for WAF policies)
    • Must use AWS WAF (not WAF Classic) for new policies.
  • Shield Advanced Subscription (for Shield policies)
    • Required only if creating Shield Advanced policies.
    • Shield Advanced subscription fee applies ($3,000/month per organization).
  • Third-Party Marketplace Subscriptions (for third-party policies)
    • Active subscription to the third-party firewall product in AWS Marketplace is required in all target accounts.

Policy Scope and Auto-Remediation

Policy Scope

  • Firewall Manager policies can be scoped using:
    • Account scope — Include all accounts in the organization, specific OUs, or specific accounts. Exclude specific accounts or OUs.
    • Resource type — Target specific resource types (e.g., ALBs, CloudFront distributions, EC2 instances).
    • Resource tags — Include or exclude resources based on tags. Supports both inclusion and exclusion tag lists.
  • Specifying an OU is equivalent to specifying all accounts in that OU and any child OUs, including accounts added later.
  • Best practice: Exclude the Firewall Manager administrator account from security group policies.

Auto-Remediation

  • When enabled, Firewall Manager automatically applies protections to non-compliant resources:
    • WAF policies — Creates Web ACLs and associates them with unprotected resources.
    • Shield policies — Enables Shield Advanced protection and associates empty Web ACLs.
    • Security group policies — Creates and applies security groups, removes non-compliant rules.
    • Network Firewall policies — Creates firewall endpoints and configures VPC route tables.
    • DNS Firewall policies — Associates rule groups with VPCs.
    • NACL policies — Updates network ACLs to match policy rules.
  • When disabled, Firewall Manager reports non-compliance but does not make changes — useful for monitoring mode.
  • Recommended approach: Start with auto-remediation disabled to identify resources requiring manual handling, then enable it when confident in the policy scope.

Integration with AWS Security Hub

  • Firewall Manager integrates natively with AWS Security Hub to send compliance findings.
  • Findings are generated for:
    • Resources that are out of compliance with Firewall Manager policies.
    • Attacks detected by Shield Advanced.
    • Resources missing expected protections.
  • Security Hub aggregates findings across accounts and Regions for centralized visibility.
  • Enables SOC teams to track and respond to compliance drift from a single pane of glass.
  • Supports automated remediation workflows when combined with Security Hub custom actions and EventBridge.
  • Integration can be enabled/disabled from the Security Hub console under Integrations.

Cross-Account Management

  • Firewall Manager uses the delegated administrator model for cross-account management.
  • The Firewall Manager administrator can:
    • Create and apply policies across all member accounts.
    • View compliance status of all accounts.
    • Monitor DDoS events across the organization.
    • Manage WAF rule groups that are shared across accounts.
  • Individual account owners can:
    • Add their own rules between centrally managed first and last rule groups (WAF policies).
    • View compliance status for their own resources.
    • Cannot remove or modify centrally enforced rules.
  • Firewall Manager uses AWS Organizations service-linked roles to deploy resources in member accounts.
  • Multiple Firewall Manager administrators can be designated with different administrative scopes.

Firewall Manager vs Individual Service Management vs Control Tower Guardrails

Feature Individual Service Management AWS Firewall Manager AWS Control Tower Guardrails
Scope Single account, manual per-account setup Multi-account via Organizations, centralized policies Multi-account governance and compliance controls
Primary Purpose Configure individual firewall/security resources Centralized firewall policy deployment and enforcement Account governance, SCPs, and compliance baselines
Auto-Remediation Not built-in (requires custom automation) Yes — automatically deploys protections to non-compliant resources Preventive (SCPs block actions) and Detective (Config rules report violations)
New Account Handling Manual configuration required Automatic — policies applied to new accounts/resources immediately Automatic via Account Factory and enrolled OUs
Policy Types Depends on individual service (WAF rules, SGs, NACLs) WAF, Shield, Security Groups, NACLs, Network Firewall, DNS Firewall, Third-party SCPs, Config Rules (detective/proactive), CloudFormation Hooks
Focus Area Network/application layer protection configuration Network/application layer firewall policy enforcement at scale Broad governance (IAM, logging, networking, data residency)
Compliance Monitoring Must configure separately (Config, CloudWatch) Built-in dashboard + Security Hub integration Built-in Control Tower dashboard
Prerequisites None beyond IAM permissions Organizations (all features), AWS Config Organizations, Control Tower landing zone
Cost Only the underlying service charges $100/policy/Region/month + underlying service charges No additional charge (pays for underlying Config rules)
Best For Small environments, single account, simple setups Multi-account firewall/security policy enforcement at scale Overall account governance, compliance frameworks, landing zone management
Complementary Use Used alongside Firewall Manager as the underlying service Works with Control Tower — Firewall Manager handles network security while Control Tower handles governance Works with Firewall Manager — Control Tower handles governance while Firewall Manager handles firewall policies

When to Use Which

  • Individual Service Management — Single-account environments, proof of concepts, or when you need granular per-resource configuration without organizational overhead.
  • AWS Firewall Manager — Multi-account environments requiring consistent firewall policies, automatic protection of new resources, and centralized compliance monitoring for network security.
  • AWS Control Tower Guardrails — Broad organizational governance including IAM restrictions, logging requirements, data residency controls, and account baseline configurations.
  • Firewall Manager + Control Tower (Together) — Best practice for enterprises: Control Tower manages account governance and baselines, while Firewall Manager enforces network security policies. They are complementary, not competing services.

AWS Firewall Manager Pricing

  • Protection Policy Fee: $100 per policy per Region per month (prorated hourly).
  • Shield Advanced customers: Firewall Manager policy fee is included at no additional charge (only pays for Config rules).
  • AWS Config Rules: Firewall Manager creates 2 Config rules per policy per account — charged at standard Config pricing ($0.003/CI change + $0.001/rule evaluation).
  • Underlying service charges: WAF Web ACLs/rules, Network Firewall endpoints, Shield Advanced, DNS Firewall queries, and third-party firewall charges apply separately.
  • No minimum fees or upfront commitments — pay only for what is used.
  • Note: Some Regions have per-policy prices greater than $100. Check the AWS pricing page for Region-specific pricing.

Pricing Example

  • 1 WAF policy, 7 accounts, no Shield Advanced:
    • Firewall Manager: $100/month
    • WAF (7 Web ACLs + 7 rules): $42/month
    • Config rules: ~$40/month
    • Total: ~$182/month
  • Same scenario WITH Shield Advanced:
    • Firewall Manager: $0 (included with Shield Advanced)
    • WAF: $0 (included with Shield Advanced)
    • Config rules: ~$40/month
    • Total: ~$40/month (plus Shield Advanced subscription of $3,000/month)

AWS Certification Exam Practice Questions

Questions are based on this topic for the AWS Certified Security – Specialty (SCS-C02) and AWS Certified Solutions Architect – Professional (SAP-C02) exams.

  1. A security team wants to enforce a standard set of AWS WAF rules across all accounts in an AWS Organization. The rules should be applied automatically to any new Application Load Balancer created in any account. Individual teams should be able to add their own additional WAF rules. What is the most operationally efficient approach?
    1. Create a WAF Web ACL in each account using AWS CloudFormation StackSets
    2. Use AWS Firewall Manager to create a WAF policy with first and last rule groups scoped to the entire organization
    3. Use AWS Control Tower to create a preventive guardrail that blocks ALBs without WAF
    4. Create a Lambda function triggered by CloudTrail to attach WAF rules to new ALBs
Show Answer

Answer: b – AWS Firewall Manager WAF policies support first and last rule groups that are centrally enforced while allowing account owners to add rules between them. It automatically applies to new resources including ALBs created in new accounts.

  1. A company uses AWS Organizations with 50 accounts across 3 Regions. The security architect needs to ensure all VPCs have AWS Network Firewall endpoints deployed with a standard inspection rule set. New VPCs should be protected automatically without manual intervention. What combination of services achieves this with the LEAST operational overhead?
    1. AWS CloudFormation StackSets with drift detection
    2. AWS Firewall Manager with a Network Firewall policy in distributed mode with auto-remediation enabled
    3. AWS Control Tower with a custom Config rule and Systems Manager remediation
    4. AWS Service Catalog with an approved Network Firewall product
Show Answer

Answer: b – Firewall Manager Network Firewall policies in distributed mode automatically deploy firewall endpoints to all in-scope VPCs. With auto-remediation enabled, new VPCs are protected immediately. This requires the least operational overhead compared to custom automation approaches.

  1. An organization wants to audit all security groups across 100 accounts to identify rules that allow unrestricted SSH access (0.0.0.0/0 on port 22). Non-compliant security groups should be flagged but NOT automatically modified. Findings should appear in AWS Security Hub. Which approach meets these requirements?
    1. Create a Firewall Manager security group audit policy with auto-remediation disabled
    2. Create a Firewall Manager common security group policy
    3. Deploy a Config managed rule restricted-ssh using StackSets
    4. Use AWS Control Tower detective guardrail for open SSH
Show Answer

Answer: a – Firewall Manager security group audit policies define guardrails for allowed/disallowed security group rules and detect overly permissive rules. With auto-remediation disabled, it reports non-compliance without making changes. Findings are automatically sent to Security Hub.

  1. What are the mandatory prerequisites for deploying AWS Firewall Manager policies across an organization? (Select TWO)
    1. AWS Control Tower must be configured
    2. AWS Organizations must be enabled with all features
    3. AWS Config must be enabled in all accounts and Regions where policies apply
    4. AWS CloudTrail must have an organization trail configured
    5. AWS Shield Advanced must be subscribed
Show Answer

Answer: b, c – AWS Organizations (all features enabled) and AWS Config are mandatory prerequisites for Firewall Manager. Control Tower and CloudTrail are not required. Shield Advanced is only required for Shield policies specifically.

  • A company uses AWS Firewall Manager to enforce WAF policies across 20 accounts in us-east-1 and eu-west-1. They are NOT Shield Advanced subscribers. What is the monthly Firewall Manager policy fee alone (excluding WAF and Config charges)?
    1. $100 (one policy applies to both Regions)
    2. $200 (one policy, charged per Region)
    3. $2,000 (one policy per account per Region)
    4. $4,000 (charged per account per Region)
    • Show Answer

    Answer: b – Firewall Manager charges $100 per policy per Region per month. With one WAF policy applied in 2 Regions, the Firewall Manager fee is $200/month. The fee is per policy per Region, regardless of the number of accounts in scope.

    AWS Firewall Manager Certification Tips

    • SCS-C02 (Security Specialty) — Firewall Manager is heavily tested. Focus on:
      • Centralized WAF management across accounts
      • Auto-remediation capabilities and when to use monitoring-only mode
      • Prerequisites (Organizations + Config)
      • Security group auditing for compliance
      • Integration with Security Hub for findings
      • Shield Advanced policy management
    • SAP-C02 (Solutions Architect Professional) — Focus on:
      • Multi-account security architecture with Organizations
      • When to use Firewall Manager vs individual service management
      • Firewall Manager + Control Tower as complementary services
      • Cost optimization (Shield Advanced includes FM at no charge)
      • Operational efficiency — FM as the answer for “least operational overhead” in multi-account scenarios
      • Network Firewall deployment models (distributed vs centralized)
    • Common Exam Patterns:
      • “Centrally manage security policies across all accounts” → Firewall Manager
      • “Automatically protect new resources” → Firewall Manager with auto-remediation
      • “Enforce WAF rules while allowing teams flexibility” → FM WAF policy with first/last rule groups
      • “Audit security groups across organization” → FM security group audit policy
      • “Deploy Network Firewall across multiple VPCs with least effort” → FM Network Firewall policy

    Frequently Asked Questions

    What is AWS Firewall Manager?

    Firewall Manager centrally configures and manages security policies (WAF, Shield Advanced, Security Groups, Network Firewall, DNS Firewall) across all accounts in your AWS Organization. It auto-remediates non-compliant resources.

    What are the prerequisites for Firewall Manager?

    You need AWS Organizations with all features enabled, AWS Config enabled in all accounts/Regions you want to protect, and a designated Firewall Manager administrator account.

    How much does Firewall Manager cost?

    Firewall Manager charges $100 per policy per Region per month, plus the underlying service charges (WAF rules, Network Firewall endpoints, etc.). Shield Advanced customers get Firewall Manager at no additional charge for WAF and Shield policies.

    References

    Verified Permissions – Fine-Grained Auth with Cedar

    ~ Last updated on : ~ Kiro Agent ~ Leave a comment

    Amazon Verified Permissions – Fine-Grained Authorization with Cedar

    Amazon Verified Permissions is a fully managed, scalable permissions management and fine-grained authorization service for custom applications. It uses the Cedar policy language — an open-source, expressive, and analyzable policy language — to define who can do what on which resources. Unlike AWS IAM (which controls access to AWS APIs), Verified Permissions is designed to be the externalized authorization engine for your own applications, enabling developers to decouple authorization logic from application code.

    📢 Key Updates (2024–2026):

    • April 2024: Cognito + API Gateway integration launched — secure APIs with fine-grained access control via Quick Start wizard
    • August 2024: Expanded OIDC identity provider support for API Gateway authorization
    • April 2026: Policy store aliases and named policies/policy templates support added
    • May 2026: Multiple namespaces support aligned with Cedar language
    • June 2025: Price reduction — single authorization requests reduced by up to 97% to $5 per million
    • 2025: avp-local-agent for local policy evaluation with zero network latency
    • 2025: ExpressJS integration for Node.js applications

    What is Amazon Verified Permissions?

    Amazon Verified Permissions serves as a Policy Decision Point (PDP) — a centralized service that evaluates authorization requests against Cedar policies and returns Allow or Deny decisions. Your application acts as the Policy Enforcement Point (PEP), calling Verified Permissions before allowing users to perform actions.

    Key Characteristics

    • Externalized authorization: Separates “who can do what” logic from application code, making policies auditable and manageable independently
    • Cedar policy language: Open-source (Apache 2.0), formally verified, human-readable policy language developed by AWS
    • Default deny: All actions are denied unless explicitly permitted — follows the principle of least privilege
    • Explicit deny wins: A single forbid policy always overrides any number of permit policies
    • Real-time evaluation: Sub-millisecond policy evaluation with single-digit millisecond API latency
    • Schema validation: Policies are validated against a schema to catch errors at authoring time
    • Supports RBAC and ABAC: Role-based and attribute-based access control models, or a combination of both
    • Identity provider agnostic: Works with Amazon Cognito, any OIDC provider, or custom identity solutions

    Cedar Policy Language

    Cedar is an open-source policy language designed for expressing authorization policies. It is human-readable, formally verified for correctness, and designed for fast evaluation. Cedar policies are built around four core concepts:

    Core Concepts

    Concept Description Example
    Principal The entity making the request (user, service, role) User::"alice", User::"a1b2c3d4-..."
    Action The operation being performed Action::"viewDocument", Action::"deleteOrder"
    Resource The target entity being acted upon Document::"doc-123", Photo::"vacation.jpg"
    Context Additional request-time attributes (IP, time, MFA status) context.ipAddress, context.authentication.usedMFA

    Policy Structure

    Every Cedar policy has:

    • Effect: Either permit (allow) or forbid (deny)
    • Scope: Specifies which principal, action, and resource the policy applies to (mandatory)
    • Conditions: Optional when (must be true) and unless (must be false) clauses
    • Annotations: Optional key-value metadata (e.g., @id, @advice)

    Cedar Policy Examples

    Example 1: Simple RBAC — Editors Can Edit Documents

    Example 2: ABAC — Owner-Based Access

    Example 3: Context-Based Restriction — MFA Required

    Example 4: Multi-Tenant SaaS — Tenant Isolation

    Example 5: Time-Based and IP Restriction

    Example 6: Forbid Policy — Block Suspended Users

    Policy Store Architecture

    A policy store is the top-level container in Verified Permissions that holds all policies, policy templates, and schema definitions. It is logically isolated from other policy stores.

    Key Characteristics

    • Logical isolation: Each policy store is independent — policies in one store cannot reference or affect another store
    • Application mapping: Typically one policy store per application, or one per tenant in multi-tenant architectures
    • Schema enforcement: Each policy store can have a schema that validates policies at creation time
    • Namespace support: As of May 2026, Verified Permissions supports multiple namespaces within a policy store (aligned with Cedar)
    • Policy store aliases: As of April 2026, you can assign human-readable aliases to policy stores for easier management
    • CloudFormation support: Policy stores can be provisioned as infrastructure-as-code

    Multi-Tenant Strategies

    • Shared policy store: All tenants share one policy store; tenant isolation enforced through when { principal.tenantId == resource.tenantId } conditions
    • Per-tenant policy store: Each tenant gets their own policy store — strongest isolation, but more management overhead
    • Hybrid: Shared store for common policies, per-tenant stores for custom permissions

    Schema Definition

    The schema defines the authorization model for your application — entity types, their attributes, valid actions, and which principals can perform which actions on which resources. It serves as a contract that validates policies.

    Schema Components

    • Entity types: Define principals (e.g., User, Group) and resources (e.g., Document, Folder) with their attributes
    • Actions: Define valid operations and which principal-resource combinations they apply to
    • Common types: Reusable type definitions shared across entity types
    • Hierarchy: Define parent-child relationships (e.g., a Document is in a Folder)

    Example Schema (JSON format)

    How Authorization Decisions Work

    When your application calls the IsAuthorized or IsAuthorizedWithToken API, Verified Permissions evaluates all relevant policies and returns an Allow or Deny decision.

    Evaluation Logic

    1. Collect relevant policies: Verified Permissions identifies all policies whose scope matches the request (principal, action, resource)
    2. Evaluate conditions: For each matching policy, evaluate when and unless conditions against the provided context and entity attributes
    3. Determine individual results:
      • A permit policy with matching scope and satisfied conditions → Allow
      • A forbid policy with matching scope and satisfied conditions → Deny
    4. Combine results:
      • If at least one Deny exists → Final decision is DENY (explicit deny always wins)
      • If at least one Allow and zero Denys → Final decision is ALLOW
      • If no matching policies → Final decision is DENY (implicit deny / default deny)

    Key Principles

    • Default deny: With an empty policy store (no policies), all requests are denied
    • Explicit deny overrides: A single matching forbid policy overrides any number of permit policies
    • No ordering dependency: Policy evaluation order does not matter — all policies are evaluated independently
    • Determining policies: The API response includes which policies contributed to the decision, enabling debugging and audit

    Authorization API Request Example

    Integration with Amazon Cognito

    Amazon Verified Permissions integrates natively with Amazon Cognito, enabling you to use Cognito tokens directly in authorization decisions without manual token parsing.

    How It Works

    • Identity source configuration: Connect a Cognito user pool as an identity source in your policy store
    • Token-based authorization: Use the IsAuthorizedWithToken API, passing the Cognito ID token or access token directly
    • Automatic attribute mapping: Verified Permissions extracts user attributes (groups, custom claims, email) from the token and makes them available in Cedar policies
    • Token validation: Verified Permissions validates token signature, expiration, and issuer automatically
    • Group membership: Cognito groups are mapped to Cedar group hierarchies for RBAC

    Policy Using Cognito Token Attributes

    Integration with API Gateway

    Amazon Verified Permissions can secure Amazon API Gateway REST APIs using a Lambda authorizer pattern, with a Quick Start wizard that automates the setup.

    Architecture Flow

    1. Client sends request to API Gateway with authentication token (Cognito JWT or OIDC token)
    2. API Gateway invokes the Lambda authorizer deployed by the Quick Start wizard
    3. Lambda authorizer extracts token claims, maps the API method and path to Cedar actions/resources
    4. Lambda authorizer calls Verified Permissions IsAuthorizedWithToken API
    5. Verified Permissions evaluates Cedar policies and returns Allow/Deny
    6. Lambda authorizer translates the response to API Gateway’s expected IAM policy format
    7. API Gateway allows or denies the request accordingly

    Key Features

    • Quick Start wizard: Creates the Lambda authorizer, policy store, and sample policies automatically
    • RBAC via groups: Control API access based on Cognito groups or OIDC claims
    • ABAC via attributes: Fine-grained control using user attributes, request parameters, and context
    • OIDC support: Works with any OpenID Connect-compatible identity provider (not just Cognito)
    • Caching: Lambda authorizer can cache authorization results to reduce latency and Verified Permissions API calls

    Policy Templates

    Policy templates are Cedar policies with placeholders for the principal, resource, or both. They enable you to create reusable permission patterns that can be instantiated for specific users and resources.

    How Templates Work

    • Define once: Create a template with ?principal and/or ?resource placeholders
    • Instantiate many: Create template-linked policies by filling in the placeholders with specific entity values
    • Centralized updates: Modify the template and all linked policies are updated automatically
    • Named templates: As of April 2026, templates can have human-readable names for easier management

    Template Example

    When you instantiate this template:

    • ?principal = User::"alice"
    • ?resource = Document::"project-plan-2025"

    This creates a policy that allows Alice to view, edit, and comment on the specific project plan document.

    Use Cases for Templates

    • Document sharing: Grant specific users access to specific documents (like Google Docs sharing)
    • Resource-specific roles: Assign users as “admin” or “viewer” on individual resources
    • Time-limited access: Templates with when { context.time < expiry } for temporary grants
    • Onboarding workflows: Automatically create policies when users are assigned to projects

    Batch Authorization

    The BatchIsAuthorized and BatchIsAuthorizedWithToken APIs allow you to evaluate multiple authorization decisions in a single API call, reducing latency and costs for UI rendering and bulk operations.

    Key Features

    • Up to 30 requests per batch: Each API call can contain up to 30 individual authorization requests
    • Shared principal or resource: Either the principal or the resource must be identical across all requests in a batch
    • Single metering: Each batch API call counts as one request for billing (regardless of the number of individual authorizations)
    • Individual results: Each authorization within the batch returns its own Allow/Deny decision

    Use Cases

    • UI permission rendering: Determine which buttons/actions to show a user across multiple resources (e.g., "Can this user edit, delete, share this document?")
    • Navigation menus: Check access to multiple pages/features in a single call
    • Bulk operations: Verify permissions before processing a batch of items
    • Dashboard rendering: Determine which widgets/data a user can see

    Local Authorization with avp-local-agent

    The avp-local-agent is an open-source Rust-based sidecar that caches policies locally and evaluates authorization decisions within your application, eliminating network round-trips to the Verified Permissions API.

    Key Benefits

    • Zero network latency: Decisions are made locally using the Cedar evaluation engine
    • No authorization API charges: Local evaluations are free — you only pay for policy management (cache refresh) calls
    • High throughput: Ideal for latency-sensitive, high-frequency authorization (e.g., financial trading systems)
    • Configurable cache refresh: Control how often the agent syncs policies from the Verified Permissions service
    • Consistent evaluation: Uses the same Cedar engine as the cloud service, ensuring identical results

    Audit Logging

    Amazon Verified Permissions integrates with AWS CloudTrail for comprehensive audit logging of all API activity.

    What Is Logged

    • Management events: Policy store creation/deletion, schema updates, policy creation/modification — logged by default in CloudTrail
    • Data events: Authorization requests (IsAuthorized, BatchIsAuthorized) — can be enabled for detailed authorization auditing
    • Determining policies: Each authorization response includes the policy IDs that led to the decision
    • Request context: Full details of who requested what, when, and the decision made

    Audit Capabilities

    • Policy querying: APIs to query which policies apply to specific principals or resources
    • Compliance reporting: Answer "who has access to what?" and "why was this access granted?" questions
    • Security investigation: Trace specific authorization decisions back to the policies that permitted them
    • Policy impact analysis: Understand which users/resources would be affected by a policy change before deploying it

    Comparison: Verified Permissions vs IAM Policies vs Cognito Groups vs Custom Authorization

    Feature Verified Permissions IAM Policies Cognito Groups Custom Auth Code
    Purpose Application-level authorization AWS API access control Coarse-grained user grouping Application-level authorization
    Granularity Fine-grained (RBAC + ABAC) Fine-grained for AWS resources Coarse (group membership only) Custom (depends on implementation)
    Policy Language Cedar (human-readable, formally verified) JSON-based IAM policy language None (group assignment only) Code (if/else, switch statements)
    Scope Your application's resources AWS services and resources only Token-based role hints Your application's resources
    Externalized Yes — policies managed separately from code Yes — managed via AWS console/CLI Partially (groups are external) No — embedded in application code
    Auditability High — policies are declarative, queryable High — IAM Access Analyzer Limited (group membership only) Low — requires code review
    Multi-Tenant Built-in (per-tenant policy stores) Not designed for app tenancy Not designed for multi-tenancy Must build from scratch
    Schema Validation Yes — catches policy errors at authoring time Yes — policy validation No No (unless you build it)
    Scalability Fully managed, auto-scaling Fully managed by AWS Fully managed by Cognito Scales with your application
    Performance Sub-ms evaluation; local agent option Evaluated per AWS API call Token parsed locally (fast) Depends on implementation
    Best For Application permissions at scale Controlling AWS resource access Simple role assignment Simple apps or prototypes

    Use Cases

    Multi-Tenant SaaS Applications

    • Enforce tenant data isolation using Cedar policies with tenant context
    • Per-tenant policy stores for strong isolation or shared stores with tenant-scoped policies
    • Tenant administrators can manage their own permissions without affecting other tenants
    • Example: A project management SaaS where each company (tenant) has its own roles, projects, and access rules

    Role-Based Access Control (RBAC)

    • Model roles as Cedar groups (e.g., Group::"admin", Group::"editor", Group::"viewer")
    • Assign users to groups and write policies that permit actions for group members
    • Use action groups to bundle related permissions (e.g., "editor" role gets view + edit + comment)
    • Policy templates for role-resource assignments

    Attribute-Based Access Control (ABAC)

    • Make authorization decisions based on attributes of principals, resources, and context
    • Examples: department matching, job level thresholds, classification levels, time-of-day restrictions
    • Combine with RBAC for layered security: "editors can edit, BUT only documents in their department"

    Document-Level Access Control

    • Model document sharing like Google Docs — individual users can be granted specific access to specific documents
    • Use policy templates: instantiate per user-document pair with specific permissions (view, edit, comment)
    • Hierarchical resources: grant access to a folder, and all documents within it inherit that access
    • Owner-based access: document creators automatically get full control

    Healthcare and Compliance

    • PHI/PII access controls with detailed audit trails for HIPAA compliance
    • Attribute-based filtering of sensitive data fields
    • Break-glass emergency access with logging

    Financial Services

    • Fine-grained API authorization for payment processing and trade execution
    • Segregation of duties enforcement
    • Transaction-level authorization with amount thresholds

    Pricing

    Amazon Verified Permissions follows a pay-per-use model with no upfront or minimum fees. Pricing is the same across all AWS Regions.

    💰 June 2025 Price Reduction: Single authorization request pricing was reduced by up to 97%, from previous pricing to $5 per million requests.
    Usage Type Price Notes
    Single Authorization (IsAuthorized, IsAuthorizedWithToken) $0.000005 per request ($5/million) Per API call
    Batch Authorization (first 40M/month) $0.00015 per request ($150/million) Per batch call (up to 30 authz each)
    Batch Authorization (next 60M/month) $0.000075 per request Volume discount tier
    Batch Authorization (100M+/month) $0.00004 per request Highest volume discount
    Policy Management (CRUD operations) $0.00004 per request Create, Update, Get, List policies
    Local Agent Evaluation $0 (free) Pay only for policy management (cache sync)

    Pricing Example

    A SaaS application with 250 vendors making 250,000 API calls/day × 20 working days = 5 million single authorization requests/month = 5M × $0.000005 = $25/month.

    AWS Certification Relevance

    🎓 Exam Relevance:

    • AWS Certified Developer – Associate (DVA-C02): Domain 3 — "Implement authentication and/or authorization for applications and AWS services." Understand how to externalize authorization using Verified Permissions with Cognito, API Gateway Lambda authorizers, and Cedar policies for application-level access control.
    • AWS Certified Security – Specialty (SCS-C02): Domain 2 — "Security Logging and Monitoring" and Domain 3 — "Infrastructure Security." Understand fine-grained authorization patterns, policy evaluation logic (default deny, explicit deny overrides), integration with identity providers, audit logging via CloudTrail, and when to use Verified Permissions vs IAM vs Cognito groups.

    Key Exam Concepts

    • Verified Permissions is for application-level authorization (not AWS resource access — that's IAM)
    • Cedar uses default deny — explicit permit required; explicit forbid always wins
    • Policy stores provide logical isolation between applications or tenants
    • Integration with Cognito + API Gateway via Lambda authorizer pattern
    • Supports both RBAC (groups/roles) and ABAC (attribute conditions) models
    • BatchIsAuthorized for multiple decisions in a single call (up to 30 requests)
    • Schema validates policies at authoring time (not runtime)
    • Policy templates for reusable permission patterns with placeholders

    Practice Questions

    Question 1

    A SaaS company needs to implement fine-grained access control for their multi-tenant document management application. Each tenant's users should only access documents within their own tenant, and document owners should have full control while team members get read-only access. The solution must be auditable and support real-time policy changes without code redeployment. Which approach best meets these requirements?

    1. Use IAM policies with condition keys to restrict access based on tenant tags
    2. Implement authorization logic in application code using if/else statements with Cognito group membership
    3. Use Amazon Verified Permissions with Cedar policies that evaluate tenant attributes and resource ownership
    4. Create separate Cognito user pools per tenant with custom Lambda triggers for authorization
    Show Answer

    Answer: C –

    Explanation: Amazon Verified Permissions with Cedar policies is designed for application-level fine-grained authorization. Cedar supports RBAC (owner/team member) and ABAC (tenant isolation via attribute matching), policies are externalized from code (real-time updates without redeployment), and all authorization decisions are auditable via CloudTrail. IAM (A) is for AWS resource access, not application authorization. Embedding auth in code (B) is not auditable and requires redeployment for changes. Separate Cognito pools per tenant (D) adds complexity without solving fine-grained document-level access.

    Question 2

    A developer is building a Cedar policy in Amazon Verified Permissions. The policy store has: a permit policy allowing users in the "editors" group to edit documents, AND a forbid policy denying all actions when principal.status == "suspended". A user who is in the "editors" group AND has status "suspended" requests to edit a document. What is the authorization decision?

    1. ALLOW — the permit policy matches and the user is in the editors group
    2. DENY — the forbid policy takes precedence because explicit deny always overrides permit
    3. ALLOW — permit policies are evaluated before forbid policies
    4. Error — conflicting policies cannot exist in the same policy store
    Show Answer

    Answer: B –

    Explanation: In Cedar's policy evaluation logic, an explicit deny (forbid policy) always overrides any number of permit policies. Both policies match the request — the permit matches because the user is in "editors", and the forbid matches because the user's status is "suspended". Since at least one forbid policy matches, the final decision is DENY. Policy evaluation order does not matter (C is wrong), and conflicting policies are perfectly valid (D is wrong).

    Question 3

    A company's application renders a dashboard where different UI elements (buttons, menus, data widgets) should be shown or hidden based on the user's permissions. The application needs to check 15 different permissions for the current user at page load time. What is the most cost-effective approach using Amazon Verified Permissions?

    1. Call the IsAuthorized API 15 times — once for each permission check
    2. Use the BatchIsAuthorized API to evaluate all 15 authorization requests in a single call
    3. Cache all policies locally and evaluate permissions in the browser using JavaScript
    4. Use Cognito groups to determine all permissions without calling Verified Permissions
    Show Answer

    Answer: B –

    Explanation: BatchIsAuthorized can evaluate up to 30 authorization requests in a single API call, and is metered as one request for billing. This is both faster (single round-trip) and more cost-effective than 15 individual calls. Individual calls (A) work but cost 15× more. Client-side evaluation (C) exposes policies to the browser — a security risk. Cognito groups (D) only support coarse-grained RBAC, not fine-grained attribute-based decisions.

    Question 4

    An organization wants to secure their REST APIs in Amazon API Gateway using Amazon Verified Permissions for fine-grained access control based on user attributes from Amazon Cognito. What is the correct architecture to achieve this?

    1. Configure API Gateway to call Verified Permissions directly as a native authorizer
    2. Use a Cognito authorizer on API Gateway and pass the authorization decision to Verified Permissions
    3. Deploy a Lambda authorizer that extracts token claims, calls Verified Permissions IsAuthorizedWithToken API, and returns an IAM policy to API Gateway
    4. Configure Verified Permissions as an identity source in API Gateway's resource policy
    Show Answer

    Answer: C –

    Explanation: The correct pattern uses a Lambda authorizer as the bridge between API Gateway and Verified Permissions. The Lambda function extracts claims from the Cognito token, calls the IsAuthorizedWithToken API, and translates the response into API Gateway's expected IAM policy format (Allow/Deny). API Gateway does not have native Verified Permissions integration (A, D are wrong). A Cognito authorizer (B) only validates tokens — it doesn't call Verified Permissions for fine-grained decisions.

    Question 5

    A financial services company needs to authorize 200 million trade decisions per month with the lowest possible latency. Policies change infrequently (updated a few times daily). Which Amazon Verified Permissions deployment pattern minimizes latency while ensuring policies stay current?

    1. Use the standard IsAuthorized API for each trade with caching enabled
    2. Deploy the avp-local-agent sidecar configured to refresh policies every few minutes, evaluating all decisions locally
    3. Use BatchIsAuthorized with 30 trade decisions per batch to reduce API calls
    4. Implement custom Cedar evaluation in the application code without using Verified Permissions
    Show Answer

    Answer: B –

    Explanation: The avp-local-agent evaluates Cedar policies locally with zero network latency, which is critical for high-frequency trading. Since local evaluations are free ($0), the cost is only for policy management API calls to refresh the cache. With policies changing infrequently, a refresh interval of a few minutes ensures policies stay current. The standard API (A) adds network latency to each decision. BatchIsAuthorized (C) reduces calls but still has network latency. Custom implementation (D) loses the managed service benefits and requires maintaining the Cedar engine yourself.

    Frequently Asked Questions

    What is Amazon Verified Permissions?

    Verified Permissions is a managed authorization service that uses the Cedar policy language to make fine-grained access decisions. It centralizes authorization logic outside your application code, supporting RBAC, ABAC, and relationship-based access control.

    What is Cedar policy language?

    Cedar is an open-source authorization policy language created by AWS. It uses a simple permit/forbid syntax with principals, actions, resources, and conditions. It's designed to be analyzable, auditable, and performant for real-time authorization decisions.

    How does Verified Permissions differ from IAM?

    IAM controls access to AWS resources (who can call AWS APIs). Verified Permissions controls access within your application (which users can see/edit which data). Use IAM for infrastructure; Verified Permissions for application-level authorization.

    References

    AWS Verified Access – Zero Trust Application Access

    ~ Last updated on : ~ Kiro Agent ~ Leave a comment

    AWS Verified Access – Zero Trust Application Access

    AWS Verified Access provides secure access to corporate applications and resources without requiring a virtual private network (VPN). It implements Zero Trust security principles by evaluating each access request in real time against fine-grained policies based on user identity and device security posture, ensuring that only authenticated and authorized users on compliant devices can reach your applications.

    📢 Key Updates (2024–2025):

    • December 2024: Non-HTTP(S) protocol support (SSH, RDP, TCP) launched in preview
    • February 2025: Non-HTTP(S) support became generally available
    • March 2025: Achieved FedRAMP High and Moderate authorization
    • 2025: RDS endpoint type added for direct database access
    • 2025: Network CIDR endpoint type for IP-range-based access
    • 2025: AWS Connectivity Client for non-HTTP resources
    AWS Verified Access — Zero Trust Flow
    User
    (Browser/Device)
    →
    Verified Access
    1. Check Identity (Okta/IdC)
    2. Check Device (CrowdStrike)
    3. Evaluate Cedar Policy
    → Allow/Deny →
    Application
    (ALB / NI / RDS)
    ❌ No VPN needed • Per-request evaluation • Never trust, always verify

    Zero Trust Principles

    AWS Verified Access is built on the “never trust, always verify” model. Traditional perimeter-based security grants broad network access once a user connects via VPN. Zero Trust eliminates implicit trust by:

    • Verifying every request: Each application access request is evaluated independently — no persistent trust based on network location
    • Least-privilege access: Users get access only to specific applications they need, not the entire network
    • Continuous validation: Identity and device posture are checked on every request, not just at initial connection
    • Assume breach: The architecture limits lateral movement — compromising one application doesn’t grant access to others
    • Context-aware decisions: Access decisions combine multiple signals: user identity, group membership, device health, and security posture

    Architecture Components

    AWS Verified Access consists of four core components that work together to enforce zero trust access:

    Verified Access Instance

    • The top-level container that evaluates access requests and enforces policies
    • Each instance is associated with one or more trust providers
    • Supports AWS WAF integration for additional web security (SQL injection, XSS protection)
    • Logging is configured at the instance level (S3, CloudWatch Logs, Kinesis Data Firehose)
    • Can be shared across AWS accounts using AWS Resource Access Manager (RAM)

    Verified Access Trust Providers

    • External services that supply user identity and device security posture data
    • Two categories: Identity trust providers (who the user is) and Device trust providers (device health status)
    • Each Verified Access instance can have one identity provider and multiple device trust providers
    • Trust data is passed to Cedar policies for access evaluation

    Verified Access Groups

    • Logical groupings of endpoints with similar security requirements
    • Group-level access policies apply to all endpoints in the group
    • Simplifies policy management — define once, apply to many applications
    • Each group is associated with a Verified Access instance

    Verified Access Endpoints

    • Represent individual applications or resources that users access
    • Each endpoint belongs to a Verified Access group and inherits its policy
    • Optional endpoint-level policy for additional application-specific controls
    • Four endpoint types:
      • Load Balancer: Routes requests to ALB or NLB for application distribution
      • Network Interface: Sends requests to a specific ENI with protocol and port
      • Network CIDR: Routes requests to a specified IP address range
      • Amazon RDS: Provides access to RDS instances, clusters, or DB proxies

    How AWS Verified Access Works

    AWS Verified Access evaluates every access request using a combination of user identity verification and device posture assessment, eliminating the need for a VPN:

    1. User requests access to a corporate application via its Verified Access endpoint URL (e.g., app.example.com)
    2. Authentication: The user is redirected to the configured identity provider (IAM Identity Center or OIDC-compatible IdP) for authentication
    3. Device posture check: The device trust provider assesses the device’s security state (OS patch level, firewall status, disk encryption, malware protection)
    4. Policy evaluation: Verified Access evaluates Cedar policies using the identity and device trust data against group-level and endpoint-level policies
    5. Access decision: If both policies return Allow, the request is forwarded to the application; otherwise, access is denied
    6. Logging: Every access attempt (allowed or denied) is logged for audit and security analysis

    For non-HTTP(S) applications (SSH, RDP, TCP), users install the AWS Verified Access Connectivity Client on their devices. The client encrypts traffic, attaches user identity and device context, and routes it to Verified Access for policy enforcement before forwarding to the target resource.

    Trust Providers

    Identity Trust Providers

    Identity trust providers authenticate users and supply identity claims (email, groups, roles) to Cedar policies:

    Provider Type Details
    AWS IAM Identity Center Native Direct integration; supports SAML 2.0 federation with external IdPs; provides user/group attributes
    Okta OIDC OpenID Connect integration; supplies user identity, group membership, and custom claims
    Ping Identity OIDC OpenID Connect integration; enterprise identity verification and SSO
    Any OIDC Provider OIDC Any standards-compliant OIDC identity provider (Azure AD, Google Workspace, Auth0, etc.)

    Device Trust Providers

    Device trust providers assess the security posture of the user’s device and provide device health signals:

    Provider Supported Platforms Trust Signals
    CrowdStrike Windows 10, Windows 11 Zero Trust Assessment (ZTA) score, OS version, sensor status, policy compliance
    Jamf macOS Device compliance, risk score, OS patch level, FileVault encryption, firewall status
    JumpCloud Windows, macOS Device compliance status, disk encryption, OS version, screen lock, firewall
    💡 Important: You can configure one identity trust provider and multiple device trust providers per Verified Access instance. Verified Access currently supports Google Chrome and Mozilla Firefox browsers for device trust context collection.

    Cedar Policy Language

    Access policies in AWS Verified Access are written in Cedar, an open-source policy language developed by AWS. Cedar provides:

    • Human-readable syntax: Policies resemble natural language — easy to write and audit
    • Provably correct evaluation: Uses automated reasoning to ensure deterministic results
    • RBAC and ABAC support: Role-based and attribute-based access control in a single policy
    • Principal/Action/Resource model: Defines who can do what on which resource under which conditions

    Example Cedar Policy — Allow engineering team on compliant devices:

    Example Cedar Policy — Deny access from non-compliant devices:

    Integration with Application Load Balancer (ALB)

    AWS Verified Access integrates with Application Load Balancers as a primary endpoint type for HTTP(S) applications:

    • Load Balancer endpoint type: Verified Access forwards authenticated and authorized requests to an internal ALB or NLB
    • No public exposure needed: The ALB remains in a private subnet — only Verified Access endpoints are internet-facing
    • Health checks maintained: ALB continues to perform health checks on target applications
    • WAF at both layers: AWS WAF can be attached to both the Verified Access instance and the ALB for defense-in-depth
    • Signed identity headers: Verified Access injects signed user identity information into HTTP headers forwarded to the ALB, allowing applications to identify the authenticated user without separate authentication logic
    • On-premises applications: By pointing a Verified Access endpoint at an NLB with IP targets, you can provide zero trust access to on-premises applications connected via Direct Connect or VPN

    Architecture Pattern: Verified Access + ALB

    AWS WAF Integration

    • Associate an AWS WAF Web ACL with a Verified Access instance for additional protection
    • Provides protection against common exploits: SQL injection, XSS, known bad IPs
    • With IAM Identity Center: WAF inspects traffic before user authentication
    • With OIDC providers: WAF inspects traffic after user authentication
    • Rate limiting and geo-blocking rules apply at the Verified Access level

    Use Cases

    1. Replacing Traditional VPN

    • Eliminate VPN infrastructure management, licensing costs, and scalability issues
    • Remove broad network access — users access only the applications they need
    • Reduce VPN-related support tickets (connectivity issues, split tunneling, performance)
    • No client software needed for HTTP(S) applications (browser-only access)
    • Gradual migration: run Verified Access alongside Client VPN during transition

    2. BYOD (Bring Your Own Device) Access

    • Enable personal device access to corporate applications without VPN tunnel to corporate network
    • Device trust providers verify minimum security posture (encryption, patches, antivirus)
    • Conditional access: allow browser-based apps from BYOD but restrict sensitive resources to managed devices
    • No corporate certificates or VPN profiles needed on personal devices

    3. Contractor and Third-Party Access

    • Grant time-limited, application-specific access to external contractors
    • Federate contractor identities through OIDC without creating AWS or corporate accounts
    • Apply stricter device posture requirements or limit to specific applications
    • Easy revocation: update group policy or remove contractor from IdP group

    4. Multi-Account Application Access

    • Share Verified Access instances across accounts using AWS Resource Access Manager
    • Centralize access policies while applications remain in separate AWS accounts
    • Consistent security posture across organizational units

    5. Securing Non-HTTP Resources

    • Provide zero trust access to SSH sessions, RDP desktops, and TCP-based applications
    • Uses AWS Verified Access Connectivity Client on user devices
    • Supports access to RDS databases without exposing them publicly
    • Apply same identity and device trust policies to infrastructure access

    AWS Verified Access vs Client VPN vs Direct Connect vs PrivateLink

    Feature Verified Access AWS Client VPN AWS Direct Connect AWS PrivateLink
    Primary Purpose Zero trust application access without VPN Remote user VPN connectivity to VPC Dedicated private network connection from on-premises Private connectivity between VPCs and services
    Access Model Per-application, per-request Network-level (full VPC access via tunnel) Network-level (Layer 2/3) Service-specific (endpoint to service)
    Client Required No (browser for HTTP); Yes (Connectivity Client for non-HTTP) Yes (OpenVPN-compatible client) No (hardware router at on-premises) No
    Identity Verification Every request (IdP + device posture) At connection time (certificate + optional MFA) None (network-level only) None (relies on VPC security)
    Device Posture Yes (CrowdStrike, Jamf, JumpCloud) No No No
    Zero Trust Yes — core design principle No — perimeter-based once connected No — dedicated circuit Partial — limits service exposure
    Lateral Movement Risk Minimal (app-level isolation) High (VPC network access) Medium (depends on routing) Low (service-specific)
    Protocol Support HTTP(S), SSH, RDP, TCP All TCP/UDP (tunnel) All protocols (Layer 2/3) TCP (NLB-based)
    Scalability Fully managed, auto-scales Scales with VPN endpoints Fixed bandwidth (1/10/100 Gbps) Scales automatically
    Best For Remote workforce, BYOD, contractors, zero trust Full network access for remote employees Hybrid cloud, high-bandwidth on-premises connectivity Service-to-service private connectivity, SaaS delivery

    Pricing

    AWS Verified Access uses a pay-as-you-go model with no upfront commitment or minimum fees:

    HTTP(S) Applications

    Dimension Rate (US East – Ohio)
    Application hours (first 200 apps × 744 hrs) $0.27 per app-hour
    Application hours (above 148,800 app-hours/month) $0.20 per app-hour
    Data processed $0.02 per GB

    Non-HTTP(S) Applications

    Dimension Rate (US East – Ohio)
    Non-HTTP endpoint hours $0.20 per endpoint-hour
    Connections (above 100 free per endpoint/hour) $0.001 per connection-hour
    💰 Cost Example: 10 HTTP(S) applications running 24/7 for a month with 5 GB total data processed: (10 × 744 × $0.27) + (5 × $0.02) = $2,008.90/month. Additional standard AWS data transfer charges apply.

    Logging and Observability

    AWS Verified Access logs every access attempt (both allowed and denied), providing centralized visibility for security audits and incident response:

    Log Destinations

    • Amazon S3: Long-term archival, Athena queries, and compliance retention
    • Amazon CloudWatch Logs: Real-time monitoring, alarms, and dashboards
    • Amazon Kinesis Data Firehose: Stream to SIEM tools, Splunk, Datadog, or OpenSearch

    Log Contents

    • Timestamp and request ID
    • Source IP address and port
    • Verified Access instance, group, and endpoint IDs
    • Access decision (Allow or Deny)
    • User identity information (from trust provider)
    • Device trust data (optionally included)
    • HTTP method, URI, status code (for HTTP requests)
    • Policy evaluation details
    💡 Tip: Enable trust data inclusion in logs to capture the full identity and device context for each request. This aids forensic investigation but increases log volume and storage costs.

    AWS Certification Exam Relevance

    Exam Relevance Key Topics
    AWS Security Specialty (SCS-C02) ⭐⭐⭐ High Zero trust architecture, identity-based access, device posture, policy evaluation, WAF integration, logging for compliance
    Solutions Architect Professional (SAP-C02) ⭐⭐⭐ High VPN replacement patterns, hybrid access architecture, multi-account access, choosing between connectivity options
    Solutions Architect Associate (SAA-C03) ⭐⭐ Medium Understanding when to use Verified Access vs VPN vs PrivateLink; basic zero trust concepts
    Advanced Networking Specialty (ANS-C01) ⭐⭐⭐ High Endpoint types, ALB/NLB integration, DNS configuration, non-HTTP protocol support, Network Firewall integration

    AWS Verified Access Practice Questions

    1. A company wants to provide secure access to internal web applications for remote employees without deploying VPN infrastructure. They require per-request identity verification and device compliance checks. Which AWS service should they use?

      1. AWS Client VPN with MFA
      2. AWS PrivateLink with VPC endpoints
      3. AWS Verified Access
      4. Amazon CloudFront with signed URLs
      Show Answer

      Answer: C –

      Explanation: AWS Verified Access provides secure application access without VPN by evaluating each request against identity and device posture policies. Client VPN provides network-level access, not per-application zero trust. PrivateLink is for service-to-service connectivity within AWS. CloudFront signed URLs don’t provide identity/device verification.

    2. An organization is configuring AWS Verified Access and needs to enforce that users can only access applications from devices with disk encryption enabled and an up-to-date OS. Which combination of trust providers should they configure? (Choose TWO)

      1. AWS IAM Identity Center as an identity trust provider
      2. CrowdStrike as a device trust provider
      3. Amazon Cognito as an identity trust provider
      4. AWS Config as a device trust provider
      5. Amazon Inspector as a device posture provider
      Show Answer

      Answer: A, B

      Explanation: Verified Access requires an identity trust provider (IAM Identity Center or OIDC) and a device trust provider (CrowdStrike, Jamf, or JumpCloud). CrowdStrike provides device posture signals including disk encryption and OS version. Amazon Cognito, AWS Config, and Inspector are not supported as Verified Access trust providers.

    3. A security engineer is writing a Cedar policy for AWS Verified Access that should allow access only to users in the “finance” group who have a CrowdStrike ZTA assessment of “pass”. Which policy correctly implements this requirement?

      1. allow(principal in Group::"finance", action, resource) when { context.device.crowdstrike.overall_assessment == "pass" };
      2. permit(principal, action, resource) when { context.identity.groups.contains("finance") && context.device.crowdstrike.overall_assessment == "pass" };
      3. grant(principal, action, resource) when { identity.group == "finance" AND device.assessment == "pass" };
      4. permit(principal, action, resource) when { context.identity.email.endsWith("@finance.com") };
      Show Answer

      Answer: B –

      Explanation: Cedar policies use permit or forbid keywords (not “allow” or “grant”). The trust data is accessed via the context object, with identity data under context.identity and device data under context.device.[provider]. Option B correctly checks both group membership and device assessment.

    4. A company currently uses AWS Client VPN but wants to migrate to AWS Verified Access for their web applications. During the transition, they need to maintain access for applications that use SSH and RDP. What should the solutions architect recommend?

      1. Use Verified Access for all applications immediately — it supports all protocols
      2. Use Verified Access for HTTP(S) applications and deploy the AWS Verified Access Connectivity Client for SSH/RDP access to non-HTTP endpoints
      3. Continue using Client VPN for SSH/RDP; Verified Access only supports HTTP(S)
      4. Use AWS Systems Manager Session Manager for SSH/RDP and Verified Access for HTTP(S) only
      Show Answer

      Answer: B –

      Explanation: Since February 2025, AWS Verified Access supports non-HTTP(S) protocols (SSH, RDP, TCP) through the AWS Verified Access Connectivity Client. Users install the client on their devices to access non-HTTP resources with the same zero trust policy enforcement. This eliminates the need for Client VPN for these protocols.

    5. An organization needs to log all Verified Access requests for compliance auditing, including the identity claims and device posture data used in each access decision. Where can they send these logs? (Choose THREE)

      1. Amazon S3
      2. Amazon CloudWatch Logs
      3. Amazon Kinesis Data Firehose
      4. AWS CloudTrail
      5. Amazon DynamoDB
      6. Amazon SQS
      Show Answer

      Answer: A, B, C

      Explanation: AWS Verified Access supports three log destinations: Amazon S3, CloudWatch Logs, and Kinesis Data Firehose. Trust data (identity and device context) can optionally be included in these logs. CloudTrail records API calls for Verified Access management operations but does not capture per-request access logs. DynamoDB and SQS are not supported log destinations.

    Frequently Asked Questions

    What is AWS Verified Access?

    AWS Verified Access provides secure access to corporate applications without a VPN. It evaluates each request against identity and device posture policies using Cedar policy language, following zero trust principles of ‘never trust, always verify’.

    How does Verified Access replace VPN?

    Instead of granting broad network access via VPN, Verified Access grants per-application access based on user identity and device security posture. Users connect directly to applications through their browser without installing VPN clients.

    What trust providers does Verified Access support?

    For identity: IAM Identity Center, Okta, Ping Identity, and any OIDC provider. For device posture: CrowdStrike, Jamf, and JumpCloud. You can combine identity + device trust for stronger security.

    Related Posts

    References

    AWS Security Lake – Centralized Security Data Lake

    ~ Last updated on : ~ Kiro Agent ~ Leave a comment

    AWS Security Lake – Centralized Security Data Lake

    • AWS Security Lake is a fully managed security data lake service that automatically centralizes security data from AWS environments, SaaS providers, on-premises, and cloud sources into a purpose-built data lake stored in your AWS account.
    • Security Lake normalizes and consolidates security data into the Open Cybersecurity Schema Framework (OCSF) format, enabling faster threat detection, investigation, and response.
    • The data lake is backed by Amazon S3 buckets, and you retain full ownership and control over your data.
    • Security Lake uses Apache Iceberg open table format and Apache Parquet columnar storage for optimized query performance and cost-efficient storage.
    • It integrates with AWS Organizations for multi-account management and supports cross-Region data aggregation through rollup Regions.
    • Security Lake provides a subscriber model to grant third-party SIEM tools, analytics platforms, and custom applications access to the centralized security data.
    • The service is highly relevant for the AWS Certified Security – Specialty (SCS-C02) exam, particularly in the domains of Security Logging and Monitoring, and Threat Detection and Incident Response.

    Security Lake Architecture

    • Security Lake creates a purpose-built security data lake in your account using Amazon S3 as the storage layer.
    • Key architectural components include:
      • Data Collection Layer – Automatically collects log and event data from natively supported AWS services and allows ingestion of custom/third-party sources.
      • Data Normalization Layer – Converts all ingested data into OCSF format and Apache Parquet columnar format for consistency.
      • Storage Layer – Data stored in S3 buckets using Apache Iceberg table format, registered in AWS Glue Data Catalog.
      • Access Control Layer – AWS Lake Formation provides fine-grained access control to the data lake tables.
      • Subscriber Layer – Managed access for SIEM tools, analytics platforms, and custom consumers.

    Open Cybersecurity Schema Framework (OCSF)

    • OCSF is a collaborative, open-source schema framework developed by AWS and leading cybersecurity partners (including Splunk, IBM, and others).
    • It provides a vendor-agnostic taxonomy for security events, eliminating the need for custom parsers for each data source.
    • OCSF defines standardized event classes such as:
      • Network Activity (VPC Flow Logs, DNS queries)
      • API Activity (CloudTrail events)
      • Security Findings (GuardDuty, Security Hub)
      • Authentication events
      • File Activity and Process Activity
    • By normalizing to OCSF, Security Lake enables correlation across disparate sources without custom ETL pipelines.
    • Third-party sources must be converted to OCSF format before ingestion (no charge for third-party data ingestion).

    Apache Iceberg Tables

    • Security Lake stores data in Apache Iceberg open table format on top of Amazon S3.
    • Iceberg provides:
      • ACID transactions – Ensures data consistency during concurrent writes.
      • Schema evolution – Supports adding/removing columns without rewriting data.
      • Partition evolution – Optimizes query patterns without data migration.
      • Time travel – Query historical snapshots of data.
      • Hidden partitioning – Automatic partition pruning for faster queries.
    • Tables are registered in AWS Glue Data Catalog, enabling query access via Amazon Athena, Amazon Redshift Spectrum, and Amazon OpenSearch Service.
    • The combination of Parquet format + Iceberg tables provides storage-efficient and query-optimized access to security data.

    Data Lifecycle Management

    • Security Lake provides customizable retention settings to manage data lifecycle.
    • Supports automated storage tiering to transition data to cost-effective storage classes (S3 Standard → S3 Standard-IA → S3 Glacier).
    • Data is automatically partitioned by source, Region, account, and time for efficient querying.
    • Retention policies can be configured per source and per Region.

    Security Lake Data Sources

    • Security Lake supports natively integrated AWS sources and custom/third-party sources.
    • AWS sources are automatically normalized to OCSF format and converted to Apache Parquet.

    Natively Supported AWS Sources

    Source Data Type OCSF Event Class
    AWS CloudTrail (Management Events) API calls, console sign-ins API Activity
    AWS CloudTrail (S3 Data Events) S3 object-level operations API Activity
    AWS CloudTrail (Lambda Data Events) Lambda invocation activity API Activity
    Amazon VPC Flow Logs Network traffic metadata Network Activity
    Amazon Route 53 Resolver DNS query logs DNS Activity
    Amazon S3 Data Events Object access activity API Activity
    AWS Lambda Execution activity API Activity
    Amazon EKS Audit Logs Kubernetes API server audit logs API Activity
    AWS WAF Web request logs HTTP Activity
    AWS Security Hub Aggregated security findings Security Finding

    Security Hub Integrated Findings Sources

    • Security Lake ingests findings from Security Hub, which aggregates from:
      • Amazon GuardDuty – Threat detection findings (malicious IPs, compromised instances, anomalous behavior)
      • Amazon Inspector – Vulnerability assessment findings
      • Amazon Macie – Sensitive data discovery findings
      • AWS Config – Configuration compliance findings
      • AWS Firewall Manager – Firewall policy compliance findings
      • IAM Access Analyzer – External access findings
      • AWS Health – Service health events
      • AWS Systems Manager Patch Manager – Patch compliance findings

    Custom and Third-Party Sources

    • Security Lake allows ingestion of custom sources from on-premises, other cloud providers, or SaaS applications.
    • Custom sources must convert data to OCSF format before ingestion.
    • There is no Security Lake charge for ingesting third-party or custom data (standard S3 storage charges apply).
    • AWS AppFabric automatically normalizes SaaS application audit logs (Microsoft 365, Google Workspace, Salesforce, etc.) into OCSF and delivers to Security Lake.
    • Custom sources can deliver data via:
      • Direct S3 writes to the Security Lake bucket
      • AWS Glue ETL pipelines for format conversion
      • Partner integrations (CrowdStrike, Palo Alto Networks, etc.)

    Default vs. Optional Sources

    • When enabling Security Lake, the default sources include: CloudTrail management events, VPC Flow Logs, Route 53 DNS logs, and Security Hub findings.
    • CloudTrail S3 Data Events and AWS WAF logs are NOT included by default due to potentially high volume and cost – they must be explicitly enabled.
    • EKS Audit Logs and Lambda Data Events are optional and can be enabled separately.

    Security Lake Subscriber Model

    • Security Lake uses a subscriber model to provide controlled access to the security data lake.
    • Subscribers are external or internal consumers (SIEM tools, analytics platforms, custom applications) that need access to the centralized security data.
    • Two types of subscriber access are available:

    Data Access Subscribers

    • Data access subscribers receive notifications when new objects are written to the data lake and can directly access the S3 objects.
    • Subscribers are notified via:
      • HTTPS endpoint (default) – Security Lake sends notifications to a subscriber-provided endpoint.
      • Amazon SQS queue – Subscriber polls an SQS queue for new object notifications.
    • Data access uses AWS Resource Access Manager (RAM) to share S3 resources cross-account.
    • Best suited for SIEM tools that need to ingest raw data into their own systems (e.g., Splunk, Datadog).
    • Subscriber specifies which log sources they are authorized to consume.

    Query Access Subscribers

    • Query access subscribers can directly query the data in place using AWS Lake Formation tables.
    • Subscribers query data through services like Amazon Athena without needing to copy or move the data.
    • Uses AWS Lake Formation permissions for fine-grained access control.
    • Requires creation of an AmazonSecurityLakeMetaStoreManager role to manage AWS Glue partitions and table updates.
    • Best suited for analytics tools that support federated queries or organizations that want to avoid data duplication.
    • A query access subscriber can only query data in the AWS Region where it was created.

    Subscriber Configuration

    • When creating a subscriber, you specify:
      • Subscriber name and description
      • Log and event sources the subscriber can access
      • Data access method (S3 data access or Lake Formation query access)
      • Subscriber credentials (AWS account ID and external ID)
      • Notification method (SQS queue or subscription endpoint) for data access subscribers

    SIEM Tool Integration

    • Security Lake integrates with major SIEM and security analytics platforms through the subscriber model.
    • OCSF normalization eliminates the need for custom parsers in each SIEM tool.

    Splunk Integration

    • Splunk integrates with Security Lake as a data access subscriber.
    • Uses the Splunk Add-on for Amazon Security Lake to ingest OCSF-normalized data.
    • Splunk polls SQS notifications and ingests new Parquet files from S3.
    • Supports building SOC workflows with Security Lake as the centralized data source.
    • Siemens uses this integration to centralize security data across 800+ AWS accounts.

    Datadog Integration

    • Datadog integrates with Security Lake for Cloud SIEM use cases.
    • Datadog Observability Pipelines can send standardized OCSF-formatted logs to Security Lake.
    • Supports bidirectional integration – ingest from Security Lake into Datadog Cloud SIEM, or route logs to Security Lake for long-term retention.
    • Enables unified security monitoring across AWS and hybrid environments.

    IBM QRadar Integration

    • IBM QRadar integrates with Security Lake as a subscriber to ingest normalized security events.
    • QRadar uses the Amazon Security Lake DSM (Device Support Module) to parse OCSF data.
    • Enables centralized threat detection combining AWS security data with on-premises sources in QRadar.

    Other Supported Integrations

    • Amazon OpenSearch Service – Direct integration for interactive log analytics, real-time monitoring, pre-built OCSF dashboards, and on-demand indexing.
    • Amazon Detective – Subscribes to Security Lake for enhanced investigation workflows.
    • CrowdStrike – Sends endpoint detection data to Security Lake; consumes Security Lake data for correlation.
    • Palo Alto Networks (Cortex XSIAM) – Ingests Security Lake data for extended detection and response.
    • SentinelOne – Integrates for unified cloud and endpoint security analytics.
    • Rapid7 – Consumes Security Lake data for managed detection and response.

    Lake Formation Access Control

    • AWS Lake Formation provides the access control layer for Security Lake data.
    • Lake Formation manages permissions for the Glue Data Catalog tables that point to Security Lake S3 data.
    • Key capabilities:
      • Table-level permissions – Control which subscribers can access which log source tables.
      • Column-level permissions – Restrict access to specific fields within a table (e.g., mask IP addresses).
      • Row-level security – Filter data based on attributes (e.g., only show data from specific accounts).
      • Cell-level security – Combine row and column filters for granular control.
    • Lake Formation supports cross-account sharing via AWS Resource Access Manager (RAM), enabling subscribers in different accounts to query Security Lake data.
    • The delegated administrator manages Lake Formation permissions for the organization’s security data lake.
    • Lake Formation permissions are provided at no additional charge – you only pay for the underlying services (Glue, S3, Athena queries).

    Cross-Account and Cross-Region Support

    Multi-Account with AWS Organizations

    • Security Lake integrates with AWS Organizations for centralized multi-account management.
    • The Organizations management account designates a delegated Security Lake administrator.
    • The delegated administrator can:
      • Enable Security Lake for all member accounts
      • Configure log sources for the entire organization
      • Automatically collect data from new organization accounts
      • Grant subscriber permissions to consume data from member accounts
    • The management account cannot be set as the delegated administrator (security best practice).
    • Each account sees its own usage on its bill, but consolidated billing applies through the organization management account.
    • The delegated account is NOT billed for all accounts – each account incurs its own log collection charges.

    Cross-Region with Rollup Regions

    • Security Lake supports enabling across multiple AWS Regions simultaneously.
    • Rollup Regions consolidate data from one or more contributing Regions into a central Region.
    • Use cases for rollup Regions:
      • Compliance – Consolidate data into a Region that meets data residency requirements.
      • Centralized analysis – Query all security data from a single Region.
      • Reduced complexity – Subscribers only need to access one Region.
    • Standard data transfer costs apply for cross-Region replication.
    • Data in contributing Regions remains available locally – rollup creates a consolidated copy.

    Security Lake Pricing

    • Security Lake uses pay-as-you-go pricing with no upfront costs.
    • Pricing is based on two dimensions:

    Pricing Dimensions

    Dimension Description Cost (US East)
    CloudTrail Log Ingestion Per GB of CloudTrail data (management + data events) $0.75 per GB
    Other AWS Log Ingestion Per GB of VPC Flow Logs, Route 53, Security Hub, WAF, EKS, Lambda $0.25 per GB
    Data Normalization Per GB for OCSF conversion and Parquet formatting $0.035 per GB
    Third-Party Data Ingestion Custom/third-party source ingestion $0 (no charge)
    S3 Storage Standard Amazon S3 storage charges Standard S3 pricing
    Lake Formation Permissions Access control management $0 (no charge)

    Additional Costs

    • AWS Glue – Orchestration costs for data catalog management.
    • Amazon EventBridge – Event routing for subscriber notifications.
    • AWS Lambda – Custom processing functions.
    • Amazon SQS/SNS – Subscriber notification delivery.
    • Amazon Athena – Per-query charges for query access subscribers.
    • Data Transfer – Cross-Region replication for rollup Regions.

    Cost Optimization

    • Security Lake can offset existing costs by replacing duplicate CloudTrail trails or individual VPC Flow Log configurations.
    • Use automated storage tiering to move older data to S3 Glacier.
    • Carefully evaluate enabling CloudTrail S3 Data Events and WAF logs – these high-volume sources can significantly impact costs.
    • A 15-day free trial is available with full feature access and a usage estimation tab in the console.

    Security Lake vs. CloudWatch Logs vs. S3 Manual Aggregation

    Feature AWS Security Lake CloudWatch Logs S3 Manual Aggregation
    Purpose Centralized security data lake Operational log monitoring Custom data lake (DIY)
    Data Normalization Automatic OCSF normalization No normalization (raw logs) Manual ETL required
    Schema OCSF (standardized, open-source) Source-specific formats Custom schema (self-managed)
    Storage Format Apache Parquet + Iceberg tables CloudWatch proprietary format Any format (JSON, CSV, Parquet)
    Multi-Account Built-in via Organizations Cross-account log subscriptions Custom cross-account S3 policies
    Multi-Region Rollup Regions (built-in) Per-Region (no native aggregation) Custom S3 replication rules
    Access Control Lake Formation (fine-grained) IAM policies + Log Groups S3 bucket policies + IAM
    Query Engine Athena, OpenSearch, Redshift Spectrum CloudWatch Logs Insights Athena, custom tools
    SIEM Integration Native subscriber model Log subscriptions to Kinesis/Lambda Custom integration required
    Retention Management Automated tiering + custom retention Log group retention policies S3 Lifecycle policies (manual)
    Setup Complexity Low (managed service) Low (per-service) High (custom infrastructure)
    Cost Model Per-GB ingestion + normalization + S3 Per-GB ingestion + storage + queries S3 + Glue + Athena + custom ETL
    Best For Security analytics, SIEM feeding, compliance Real-time operational monitoring Full customization, non-security data lakes

    When to Use Each

    • Security Lake – When you need centralized, normalized security data across multiple accounts/Regions for threat detection, incident response, and SIEM integration.
    • CloudWatch Logs – When you need real-time operational monitoring, metric-based alarms, and log analysis for application debugging.
    • S3 Manual Aggregation – When you have custom requirements, non-security data, or need complete control over the ETL pipeline and schema design.
    • These solutions are complementary, not mutually exclusive – many organizations use CloudWatch Logs for real-time operations while using Security Lake for security analytics and long-term retention.

    AWS Certification Relevance (SCS-C02)

    • Security Lake is highly relevant for the AWS Certified Security – Specialty (SCS-C02) exam.
    • Key exam domains where Security Lake appears:
      • Domain 2: Security Logging and Monitoring – Centralized log management, log aggregation across accounts/Regions, OCSF normalization.
      • Domain 1: Threat Detection and Incident Response – SIEM integration, threat detection workflows, subscriber model for security tools.
      • Domain 6: Management and Security Governance – Multi-account security management, Organizations integration, delegated administrator.
    • Key concepts to understand for the exam:
      • How Security Lake differs from CloudWatch Logs and CloudTrail Lake
      • The subscriber model (data access vs. query access)
      • OCSF as the normalization standard
      • Cross-account and cross-Region data aggregation
      • Lake Formation for access control
      • Integration with Security Hub and GuardDuty

    AWS Security Lake Practice Questions

    1. A security team needs to centralize security logs from 50 AWS accounts across 4 Regions into a single data lake for their SIEM tool. The solution must normalize data from VPC Flow Logs, CloudTrail, GuardDuty findings, and third-party endpoint agents into a common schema. Which solution meets these requirements with the LEAST operational overhead?
      1. Create a centralized S3 bucket with cross-account bucket policies and use AWS Glue ETL jobs to normalize all log formats
      2. Enable Amazon Security Lake with AWS Organizations, configure rollup Regions, and use the OCSF schema for normalization
      3. Set up CloudWatch Logs cross-account subscriptions with Kinesis Data Firehose to deliver to a centralized S3 bucket
      4. Deploy AWS CloudTrail Lake with organization-wide event data stores in each Region
      Show Answer

      Answer: B –

      Explanation: Security Lake is purpose-built for this use case – it natively integrates with Organizations for multi-account collection, supports rollup Regions for cross-Region aggregation, automatically normalizes AWS sources to OCSF, and provides a subscriber model for SIEM tools. Third-party sources can also be ingested in OCSF format. Options A and C require significant custom engineering. Option D only covers CloudTrail events, not VPC Flow Logs or third-party sources.

    2. A company uses Amazon Security Lake and wants their Splunk deployment to ingest new security events as soon as they arrive. The Splunk instance runs in a separate AWS account. Which subscriber configuration should be used?
      1. Create a query access subscriber and configure Splunk to run periodic Athena queries
      2. Create a data access subscriber with SQS queue notification and provide the Splunk account credentials
      3. Share the S3 bucket directly with the Splunk account using a bucket policy
      4. Configure CloudWatch Logs subscription filters to forward to the Splunk account
      Show Answer

      Answer: B –

      Explanation: For SIEM tools like Splunk that need to ingest raw data as it arrives, a data access subscriber with SQS notification is the correct approach. Splunk polls the SQS queue for new object notifications and ingests the Parquet files from S3. AWS Resource Access Manager handles cross-account S3 access. Option A (query access) is for in-place querying, not data ingestion. Options C and D bypass Security Lake’s managed subscriber model.

    3. An organization enabled Security Lake but is concerned about costs. They notice that CloudTrail S3 Data Events and WAF logs account for 80% of their bill. What is the MOST cost-effective approach while maintaining security visibility?
      1. Disable Security Lake entirely and use CloudWatch Logs instead
      2. Remove CloudTrail S3 Data Events and WAF from Security Lake sources, and selectively enable them only for critical accounts or buckets
      3. Move all data to S3 Glacier immediately after ingestion
      4. Switch all subscribers from data access to query access
      Show Answer

      Answer: B –

      Explanation: CloudTrail S3 Data Events and WAF logs are high-volume sources that are NOT enabled by default in Security Lake for this exact reason. The recommended approach is to selectively enable these sources only where critical visibility is needed. Disabling Security Lake entirely (A) loses all centralized security data. Moving to Glacier immediately (C) makes data unavailable for real-time analysis. Subscriber type (D) doesn’t affect ingestion costs.

    4. A security analyst with query access to Security Lake needs to investigate suspicious network traffic from a specific source IP across all Regions. Security Lake is enabled in 3 Regions with a rollup Region configured. How should the analyst run this investigation?
      1. Run separate Athena queries in each of the 3 contributing Regions
      2. Query the rollup Region using Amazon Athena, which contains consolidated data from all contributing Regions
      3. Use CloudWatch Logs Insights to search across all Regions simultaneously
      4. Create a new subscriber in each Region and aggregate results manually
      Show Answer

      Answer: B –

      Explanation: Rollup Regions consolidate data from contributing Regions into a central location. The analyst only needs to query the rollup Region using Athena to search across all Regional data. This eliminates the need for separate queries in each Region. Note that a query access subscriber can only query data in the Region where it was created, so querying the rollup Region provides the consolidated view.

    5. A company wants to provide their managed security service provider (MSSP) access to Security Lake data. The MSSP needs to run custom threat hunting queries using Amazon Athena but should only see VPC Flow Logs and GuardDuty findings – not CloudTrail events. Which approach provides the required access with least privilege?
      1. Create a data access subscriber for the MSSP and filter notifications to only include VPC Flow Logs and GuardDuty
      2. Create a query access subscriber for the MSSP, specifying only VPC Flow Logs and Security Hub (GuardDuty findings) as authorized sources, with Lake Formation permissions
      3. Share the entire S3 bucket with the MSSP account and rely on IAM policies for filtering
      4. Export VPC Flow Logs and GuardDuty findings to a separate S3 bucket and share that with the MSSP
      Show Answer

      Answer: B –

      Explanation: A query access subscriber with specific source authorization is the correct approach. When creating a subscriber, you specify which log and event sources the subscriber can access. Lake Formation provides fine-grained access control to the specific tables. The MSSP uses Athena to query in place without data duplication. Option A (data access) would send raw data rather than enabling Athena queries. Options C and D bypass Security Lake’s managed access control model.

    Frequently Asked Questions

    What is AWS Security Lake?

    AWS Security Lake automatically centralizes security data from AWS services, SaaS providers, and custom sources into a purpose-built data lake in your account. It normalizes data to the Open Cybersecurity Schema Framework (OCSF) and stores it as Apache Iceberg tables.

    How does Security Lake differ from CloudWatch Logs?

    CloudWatch Logs stores operational logs for monitoring and alerting. Security Lake normalizes security-specific data to OCSF format for long-term storage, cross-account aggregation, and integration with SIEM/analytics tools like Splunk and Datadog.

    What data sources does Security Lake support?

    Native sources include CloudTrail, VPC Flow Logs, Route 53 DNS, Security Hub findings, Lambda, EKS audit logs, WAF, and S3 data events. It also supports custom sources via OCSF-formatted Parquet files and third-party integrations.

    Related Posts

    References

    IAM Roles vs Policies vs Users – Complete Guide

    ~ Last updated on : ~ Kiro Agent ~ Leave a comment

    AWS IAM Roles vs Policies vs Users – Complete Guide

    AWS Identity and Access Management (IAM) is the foundation of security in AWS. Understanding the differences between IAM Users, IAM Roles, and IAM Policies is critical for both real-world AWS security and AWS certification exams. This guide provides a comprehensive comparison of these three core IAM components, explains how they work together, and covers best practices for 2025-2026.

    IAM — How Users, Roles & Policies Work Together
    AWS Account
    IAM User
    Long-term credentials
    (Access Key / Password)
    IAM Role
    Temporary credentials
    (AssumeRole → STS)
    IAM Group
    Collection of Users
    (attach policies to group)
    ↓ All get permissions from ↓
    Identity Policy
    Attached to User/Role/Group
    Resource Policy
    Attached to S3/SQS/KMS
    Permission Boundary
    Max permissions cap
    SCP
    Organization guardrail

    IAM Overview – The Big Picture

    IAM controls who (authentication) can do what (authorization) on which resources in your AWS account. Every single AWS API call passes through IAM for evaluation before reaching the target service.

    The three core building blocks are:

    • IAM Users – Identities representing people or applications with long-term credentials
    • IAM Roles – Identities with temporary credentials that can be assumed by trusted entities
    • IAM Policies – JSON documents that define permissions (allow/deny actions on resources)
    Component What It Is Credentials Primary Use Case
    IAM User An identity (person or app) Long-term (password, access keys) Legacy human access, service accounts
    IAM Role An assumable identity Temporary (STS tokens, 1-12 hrs) Services, cross-account, federation
    IAM Policy A permissions document N/A (attached to identities/resources) Define what actions are allowed/denied

    IAM Users

    What Are IAM Users?

    An IAM User is an identity within your AWS account that represents a person or application. Each IAM user has:

    • A unique name within the AWS account
    • Long-term credentials – either a password (for console access) or access keys (for programmatic access)
    • A unique ARN – e.g., arn:aws:iam::123456789012:user/jayendra

    IAM User Credentials

    Credential Type Usage Rotation
    Password AWS Console sign-in Configurable via password policy
    Access Key ID + Secret Access Key CLI, SDK, API calls Manual (max 2 active keys per user)
    MFA Device Additional authentication factor Virtual (TOTP) or hardware

    When to Use IAM Users

    • Third-party integrations that cannot use IAM roles or OIDC federation
    • Break-glass emergency access when federation is unavailable
    • Very small teams (1-2 people) without AWS Organizations
    ⚠️ Best Practice (2025-2026): AWS strongly recommends using IAM Identity Center (formerly AWS SSO) instead of IAM users for human access. IAM Identity Center provides temporary credentials, centralized management, and integrates with external identity providers (Okta, Entra ID, Google Workspace). Reserve IAM users for legacy workloads and specific programmatic use cases.

    IAM Groups

    IAM Groups are collections of IAM users that simplify permission management:

    • Attach policies to a group; all users in the group inherit those permissions
    • A user can belong to up to 10 groups
    • Groups cannot be nested (no group within a group)
    • Groups are not identities – they cannot be referenced in resource-based policies or assume roles

    IAM Roles

    What Are IAM Roles?

    An IAM Role is an identity with specific permissions that can be assumed by trusted entities. Unlike users, roles do not have long-term credentials. When an entity assumes a role, AWS STS (Security Token Service) provides temporary security credentials consisting of:

    • Access Key ID
    • Secret Access Key
    • Session Token
    • Expiration timestamp (default 1 hour, configurable 15 min to 12 hours)

    Role Components

    Component Purpose Example
    Trust Policy Defines WHO can assume the role EC2 service, another account, OIDC provider
    Permissions Policy Defines WHAT the role can do Read S3, write DynamoDB
    Permission Boundary Sets maximum permissions ceiling Restrict to specific services only
    Session Duration How long credentials are valid 1 hour (default), max 12 hours

    Trust Policy Example

    This trust policy allows the EC2 service to assume this role, enabling EC2 instances to use the role’s permissions.

    Types of IAM Roles

    Role Type Trusted Entity Use Case
    Service Role AWS Service (EC2, Lambda, ECS) EC2 instance accessing S3, Lambda accessing DynamoDB
    Cross-Account Role Another AWS account Account A accessing resources in Account B
    Federation Role Identity Provider (SAML/OIDC) Corporate SSO users accessing AWS
    Service-Linked Role Specific AWS service Pre-defined by AWS, cannot modify permissions

    Cross-Account Access with Roles

    Cross-account roles enable secure access between AWS accounts without sharing long-term credentials:

    1. Account B (resource owner) creates a role with a trust policy allowing Account A
    2. Account A (requester) grants its users/roles permission to call sts:AssumeRole on Account B’s role
    3. User in Account A calls AssumeRole and receives temporary credentials for Account B

    Role Chaining

    Role chaining occurs when a role assumes another role. Key limitations:

    • Maximum session duration is limited to 1 hour (regardless of role’s max session setting)
    • CloudTrail logs each AssumeRole call in the chain
    • The final role’s permissions apply (not a union of all roles in the chain)

    IAM Roles Anywhere

    Launched in 2022 and enhanced through 2025, IAM Roles Anywhere extends IAM roles to workloads outside AWS using X.509 certificates. On-premises servers, IoT devices, and other non-AWS workloads can obtain temporary AWS credentials without long-term access keys.

    IAM Policies

    What Are IAM Policies?

    IAM Policies are JSON documents that define permissions. They specify which actions are allowed or denied on which resources under what conditions. Policies do not grant access on their own – they must be attached to an identity (user, group, role) or a resource.

    Policy Structure

    Policy Elements

    Element Required Description
    Version Yes Always use “2012-10-17” (current version)
    Statement Yes Array of permission statements
    Sid No Statement identifier (optional description)
    Effect Yes Allow or Deny
    Principal Resource policies only Who the policy applies to
    Action Yes API actions (e.g., s3:GetObject)
    Resource Yes ARN of resources the policy applies to
    Condition No When the policy is in effect

    Types of IAM Policies

    Identity-Based Policies vs Resource-Based Policies

    Aspect Identity-Based Policies Resource-Based Policies
    Attached to Users, Groups, Roles Resources (S3 bucket, SQS queue, KMS key)
    Principal element Not used (implied by attachment) Required (specifies who gets access)
    Cross-account Requires role assumption Can grant access directly to another account
    Types Managed and Inline Inline only (embedded in resource)
    Examples AmazonS3ReadOnlyAccess S3 Bucket Policy, SQS Queue Policy, KMS Key Policy
    💡 Key Difference for Cross-Account Access: With resource-based policies, the principal retains permissions from their original account (no need to give up permissions). With IAM roles, the assuming entity temporarily gives up their original permissions and takes on only the role’s permissions.

    AWS Managed vs Customer Managed vs Inline Policies

    Type Created By Reusable Versioning Use When
    AWS Managed AWS Yes (across accounts) Yes (AWS updates) Standard permissions for common use cases
    Customer Managed You Yes (within account) Yes (up to 5 versions) Custom, reusable permissions specific to your org
    Inline You No (1:1 with identity) No Strict 1:1 relationship, deleted with identity

    Permission Boundaries

    A permission boundary is an advanced feature that sets the maximum permissions an IAM entity (user or role) can have. It acts as a guardrail:

    • The effective permissions = intersection of identity-based policies AND permission boundary
    • Even if an identity-based policy grants s3:*, if the permission boundary only allows s3:GetObject, the effective permission is only s3:GetObject
    • Used for delegation – allow developers to create roles but only within defined boundaries
    • Permission boundaries do NOT grant permissions on their own

    Service Control Policies (SCPs)

    SCPs are organization-level policies in AWS Organizations that set permission guardrails across all accounts:

    • Apply to all IAM users and roles in member accounts (including root user for service actions)
    • Do NOT grant permissions – they only restrict what’s allowed
    • Effective permissions = SCP ∩ Identity-based policies ∩ Permission boundaries
    • Can be attached at Organization root, OU, or account level
    • Do NOT affect the management account
    • As of 2025, SCPs support the full IAM policy language including conditions in Allow statements and NotAction

    Resource Control Policies (RCPs)

    Introduced in 2024, Resource Control Policies (RCPs) complement SCPs by controlling access to resources rather than identities:

    • Restrict which principals (including external accounts) can access resources in your organization
    • Applied at Organization root, OU, or account level
    • Complement SCPs (identity guardrails) with resource-level guardrails

    IAM Policy Evaluation Logic

    When an AWS API call is made, IAM evaluates all applicable policies in a specific order:

    1. Explicit Deny – If ANY policy explicitly denies the action → DENIED (always wins)
    2. Resource Control Policies (RCPs) – Organization-level resource guardrails
    3. Service Control Policies (SCPs) – Organization-level identity guardrails
    4. Resource-Based Policies – If the resource policy allows the caller → may ALLOW (same account)
    5. Permission Boundaries – Must allow the action for it to proceed
    6. Session Policies – If using assumed role with session policy, must allow
    7. Identity-Based Policies – Must explicitly allow the action
    💡 Key Rule: By default, all requests are implicitly denied. An explicit Allow is required (from the appropriate policy type), and an explicit Deny always overrides any Allow.

    Same-Account vs Cross-Account Evaluation

    Scenario Requirements
    Same account Either identity-based OR resource-based policy can grant access
    Cross-account BOTH the identity-based policy (in caller’s account) AND resource-based policy (in resource’s account) must allow access

    How Users, Roles, and Policies Work Together

    Visual Hierarchy

    Common Patterns

    Pattern 1: EC2 Instance Accessing S3

    1. Create an IAM Role with a trust policy for ec2.amazonaws.com
    2. Attach an identity-based policy granting S3 permissions to the role
    3. Attach the role to the EC2 instance (Instance Profile)
    4. Application on EC2 uses temporary credentials automatically via instance metadata

    Pattern 2: Lambda Function Accessing DynamoDB

    1. Create an IAM Role with a trust policy for lambda.amazonaws.com
    2. Attach policies granting DynamoDB access
    3. Assign the role as the Lambda execution role
    4. Lambda automatically assumes the role on each invocation

    Pattern 3: Cross-Account S3 Access

    1. Option A (Role-based): Create a role in Account B, trust Account A, grant S3 access
    2. Option B (Resource-based): Add a bucket policy in Account B allowing Account A’s principal

    Pattern 4: Developer Permission Delegation

    1. Admin creates a permission boundary policy (e.g., only allow S3 and DynamoDB actions)
    2. Admin grants developer permission to create roles WITH the permission boundary
    3. Developer creates roles freely, but those roles can never exceed the boundary’s permissions

    Best Practices (2025-2026)

    1. Use IAM Identity Center for Human Access

    • Replace IAM users with IAM Identity Center (formerly AWS SSO)
    • Connect your existing IdP (Okta, Entra ID, Google Workspace)
    • Provides temporary credentials with automatic token refresh
    • Single sign-on to all AWS accounts and applications
    • No additional AWS charge for IAM Identity Center

    2. Enforce Least Privilege

    • Start with minimal permissions and add as needed
    • Use IAM Access Analyzer to generate policies based on actual usage (CloudTrail)
    • Review and remove unused permissions regularly
    • Use last accessed information to identify unused services
    • Prefer specific actions over wildcards (s3:GetObject not s3:*)

    3. Require MFA

    • Enable MFA for all IAM users (especially those with console access)
    • Use policy conditions to require MFA for sensitive operations: "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    • Prefer FIDO2/WebAuthn security keys over TOTP virtual MFA

    4. Use Roles Over Users

    • EC2 instances → use Instance Profiles (IAM Roles)
    • Lambda functions → use Execution Roles
    • Cross-account access → use IAM Roles with AssumeRole
    • On-premises workloads → use IAM Roles Anywhere
    • CI/CD pipelines → use OIDC federation (GitHub Actions, GitLab)

    5. Implement Guardrails at Scale

    • Use SCPs to prevent dangerous actions organization-wide (e.g., deny leaving organization, deny disabling CloudTrail)
    • Use Permission Boundaries for delegation (developers creating their own roles)
    • Use RCPs to restrict external access to your resources
    • Tag-based access control (ABAC) for scalable permissions management

    6. Monitor and Audit

    • Enable CloudTrail in all accounts and regions
    • Use IAM Access Analyzer to detect external and unused access
    • Review IAM credential reports regularly
    • Set up alerts for root account usage

    When to Use Each – Decision Guide

    Scenario Use Why
    Human accessing AWS Console IAM Identity Center Centralized, temporary credentials, SSO
    EC2 instance needs AWS API access IAM Role (Instance Profile) Temporary credentials, auto-rotated
    Lambda function accessing DynamoDB IAM Role (Execution Role) Service role, no static credentials
    Account A accessing Account B resources IAM Role (Cross-Account) Secure delegation without sharing keys
    Third-party SaaS needing AWS access IAM Role (External ID) Prevents confused deputy, no shared secrets
    CI/CD pipeline (GitHub Actions) IAM Role (OIDC Federation) No stored AWS secrets in CI system
    On-premises server accessing S3 IAM Roles Anywhere X.509 certs, temporary credentials
    Restricting max permissions for developers Permission Boundary Delegation without privilege escalation
    Organization-wide security guardrails SCPs Prevent dangerous actions across all accounts
    Allow external account to access S3 bucket Resource-Based Policy Principal retains own permissions
    Emergency break-glass access IAM User (with MFA) When federation/SSO is unavailable

    AWS Certification Exam Tips

    🎯 Exam Tips for SAA-C03, SAP-C02, SCS-C02, DVA-C02:

    • Explicit Deny always wins – No matter what allows exist, a single deny overrides everything
    • Roles for services, users for legacy – If the question mentions EC2/Lambda needing access, the answer involves a role, not access keys
    • Cross-account = role OR resource policy – Know when each is appropriate. Resource-based policies let the caller keep their original permissions
    • Permission boundaries don’t grant permissions – They only restrict. Effective = identity policy ∩ boundary
    • SCPs don’t affect management account – Common exam trick question
    • External ID prevents confused deputy – Required for third-party cross-account access
    • Role chaining limits session to 1 hour – Even if role’s max is 12 hours
    • Groups are NOT identities – Cannot be principal in a resource policy, cannot assume roles
    • IAM is global – Not region-specific (but STS endpoints can be regional)
    • AssumeRoleWithWebIdentity vs AssumeRoleWithSAML – Web identity for OIDC (Cognito, GitHub), SAML for enterprise IdPs

    IAM Roles vs Policies vs Users – Practice Questions

    Question 1

    A company wants its EC2 instances to securely access objects in an S3 bucket without storing credentials on the instances. What is the recommended approach?

    1. Create an IAM user, generate access keys, and store them in environment variables on the EC2 instance
    2. Create an IAM role with S3 permissions and associate it with the EC2 instance via an instance profile
    3. Add a bucket policy allowing all EC2 instances in the VPC to access the bucket
    4. Enable public access on the S3 bucket for the specific objects needed
    Show Answer

    Answer: B –

    Explanation: IAM roles attached to EC2 instances (via instance profiles) provide temporary credentials that are automatically rotated. This eliminates the need to store long-term credentials. Option A uses long-term credentials which is a security risk. Option C is not how bucket policies work (VPC endpoint policies could restrict, but not via bucket policy to EC2). Option D removes security entirely.

    Question 2

    An organization uses AWS Organizations with multiple accounts. They want to ensure NO user in any member account can disable CloudTrail, regardless of their IAM permissions. What should they implement?

    1. An IAM policy attached to all users denying cloudtrail:StopLogging
    2. A permission boundary on all roles denying cloudtrail:StopLogging
    3. A Service Control Policy (SCP) denying cloudtrail:StopLogging on member accounts
    4. A resource-based policy on the CloudTrail trail denying StopLogging
    Show Answer

    Answer: C –

    Explanation: SCPs provide organization-wide guardrails that cannot be overridden by any IAM policy within member accounts. Option A requires attaching to every user and can be removed by admins. Option B requires applying to every role and doesn’t cover users. Option D is not supported by CloudTrail. Only SCPs provide mandatory, centralized enforcement across accounts.

    Question 3

    A developer in Account A (111111111111) needs to access a DynamoDB table in Account B (222222222222). The solution must NOT require the developer to give up their Account A permissions while accessing Account B’s table. What approach should be used?

    1. Create a cross-account IAM role in Account B and have the developer assume it
    2. Create an IAM user in Account B for the developer with DynamoDB permissions
    3. Add a resource-based policy on the DynamoDB table granting access to Account A’s developer
    4. Use VPC peering between the accounts to access DynamoDB
    Show Answer

    Answer: C –

    Explanation: Resource-based policies allow cross-account access while the principal retains their original account permissions. When you assume a role (Option A), you temporarily give up your original permissions and can only use the assumed role’s permissions. DynamoDB does not support resource-based policies directly, but this question tests the concept. In practice, for DynamoDB cross-account, you would use a role. However, for the exam concept being tested: resource-based policies = keep original permissions; role assumption = adopt role’s permissions only.

    Note: In real-world scenarios, DynamoDB does NOT support resource-based policies, so cross-account IAM roles would be the correct approach for DynamoDB specifically. This question tests conceptual understanding of the difference between roles and resource-based policies.

    Question 4

    A company wants to allow its development team to create IAM roles for their Lambda functions, but ensure those roles can never have more permissions than a predefined set (S3 and DynamoDB access only). What should the security team implement?

    1. An SCP restricting the development account to S3 and DynamoDB only
    2. A permission boundary policy that allows only S3 and DynamoDB actions, required when developers create roles
    3. AWS managed policies that only include S3 and DynamoDB permissions
    4. Inline policies on each developer’s IAM user restricting role creation
    Show Answer

    Answer: B –

    Explanation: Permission boundaries are designed for this exact delegation pattern. The security team creates a permission boundary policy allowing only S3 and DynamoDB. They then grant developers permission to create roles only if those roles have this permission boundary attached (using iam:PermissionsBoundary condition key). This ensures developers can self-service while preventing privilege escalation. Option A would restrict the entire account, not just developer-created roles. Options C and D don’t prevent developers from attaching broader policies.

    Question 5

    A company’s security policy requires that all API calls from IAM users must use Multi-Factor Authentication (MFA). They want users who haven’t authenticated with MFA to only be able to manage their own MFA device. Which policy approach achieves this?

    1. Attach a deny policy that denies all actions except MFA management unless aws:MultiFactorAuthPresent is true
    2. Remove all permissions from users and only grant them through roles that require MFA to assume
    3. Use an SCP to deny all actions unless MFA is present
    4. Configure the AWS account password policy to require MFA
    Show Answer

    Answer: A –

    Explanation: The standard pattern uses a policy with two statements: (1) Allow MFA self-management actions always, and (2) Deny all other actions with a condition "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}. This forces users to set up and authenticate with MFA before they can perform any other actions. Option B works but is overly complex. Option C would affect all principals including service roles which don’t use MFA. Option D only enforces MFA at console sign-in, not for API/CLI calls.

    Related Posts

    Related Posts

    References

    AWS Certified Security – Specialty (SCS-C01) Exam Learning Path

    AWS Certified Security - Specialty SCS-C01 Certificate
    ~ Last updated on : ~ jayendrapatil ~ 55 Comments

    AWS Certified Security – Specialty (SCS-C03) Exam Learning Path

    ⚠️ EXAM VERSION UPDATE

    AWS Certified Security – Specialty SCS-C01 was retired on July 10, 2023. SCS-C02 replaced it on July 11, 2023, and was subsequently replaced by SCS-C03 on December 2, 2025.

    This post has been updated to reflect the current SCS-C03 exam content, domains, and in-scope services.

    The AWS Certified Security – Specialty (SCS-C03) validates your ability to effectively secure workloads and architectures on AWS. The exam tests your knowledge of threat detection, incident response, infrastructure security, identity and access management, data protection, and security governance.

    AWS Certified Security – Specialty (SCS-C03) Exam Content

    • The AWS Certified Security – Specialty (SCS-C03) exam validates:
      • An understanding of specialized data classifications and AWS data protection mechanisms.
      • An understanding of data-encryption methods and AWS mechanisms to implement them.
      • An understanding of secure Internet protocols and AWS mechanisms to implement them.
      • The ability to design and implement security controls for cloud workloads including generative AI applications.
    • A working knowledge of AWS security services and features of services to provide a secure production environment.
    • Competency gained from two or more years of production deployment experience using AWS security services and features.
    • The ability to make tradeoff decisions with regard to cost, security, and deployment complexity given a set of application requirements.
    • An understanding of security operations and risks.

    Refer to AWS Certified Security – Specialty (SCS-C03) Exam Guide

    AWS Certified Security – Specialty (SCS-C03) Exam Domains

    Domain % of Exam
    Domain 1: Detection16%
    Domain 2: Incident Response14%
    Domain 3: Infrastructure Security18%
    Domain 4: Identity and Access Management20%
    Domain 5: Data Protection18%
    Domain 6: Security Foundations and Governance14%

    AWS Certified Security – Specialty (SCS-C03) Exam Summary

    • Specialty exams are tough, lengthy, and tiresome. Most of the questions and answers options have a lot of prose and a lot of reading that needs to be done, so be sure you are prepared and manage your time well.
    • SCS-C03 exam has 65 questions to be solved in 170 minutes which gives you roughly 2 1/2 minutes to attempt each question.
    • SCS-C03 exam includes two types of questions, multiple-choice and multiple-response.
    • SCS-C03 has a scaled score between 100 and 1,000. The scaled score needed to pass the exam is 750.
    • Specialty exams currently cost $300 + tax.
    • You can get an additional 30 minutes if English is your second language by requesting Exam Accommodations. It is helpful for Professional and Specialty exams.
    • As always, mark the questions for review and move on and come back to them after you are done with all.
    • Having a rough architecture or mental picture of the setup helps focus on the areas that you need to improve. You will be able to eliminate 2 answers for sure and then need to focus on only the other two.
    • AWS exams can be taken either remotely or at a test center. Just make sure you have a proper place to take the exam with no disturbance and nothing around you.
    • If you are taking the AWS Online exam, try to join at least 30 minutes before the actual time as there can be long wait times with PSI and Pearson VUE.

    AWS Certified Security – Specialty (SCS-C03) Exam Resources

    AWS Certified Security – Specialty (SCS-C03) Exam Topics

    • AWS Certified Security – Specialty (SCS-C03) exam focuses heavily on Detection, Incident Response, Infrastructure Security, IAM, Data Protection, and Security Governance involving Data Encryption at rest or in transit, Data protection, Auditing, Compliance and regulatory requirements, and automated remediation.
    • SCS-C03 adds emphasis on generative AI security (GenAI OWASP Top 10 for LLM Applications), OCSF format integration, and inter-resource encryption.

    Security, Identity & Compliance

    • Identity and Access Management (IAM)
      • IAM Roles to grant the service, users temporary access to AWS services.
        • IAM Role can be used to give cross-account access and usually involves creating a role within the trusting account with a trust and permission policy and granting the user in the trusted account permissions to assume the trusting account role.
      • Identity Providers & Federation to grant external user identity (SAML or Open ID compatible IdPs) permissions to AWS resources without having to be created within the AWS account.
      • IAM Policies help define who has access & what actions can they perform.
    • AWS IAM Identity Center (formerly AWS SSO)
      • is the recommended way to manage human access to multiple AWS accounts.
      • provides centralized workforce identity management with support for SAML 2.0, SCIM, and built-in identity store.
      • uses Permission Sets to define access levels for users/groups across AWS accounts.
      • integrates with AWS Organizations for multi-account access management.
      • supports external identity providers (Okta, Microsoft Entra ID, Google Workspace).
      • eliminates the need for long-term static access keys for human users.
    • Deep dive into Key Management Service (KMS). There would be quite a few questions on this.
      • is a managed encryption service that allows the creation and control of encryption keys to enable data encryption.
      • uses Envelope Encryption which uses a master key to encrypt the data key, which is then used to encrypt the data.
      • Understand how KMS works
      • Understand IAM Policies, Key Policies, Grants to grant access.
        • Key policies are the primary way to control access to KMS keys. Unless the key policy explicitly allows it, you cannot use IAM policies to allow access to a KMS key.
      • are regional, however, supports multi-region keys, which are KMS keys in different AWS Regions that can be used interchangeably.
      • KMS Multi-region keys
        • are AWS KMS keys in different AWS Regions that can be used interchangeably.
        • are not global and each multi-region key needs to be replicated and managed independently.
      • Understand the difference between CMK with generated and imported key material esp. in rotating keys. SCS-C03 explicitly tests understanding of differences between imported key material and AWS-generated key material.
      • KMS usage with VPC Endpoint which ensures the communication between the VPC and KMS is conducted entirely within the AWS network.
      • KMS ViaService condition
      • Supports automatic key rotation for customer managed keys (rotates every year by default, configurable rotation period).
    • CloudHSM
      • is a cloud-based hardware security module (HSM) that enables you to easily generate and use your own encryption keys on the AWS Cloud.
      • provides FIPS 140-2 Level 3 validated HSMs.
    • AWS Certificate Manager (ACM)
      • helps provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services.
      • to use an ACM Certificate with CloudFront, the certificate must be in the US East (N. Virginia) region.
      • is regional and you need to request certificates in all regions and associate individually.
      • does not support EC2 instances and private keys cannot be exported.
    • AWS Private Certificate Authority (Private CA)
      • is a managed private CA service for issuing and managing private certificates.
      • supports creating certificate hierarchies (root and subordinate CAs).
      • integrates with ACM for deployment of private certificates to AWS services.
      • is in-scope for SCS-C03 for managing encryption keys and certificates across single or multiple regions.
    • AWS Secrets Manager
      • protects secrets needed to access applications, services, etc.
      • enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.
      • supports automatic rotation of credentials for RDS, DocumentDB, Redshift, and custom Lambda rotation functions.
    • Secrets Manager vs Systems Manager Parameter Store
      • Secrets Manager supports automatic rotation while SSM Parameter Store does not.
      • Parameter Store is cost-effective as compared to Secrets Manager.
    • Amazon GuardDuty
      • is a threat detection service that continuously monitors the AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.
      • supports CloudTrail S3 data events and management event logs, DNS logs, EKS audit logs, VPC flow logs, RDS login activity, Lambda network activity, and Runtime Monitoring.
      • GuardDuty Malware Protection scans EBS volumes attached to EC2 instances and container workloads for malware.
      • GuardDuty Malware Protection for S3 scans newly uploaded objects in S3 buckets.
      • GuardDuty Runtime Monitoring provides runtime threat detection for EC2, EKS, ECS/Fargate workloads.
      • GuardDuty Extended Threat Detection uses AI/ML to correlate findings into attack sequences for EC2 and ECS.
    • Amazon Inspector
      • is an automated vulnerability management service that continuously scans AWS workloads for software vulnerabilities and unintended network exposure.
      • automatically discovers and scans EC2 instances, container images in ECR, and Lambda functions.
      • calculates a contextualized risk score using CVE information, network access, and exploitability.
      • supports code scanning (SAST, SCA) and Infrastructure as Code (IaC) scanning with GitHub/GitLab integration.
    • Amazon Detective
      • makes it easier to analyze, investigate, and quickly identify the root cause of security findings or suspicious activities.
      • automatically collects log data from AWS resources and uses machine learning, statistical analysis, and graph theory.
      • integrates with GuardDuty findings, Security Hub, and Security Lake.
      • supports automated IAM investigations to determine if a principal is involved in a security event.
      • can access up to a year of historical event data with visualizations.
    • Amazon Macie
      • is a security service that uses machine learning to automatically discover, classify, and protect sensitive data in S3.
      • can detect PII, financial data, credentials, and custom data identifiers.
    • Amazon Security Lake
      • automatically centralizes security data from AWS environments, SaaS providers, on-premises, and cloud sources into a purpose-built data lake.
      • uses the Open Cybersecurity Schema Framework (OCSF) to normalize and standardize security data.
      • natively collects CloudTrail management events, VPC Flow Logs, Route 53 Resolver query logs, and Security Hub findings.
      • integrates with Amazon Athena, OpenSearch, and third-party SIEM tools for analysis.
      • is explicitly tested in SCS-C03 Domain 1 (Detection) for creating metrics and dashboards to detect anomalous data.
    • AWS Artifact is a central resource for compliance-related information that provides on-demand access to AWS’ security and compliance reports and select online agreements.
    • AWS Shield & Shield Advanced
      • for DDoS protection and integrates with Route 53, CloudFront, ALB, and Global Accelerator.
    • AWS WAF
      • protects from common attack techniques like SQL injection and XSS.
      • integrates with CloudFront, ALB, API Gateway, AppSync, Cognito User Pools, App Runner, and Verified Access.
      • supports Web ACLs and can block traffic based on IPs, Rate limits, and specific countries.
      • supports managed rule groups from AWS and AWS Marketplace sellers (including third-party WAF rules for SCS-C03).
      • logs can be sent to CloudWatch Logs, S3 bucket, or Kinesis Data Firehose.
    • AWS Security Hub
      • is a cloud security posture management service that performs security best practice checks, aggregates alerts, and enables automated remediation.
      • consolidates findings from GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, and third-party tools.
      • supports security standards: AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, PCI DSS.
    • AWS Network Firewall is a stateful, fully managed, network firewall and intrusion detection and prevention service (IDS/IPS) for VPCs.
    • AWS Resource Access Manager helps you securely share your resources across AWS accounts, within your organization or organizational units (OUs).
    • AWS Audit Manager to map your compliance requirements to AWS usage data with prebuilt and custom frameworks and automated evidence collection.
    • Amazon Cognito esp. User Pools and Identity Pools for authentication and authorization.
    • AWS Firewall Manager helps centrally configure and manage firewall rules across accounts and applications in AWS Organizations which includes WAF, Shield Advanced, VPC security groups, Network Firewall, and Route 53 Resolver DNS Firewall.

    Networking & Content Delivery

    • Virtual Private Cloud – VPC
      • Security Groups, NACLs
        • NACLs are stateless, Security groups are stateful
        • NACLs at subnet level, Security groups at the instance level
        • NACLs need to open ephemeral ports for response traffic.
      • VPC Gateway Endpoints to provide access to S3 and DynamoDB
      • VPC Interface Endpoints or PrivateLink provide access to a variety of services like SQS, Kinesis, or Private APIs exposed through NLB.
      • VPC Peering
        • to enable communication between VPCs within the same or different regions.
        • Route tables need to be configured on either VPC for them to be able to communicate.
      • VPC Flow Logs help capture information about the IP traffic going to and from network interfaces in the VPC.
      • NAT Gateway provides managed NAT service with high availability and bandwidth.
      • VPC Network Access Analyzer helps identify unintended network access to resources by analyzing network reachability conditions.
    • AWS Verified Access
      • provides secure, VPN-less access to corporate applications using Zero Trust principles.
      • evaluates each request based on user identity and device health rather than network location.
      • uses Cedar policy language for fine-grained access policies.
      • supports HTTP/HTTPS applications and non-HTTP(S) protocols (SSH, RDP, JDBC/ODBC) since 2025.
      • integrates with identity providers and device trust providers.
      • is in-scope for SCS-C03 under Networking and Content Delivery.
    • Virtual Private Network – VPN & Direct Connect to establish connectivity between an on-premises data center and VPC.
      • IPSec VPN over Direct Connect to provide secure connectivity.
      • AWS Site-to-Site VPN is in-scope for SCS-C03.
    • AWS Transit Gateway
      • acts as a hub to connect VPCs and on-premises networks through a central gateway.
      • is in-scope for SCS-C03 for network security design patterns.
    • CloudFront
    • Route 53
      • is a highly available and scalable DNS web service.
      • Resolver Query logging logs queries from VPCs, on-premises resources using inbound/outbound resolvers. Can be logged to CloudWatch Logs, S3, and Kinesis Data Firehose.
      • Route 53 DNSSEC secures DNS traffic and helps protect from DNS spoofing attacks.
      • Route 53 Resolver DNS Firewall allows filtering and regulating outbound DNS traffic for VPCs.
    • Elastic Load Balancer
      • End to End encryption
        • NLB with TCP listener as pass through and terminating SSL on the EC2 instances
        • ALB with SSL termination and HTTPS between ALB and EC2 instances
    • Gateway Load Balancer – GWLB
      • helps deploy, scale, and manage virtual appliances, such as firewalls, IDS/IPS systems, and deep packet inspection systems.

    Management & Governance Tools

    • CloudWatch
      • CloudWatch Logs
        • CloudWatch Logs data protection policies can automatically mask sensitive data (PII, credentials) in log events (new in SCS-C03).
      • CloudWatch Subscription Filters and their integration with other services.
      • EventBridge (formerly CloudWatch Events) for real-time event-driven security automation.
    • CloudTrail for audit and governance
      • CloudTrail can be enabled for all regions and supports log file integrity validation.
      • With Organizations, the trail can be configured to log CloudTrail from all accounts to a central account.
      • CloudTrail Lake provides a managed data lake for querying CloudTrail events using SQL. In-scope for SCS-C03.
      • CloudTrail Insights detects unusual operational activity in your account.
    • AWS Config
      • AWS Config rules can alert for any changes and check the history of changes. Can check approved AMIs compliance.
      • allows remediation of noncompliant resources using AWS Systems Manager Automation documents.
      • AWS Config → EventBridge → Lambda/SNS
    • CloudTrail vs Config
      • CloudTrail provides the WHO and Config provides the WHAT.
    • Systems Manager
      • Parameter Store provides secure, scalable, centralized, hierarchical storage for configuration data and secret management.
      • Systems Manager Patch Manager helps select and deploy operating system and software patches across EC2 or on-premises instances.
      • Systems Manager Run Command provides safe, secure remote management of instances at scale.
      • Session Manager provides secure and auditable instance management without opening inbound ports or managing SSH keys.
    • AWS Organizations
      • is an account management service for consolidating multiple AWS accounts into a centrally managed organization.
      • can configure Organization Trail to centrally log all CloudTrail logs.
      • Service Control Policies (SCPs)
        • act as guardrails and specify the services and actions that users and roles can use.
        • are similar to IAM permission policies except that they don’t grant any permissions.
      • Resource Control Policies (RCPs) — new policy type that controls maximum permissions on resources in your organization.
    • AWS Trusted Advisor
      • inspects the AWS environment to make recommendations for performance, cost savings, availability, and security.
    • CloudFormation
      • Deletion Policy to prevent, retain, or backup RDS, EBS Volumes.
      • Stack policy can prevent stack resources from being unintentionally updated or deleted during a stack update.
    • Control Tower
      • to setup, govern, and secure a multi-account environment.
      • strongly recommended guardrails cover EBS encryption.

    Storage & Databases

    Compute

    • EC2 access using IAM Role, Lambda using the Execution role & ECS using the Task role.
    • EC2 Instance Metadata Service version 2 (IMDSv2) and enforcement of the same. IMDSv2 uses session-oriented requests to protect against SSRF attacks.
    • EC2 Image Builder for creating hardened AMIs and container images with embedded security controls (in-scope for SCS-C03).
    • Amazon EKS security — Pod security, IRSA (IAM Roles for Service Accounts), EKS Pod Identity.

    Generative AI Security (New in SCS-C03)

    • Amazon Bedrock Security
      • Bedrock Guardrails to filter harmful content, prevent prompt injection, and enforce responsible AI policies.
      • Data encryption at rest and in transit for model interactions.
      • VPC endpoints for private connectivity to Bedrock.
      • IAM policies for fine-grained access control to foundation models.
    • GenAI OWASP Top 10 for LLM Applications — SCS-C03 explicitly tests implementing protections against LLM vulnerabilities including prompt injection, data leakage, and insecure output handling.
    • Amazon Q security — access controls, data permissions, and guardrails for Q Business and Q Developer.

    Integration Tools

    • Know how CloudWatch integration with SNS and Lambda can help in notification and automated remediation.
    • Amazon SNS message data protection can mask or block sensitive data in messages (in-scope for SCS-C03 data protection).

    Whitepapers and Articles

    On the Exam Day

    • Make sure you are relaxed and get some good night’s sleep. The exam is not tough if you are well-prepared.
    • If you are taking the AWS Online exam
      • Try to join at least 30 minutes before the actual time as there can be long wait times.
      • The online verification process does take some time and usually, there are glitches.
      • Remember, you would not be allowed to take the exam if you are late by more than 30 minutes.
      • Make sure you have your desk clear, no hand-watches, or external monitors, keep your phones away, and nobody can enter the room.

    Finally, All the Best 🙂

    AWS Identity & Security Services Cheat Sheet

    ~ Last updated on : ~ jayendrapatil ~ 9 Comments

    AWS Identity & Security Services Cheat Sheet

    AWS Identity and Security Services

    📌 Last Updated: June 2026 — Includes AWS Security Hub reimagined (re:Invent 2025), AWS Security Agent (GA March 2026), mandatory MFA enforcement for all root users, GuardDuty Extended Threat Detection, and IAM Identity Center multi-Region replication.

    AWS Identity Services Cheat Sheet

    AWS Security Services Cheat Sheet

    AWS Identity & Security Services Overview

    AWS Security, Identity, and Compliance services provide a comprehensive set of tools to help protect data, accounts, and workloads. These services are organized into the following categories:

    Identity and Access Management

    • AWS Identity and Access Management (IAM) – Securely manage access to AWS services and resources using users, groups, roles, and policies
    • AWS IAM Identity Center (formerly AWS SSO) – Centrally manage SSO access to multiple AWS accounts and business applications
      • Now supports multi-Region replication (Feb 2026) for high availability
      • Supports IPv6 dual-stack endpoints
    • Amazon Cognito – Customer identity and access management (CIAM) for web and mobile apps
      • Now supports passwordless authentication with passkeys (FIDO2/WebAuthn), email OTP, and SMS OTP (Nov 2024)
      • New feature tiers: Essentials and Plus (Nov 2024)
      • Managed Login for pre-built authentication UIs
    • Amazon Verified Permissions – Scalable, fine-grained authorization using Cedar policy language for custom applications
    • AWS Resource Access Manager (RAM) – Securely share AWS resources across accounts and within AWS Organizations
    • AWS Directory Service – Managed Microsoft Active Directory in the AWS Cloud

    Detection and Response

    • Amazon GuardDuty – Intelligent threat detection that continuously monitors for malicious activity
      • Extended Threat Detection (re:Invent 2024) – AI/ML-powered attack sequence identification across multiple data sources
      • Now covers EC2, ECS, EKS, S3, and IAM attack sequences
      • Custom entity lists for domain-based threat intelligence (Sept 2025)
    • Amazon Detective – Analyze, investigate, and identify root cause of security findings using ML and graph theory
    • Amazon Inspector – Automated vulnerability management for EC2 instances and container images in ECR
    • AWS Security Hub – Cloud security posture management (CSPM) and unified security operations
      • Reimagined at re:Invent 2025 – Unifies GuardDuty, Inspector, and other services into a single experience
      • Near real-time analytics and risk prioritization (GA Dec 2025)
      • Extended Plan (GA Feb 2026) – Full-stack enterprise security with 21 curated partner solutions across 9 categories
      • Expanding to multicloud environments
    • AWS Security Agent (GA March 2026) – AI-powered frontier agent for proactive application security
      • Automated security reviews tailored to organizational requirements
      • On-demand context-aware penetration testing
      • Full repository code scanning (Preview May 2026)
      • Operates like a human penetration tester – identifies, exploits, and validates vulnerabilities

    Data Protection

    Network and Application Protection

    • AWS WAF – Web application firewall to protect against common web exploits and bots
    • AWS Shield – Managed DDoS protection (Standard and Advanced tiers)
    • AWS Network Firewall – Managed network firewall for VPC with stateful inspection and IPS
    • AWS Firewall Manager – Centrally configure and manage firewall rules across accounts in AWS Organizations

    Security Data Management and Compliance

    • Amazon Security Lake – Centralize security data from AWS, SaaS, on-premises using OCSF standard
      • Achieved FedRAMP High and Moderate authorization (April 2025)
    • AWS Audit Manager – Continuously audit AWS usage for risk and compliance assessment
    • AWS Artifact – On-demand access to AWS security and compliance reports

    Key Updates (2024-2026)

    • MFA Enforcement (2024-2025) – AWS now mandates MFA for all root users across all account types. Prevents over 99% of password-related attacks.
    • AWS Security Hub Reimagined (re:Invent 2025) – Completely redesigned to unify security services into a single experience with near real-time analytics and AI-driven risk prioritization.
    • AWS Security Agent (GA March 2026) – First AI-powered frontier agent for autonomous application security testing and code scanning.
    • GuardDuty Extended Threat Detection (re:Invent 2024) – AI/ML attack sequence identification now covers EC2, ECS, EKS workloads.
    • IAM Identity Center Multi-Region (Feb 2026) – Replicate identity center configuration across multiple AWS Regions for high availability.
    • Amazon Cognito Passwordless (Nov 2024) – Native passkey support with FIDO2/WebAuthn, email OTP, and SMS OTP authentication.
    • Centralized Root Access Management (Nov 2024) – Centrally manage root credentials and perform privileged tasks across AWS Organizations member accounts.
    • Agentic AI Security Framework (2025) – New Agentic AI Security Scoping Matrix for securing autonomous AI systems.

    AWS Certification Relevance

    • Solutions Architect (Associate/Professional) – IAM, VPC security, encryption, Security Hub, GuardDuty
    • Security Specialty – All services in depth, including Security Lake, Detective, Macie, Inspector
    • SysOps Administrator – Security Hub, Config, GuardDuty, IAM best practices
    • Developer Associate – Cognito, IAM roles, KMS, Secrets Manager
    • DevOps Professional – Security automation, Inspector, Security Hub integrations

    AWS EC2 Security

    ~ Last updated on : ~ jayendrapatil ~ 17 Comments

    AWS EC2 Security

    • IAM helps control whether users in the organization can perform a task using specific EC2 API actions and whether they can use specific AWS resources.
    • Use IAM roles to prevent the need to share as well as manage, and rotate the security credentials that the applications use.
    • Security groups act as a virtual firewall that controls the traffic to the EC2 instances. They can help specify rules that control the inbound traffic that’s allowed to reach the instances and the outbound traffic that’s allowed to leave the instance.
    • Use AWS Systems Manager Session Manager to connect to the instance as it provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.
    • Use EC2 Instance Connect to connect to your instances using Secure Shell (SSH) without the need to share and manage SSH keys.
    • Use EC2 Instance Connect Endpoint to connect securely to instances in private subnets without requiring a public IP address, Internet Gateway, or bastion host.
    • Use AWS Systems Manager Run Command to automate common administrative tasks instead of opening inbound SSH ports and managing SSH keys.
    • Use Systems Manager Patch Manager to automate the process of patching, installing security-related updates for both the operating system and applications.
    • Use AWS Verified Access to provide secure, VPN-less, zero-trust access to EC2 instances over SSH, RDP, and other protocols.
    • Enforce IMDSv2 (Instance Metadata Service Version 2) to add defense-in-depth against unauthorized metadata access using session-oriented token-based requests.

    EC2 Key Pairs

    • EC2 uses public-key cryptography to encrypt & decrypt login information
    • Public-key cryptography uses a public key to encrypt a piece of data, such as a password, then the recipient uses the private key to decrypt the data.
    • Public and private keys are known as a key pair.
    • To log in to an EC2 instance, a key pair needs to be created and specified when the instance is launched, and the private key can be used to connect to the instance.
    • Linux instances have no password, and the key pair is used for ssh log in
    • For Windows instances, the key pair can be used to obtain the administrator password and then log in using RDP
    • EC2 stores the public key only, and the private key resides with the user. EC2 doesn’t keep a copy of your private key
    • Public key content (on Linux instances) is placed in an entry within ~/.ssh/authorized_keys at boot time and enables the user to securely access the instance without passwords
    • Public key specified for an instance when launched is also available through its instance metadata http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
    • EC2 Security Best Practice: Store the private keys in a secure place as anyone who possesses the private key can decrypt the login information
    • Also, if the private key is lost, there is no way to recover the same.
      • For instance store, you cannot access the instance
      • For EBS-backed Linux instances, access can be regained.
        • EBS-backed instance can be stopped, its root volume detached and attached to another instance as a data volume
        • Modify the authorized_keys file, move the volume back to the original instance, and restart the instance
    • Key pair associated with the instances can either be
      • Generated by EC2
        • EC2 supports RSA (2048-bit SSH-2) and ED25519 key pair types.
        • ED25519 keys are not supported for Windows instances.
        • Key pairs can be generated in PEM or PPK format.
      • Created separately (using third-party tools) and Imported into EC2
        • EC2 accepts RSA and ED25519 keys for import (does not accept DSA keys)
        • RSA supported lengths: 1024, 2048, and 4096
    • Supports five thousand key pairs per region
    • Key pair management features include viewing creation date and public key material for existing and new key pairs.
    • Deleting a key pair only deletes the public key and does not impact the servers already launched with the key.
    • Use AWS Systems Manager Session Manager to connect to the instance as it provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.

    EC2 Instance Connect

    • EC2 Instance Connect provides a simple and secure way to connect to instances using SSH without the need to share and manage SSH keys.
    • Generates a one-time-use SSH public key and pushes it to the instance metadata, where it remains available for 60 seconds.
    • IAM policies control which users can access and connect to specific instances.
    • All connection requests using EC2 Instance Connect are logged to AWS CloudTrail for auditing.
    • Supports IPv6 connectivity (added Sep 2024), allowing connections to instances with IPv6 addresses.
    • Available at no additional cost.

    EC2 Instance Connect Endpoint

    • EC2 Instance Connect Endpoint (EIC Endpoint), launched in June 2023, allows secure connectivity from the Internet to instances in private subnets.
    • Eliminates the need for an Internet Gateway (IGW) in the VPC, a public IP address on the resource, a bastion host, or any agent to connect to instances.
    • Supports SSH (Linux) and RDP (Windows) connectivity without public IP addresses.
    • Uses IAM-based authentication to establish secure connections.
    • Supports IPv6 connectivity (added Oct 2025) — EIC Endpoints can be configured as dual-stack or IPv6-only.
    • IAM policies can restrict which instances users can connect to through the endpoint.
    • Available at no additional cost.
    • Replaces traditional bastion host architecture for many use cases, reducing operational overhead and attack surface.

    EC2 Security Groups

    • An EC2 instance, when launched, can be associated with one or more security groups, which acts as a virtual firewall that controls the traffic to that instance
    • Security groups help specify rules that control the inbound traffic that’s allowed to reach the instances and the outbound traffic that’s allowed to leave the instance
    • Security groups are associated with network interfaces. Changing an instance’s security groups changes the security groups associated with the primary network interface (eth0)
    • An ENI can be associated with 5 security groups and with 60 inbound and 60 outbound rules per security group (120 total rules per security group)
    • A single network interface cannot have more than 1000 combined rules from all attached Security Groups.
    • Rules for a security group can be modified at any time; the new rules are automatically applied to all instances associated with the security group.
    • All the rules from all associated security groups are evaluated to decide where to allow traffic to an instance
    • Security Group features
      • For the VPC default security group, it allows all inbound traffic from other instances associated with the default security group
      • By default, VPC default security groups or newly created security groups allow all outbound traffic
      • Security group rules are always permissive; deny rules can’t be created
      • Rules can be added and removed any time.
      • Any modification to the rules are automatically applied to the instances associated with the security group after a short period, depending on the connection tracking for the traffic
      • Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. For VPC security groups, this also means that responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules
      • If multiple rules are defined for the same protocol and port, the Most permissive rule is applied for e.g. for multiple rules for tcp and port 22 for specific IP and Everyone, everyone is granted access being the most permissive rule

    Security Group VPC Associations (Oct 2024)

    • Security groups can now be associated with multiple VPCs in the same account and AWS Region using Security Group VPC Associations.
    • Enables enforcing consistent traffic filtering rules for workloads regardless of the VPC.
    • Security groups can be shared with participant accounts using AWS Resource Access Manager (RAM) in shared VPC environments.
    • Cannot share security groups that are in a default VPC.
    • Eliminates the need to duplicate security group rules across multiple VPCs.

    Security Group Referencing across Transit Gateway (Sep 2024)

    • Security group referencing is now supported across VPCs connected by AWS Transit Gateway.
    • Allows creating inbound security rules that reference security groups defined in other VPCs attached to a Transit Gateway within the same Region.
    • Simplifies management and provides better security posture for TGW-based networks.
    • Also supported across AWS Cloud WAN (Jun 2025) for cross-VPC connectivity.

    Related Resources View (Feb 2026)

    • The EC2 and VPC consoles now display a “Related resources” tab for security groups.
    • Provides a consolidated view of all resources that depend on a specific security group.
    • Eliminates the need to manually check multiple services before making security group configuration changes.

    Connection Tracking

    • Security groups are Stateful and they use Connection tracking to track information about traffic to and from the instance.
    • This allows responses to inbound traffic to flow out of the instance regardless of outbound security group rules, and vice versa.
    • Connection Tracking is maintained only if there is no explicit Outbound rule for an Inbound request (and vice versa)
    • However, if there is an explicit Outbound rule for an Inbound request, the response traffic is allowed on the basis of the Outbound rule and not on the Tracking information
    • Any existing flow of traffic, that is tracked, is not interrupted even if the rules for the security groups are changed. To ensure traffic is immediately interrupted, use NACL as they are stateless and therefore do not allow automatic response traffic.
    • Also, If the instance (host A) initiates traffic to host B and uses a protocol other than TCP, UDP, or ICMP, the instance’s firewall only tracks the IP address and protocol number for the purpose of allowing response traffic from host B. If host B initiates traffic to your instance in a separate request within 600 seconds of the original request or response, your instance accepts it regardless of inbound security group rules, because it’s regarded as response traffic.
    • Can be controlled by modifying the security group’s outbound rules to permit only certain types of outbound traffic or using NACL

    Configurable Idle Timeouts (Nov 2023)

    • Idle timeouts for connection tracking are now configurable on a per Elastic Network Interface (ENI) basis.
    • Configurable timeout settings:
      • TCP Established: Min 60 seconds, Max 432,000 seconds (5 days). Default: 432,000 seconds (pre-Nitro v6) or 350 seconds (Nitro v6 instances).
      • UDP Stream: Min 60 seconds, Max 180 seconds. Default: 180 seconds.
      • UDP Unidirectional: Min 30 seconds, Max 60 seconds. Default: 30 seconds.
    • Important (Jun 2025): Sixth-generation Nitro (Nitro v6) instances (c8, r8, etc.) changed the default TCP connection tracking idle timeout from 432,000 seconds (5 days) to 350 seconds. If a TCP connection remains idle for more than 350 seconds, the ENI evicts the session from its tracking table.
    • Applications with long-lived idle connections on Nitro v6 instances should either configure keep-alive mechanisms or adjust the idle timeout setting.

    Instance Metadata Service v2 (IMDSv2)

    • IMDSv2 is an enhancement to the Instance Metadata Service that uses session-oriented token-based requests to add defense-in-depth against unauthorized metadata access.
    • IMDSv2 requires a session token obtained via a PUT request before metadata can be retrieved, protecting against SSRF attacks and unauthorized access.
    • Sessions can last up to six hours and tokens can only be used from the EC2 instance where the session began.
    • Session token PUT requests are blocked if they contain an X-forwarded-for header (mitigates reverse proxy exploitation).
    • IMDSv2 enforcement timeline:
      • Mar 2024: Account-level setting available to set IMDSv2 as default for all new instance launches.
      • Mid-2024: All newly released EC2 instance types require IMDSv2 only (IMDSv1 disabled).
      • AWS Console Quick Starts and other launch pathways default to IMDSv2.
    • Methods to enforce IMDSv2:
      • Set account-level default using ModifyInstanceMetadataDefaults API
      • Set AMI-level property to require IMDSv2
      • Set instance metadata options during launch
      • Use declarative policies via AWS Organizations for multi-account, multi-region enforcement
    • When IMDSv2 is required, IMDSv1 is disabled — applications relying on IMDSv1 will break.
    • Default hop limit is set to 2 when IMDSv2 is required (supports containerized workloads).
    • Best Practice: Enforce IMDSv2 across all instances to prevent credential theft via SSRF attacks

    IAM with EC2

    • IAM policy can be defined to allow or deny a user access to the EC2 resources and actions
    • EC2 partially supports resource-level permissions. For some EC2 API actions, you cannot specify which resource a user is allowed to work with for that action; instead, you have to allow users to work with all resources for that action
    • IAM allows to control only what actions a user can perform on the EC2 resources but cannot be used to grant access for users to be able to access or login to the instances

    EC2 with IAM Role

    • EC2 instances can be launched with IAM roles so that the applications can securely make API requests from your instances.
    • IAM roles prevent the need to share as well as manage, rotate the security credentials that the applications use.
    • IAM role can be added to an existing running EC2 instance.
    • EC2 uses an instance profile as a container for an IAM role.
      • Creation of an IAM role using the console, creates an instance profile automatically and gives it the same name as the role it corresponds to.
      • When using the AWS CLI, API, or an AWS SDK to create a role, the role and instance profile needs to be created as separate actions, and they can be given different names.
      • One role per instance profile (this limit cannot be increased).
    • To launch an instance with an IAM role, the name of its instance profile needs to be specified.
    • An application on the instance can retrieve the security credentials provided by the role from the instance metadata item http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.
    • Security credentials are temporary and are rotated automatically and new credentials are made available at least five minutes prior to the expiration of the old credentials.
    • EC2 IAM role credentials are not subject to maximum session durations configured in the role.
    • Best Practice: Always launch EC2 instance with IAM role instead of hardcoded credentials

    EC2 IAM Role S3 Access

    AWS Verified Access

    • AWS Verified Access provides secure, VPN-less access to corporate applications and resources using zero-trust principles (“never trust, always verify”).
    • Evaluates each access request based on user identity and device health rather than network location.
    • Supports fine-grained access policies using the Cedar policy language.
    • Originally supported HTTP(S) applications only (GA April 2023).
    • Non-HTTP(S) protocol support (GA Feb 2025): Extends zero-trust access to SSH, RDP, JDBC, ODBC, and other TCP protocols.
      • Eliminates the need for VPNs or bastion hosts for SSH/RDP access to EC2 instances.
      • Simplifies security operations by using a single solution for all application types.
    • Integrates with third-party identity providers (IdPs) and device management solutions.
    • All access requests are logged for auditing and compliance.
    • Achieved FedRAMP High and Moderate authorization (Mar 2025).
    • Can be combined with AWS Network Firewall for deep packet inspection.

    EC2 Resiliency

    • EC2 offers the following features to support your data resiliency:
      • Copying AMIs across Regions
      • Copying EBS snapshots across Regions
      • Automating EBS-backed AMIs using Data Lifecycle Manager
      • Automating EBS snapshots using Data Lifecycle Manager
      • Maintaining the health and availability of the fleet using EC2 Auto Scaling
      • Distributing incoming traffic across multiple instances in a single AZ or multiple AZs using Elastic Load Balancing
      • Using Recycle Bin to protect EBS snapshots, EBS-backed AMIs, and EBS Volumes from accidental deletion with configurable retention periods
      • Automatically deleting underlying EBS snapshots when deregistering AMIs (Jun 2025) to simplify cleanup

    AWS Certification Exam Practice Questions

    • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
    • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
    • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
    • Open to further feedback, discussion and correction.
    1. You launch an Amazon EC2 instance without an assigned AWS identity and Access Management (IAM) role. Later, you decide that the instance should be running with an IAM role. Which action must you take in order to have a running Amazon EC2 instance with an IAM role assigned to it?
      1. Create an image of the instance, and register the image with an IAM role assigned and an Amazon EBS volume mapping.
      2. Create a new IAM role with the same permissions as an existing IAM role, and assign it to the running instance. (As per AWS latest enhancement, this is possible now)
      3. Create an image of the instance, add a new IAM role with the same permissions as the desired IAM role, and deregister the image with the new role assigned.
      4. Create an image of the instance, and use this image to launch a new instance with the desired IAM role assigned (This was correct before, as it was not possible to add an IAM role to an existing instance)
    2. What does the following command do with respect to the Amazon EC2 security groups? ec2-revoke RevokeSecurityGroupIngress
      1. Removes one or more security groups from a rule.
      2. Removes one or more security groups from an Amazon EC2 instance.
      3. Removes one or more rules from a security group
      4. Removes a security group from our account.
    3. Which of the following cannot be used in Amazon EC2 to control who has access to specific Amazon EC2 instances?
      1. Security Groups
      2. IAM System
      3. SSH keys
      4. Windows passwords
    4. You must assign each server to at least _____ security group
      1. 3
      2. 2
      3. 4
      4. 1
    5. A company is building software on AWS that requires access to various AWS services. Which configuration should be used to ensure that AWS credentials (i.e., Access Key ID/Secret Access Key combination) are not compromised?
      1. Enable Multi-Factor Authentication for your AWS root account.
      2. Assign an IAM role to the Amazon EC2 instance
      3. Store the AWS Access Key ID/Secret Access Key combination in software comments.
      4. Assign an IAM user to the Amazon EC2 Instance.
    6. Which of the following items are required to allow an application deployed on an EC2 instance to write data to a DynamoDB table? Assume that no security keys are allowed to be stored on the EC2 instance. (Choose 2 answers)
      1. Create an IAM Role that allows write access to the DynamoDB table
      2. Add an IAM Role to a running EC2 instance. (As per AWS latest enhancement, this is possible now)
      3. Create an IAM User that allows write access to the DynamoDB table.
      4. Add an IAM User to a running EC2 instance.
      5. Launch an EC2 Instance with the IAM Role included in the launch configuration (This was correct before, as it was not possible to add an IAM role to an existing instance)
    7. You have an application running on an EC2 Instance, which will allow users to download files from a private S3 bucket using a pre-assigned URL. Before generating the URL the application should verify the existence of the file in S3. How should the application use AWS credentials to access the S3 bucket securely?
      1. Use the AWS account access Keys the application retrieves the credentials from the source code of the application.
      2. Create a IAM user for the application with permissions that allow list access to the S3 bucket launch the instance as the IAM user and retrieve the IAM user’s credentials from the EC2 instance user data.
      3. Create an IAM role for EC2 that allows list access to objects in the S3 bucket. Launch the instance with the role, and retrieve the role’s credentials from the EC2 Instance metadata
      4. Create an IAM user for the application with permissions that allow list access to the S3 bucket. The application retrieves the IAM user credentials from a temporary directory with permissions that allow read access only to the application user.
    8. A user has created an application, which will be hosted on EC2. The application makes calls to DynamoDB to fetch certain data. The application is using the DynamoDB SDK to connect with from the EC2 instance. Which of the below mentioned statements is true with respect to the best practice for security in this scenario?
      1. The user should attach an IAM role with DynamoDB access to the EC2 instance
      2. The user should create an IAM user with DynamoDB access and use its credentials within the application to connect with DynamoDB
      3. The user should create an IAM role, which has EC2 access so that it will allow deploying the application
      4. The user should create an IAM user with DynamoDB and EC2 access. Attach the user with the application so that it does not use the root account credentials
    9. Your application is leveraging IAM Roles for EC2 for accessing object stored in S3. Which two of the following IAM policies control access to you S3 objects.
      1. An IAM trust policy allows the EC2 instance to assume an EC2 instance role.
      2. An IAM access policy allows the EC2 role to access S3 objects
      3. An IAM bucket policy allows the EC2 role to access S3 objects. (Bucket policy is defined with S3 and not with IAM)
      4. An IAM trust policy allows applications running on the EC2 instance to assume as EC2 role (Trust policy allows EC2 instance to assume the role)
      5. An IAM trust policy allows applications running on the EC2 instance to access S3 objects. (Applications can access S3 through EC2 assuming the role)
    10. You have an application running on an EC2 Instance, which will allow users to download files from a private S3 bucket using a pre-assigned URL. Before generating the URL the application should verify the existence of the file in S3. How should the application use AWS credentials to access the S3 bucket securely?
      1. Use the AWS account access Keys the application retrieves the credentials from the source code of the application.
      2. Create a IAM user for the application with permissions that allow list access to the S3 bucket launch the instance as the IAM user and retrieve the IAM user’s credentials from the EC2 instance user data.
      3. Create an IAM role for EC2 that allows list access to objects in the S3 bucket. Launch the instance with the role, and retrieve the role’s credentials from the EC2 Instance metadata
      4. Create an IAM user for the application with permissions that allow list access to the S3 bucket. The application retrieves the IAM user credentials from a temporary directory with permissions that allow read access only to the application user.

    New Practice Questions

    1. A company wants to provide secure SSH access to EC2 instances in private subnets without using bastion hosts, VPNs, or public IP addresses. Which AWS service should they use?
      1. AWS Direct Connect
      2. AWS Site-to-Site VPN
      3. EC2 Instance Connect Endpoint
      4. AWS PrivateLink
    2. A security team wants to protect EC2 instances from credential theft through SSRF (Server-Side Request Forgery) attacks targeting the instance metadata service. Which approach should they implement?
      1. Disable the instance metadata service entirely
      2. Use security groups to block metadata access
      3. Enforce IMDSv2 which requires session tokens for metadata access
      4. Encrypt the metadata service endpoint
    3. An organization uses multiple VPCs within the same account and region and wants to maintain consistent security group rules across all VPCs without duplication. Which feature should they use?
      1. VPC Peering with security group referencing
      2. Security Group VPC Associations
      3. AWS Network Firewall
      4. AWS Config rules
    4. A company is migrating to sixth-generation Nitro (Nitro v6) EC2 instances and experiencing dropped TCP connections for long-running idle workloads. What is the most likely cause?
      1. Security group rules are being modified
      2. Network ACLs are timing out
      3. The default TCP connection tracking idle timeout changed from 432,000 seconds to 350 seconds on Nitro v6 instances
      4. The instance is being stopped by Auto Scaling
    5. A company wants to implement zero-trust access for SSH and RDP connections to EC2 instances, evaluating user identity and device security posture for each request without requiring a VPN. Which AWS service provides this capability?
      1. EC2 Instance Connect Endpoint
      2. AWS Systems Manager Session Manager
      3. AWS Verified Access
      4. AWS Client VPN
    6. Which of the following key pair types are supported for EC2 Linux instances? (Choose 2)
      1. DSA
      2. RSA
      3. ED25519
      4. ECDSA

    AWS Security – Whitepaper – Certification

    ~ Last updated on : ~ jayendrapatil ~ 12 Comments

    AWS Security – Whitepaper – Certification

    📋 Important Update

    The original AWS Security Whitepaper and the “Overview of Security Processes” whitepaper have been archived by AWS and marked as “historical reference only.” AWS now recommends the following current resources:

    The core concepts below remain relevant for AWS certification exams, updated with current information.

    Shared Security Responsibility Model

    In the Shared Security Responsibility Model, AWS is responsible for securing the underlying infrastructure that supports the cloud (“Security of the Cloud”), and you’re responsible for anything you put on the cloud or connect to the cloud (“Security in the Cloud”).

    AWS Security Shared Responsibility Model

    AWS Security Responsibilities (“Security OF the Cloud”)

    • AWS is responsible for protecting the global infrastructure that runs all of the services offered in the AWS cloud. This infrastructure is comprised of the hardware, software, networking, and facilities that run AWS services.
    • AWS provides several reports from third-party auditors who have verified their compliance with a variety of computer security standards and regulations (available via AWS Artifact)
    • AWS is responsible for the security configuration of its products that are considered managed services for e.g. RDS, DynamoDB, Lambda, Fargate
    • For Managed Services, AWS will handle basic security tasks like guest operating system (OS) and database patching, firewall configuration, and disaster recovery.
    • AWS infrastructure is built on the AWS Nitro System, which provides hardware-enforced isolation between instances and prohibits administrative access to customer data.

    Customer Security Responsibilities (“Security IN the Cloud”)

    • AWS Infrastructure as a Service (IaaS) products for e.g. EC2, VPC, S3 are completely under your control and require you to perform all of the necessary security configuration and management tasks.
    • Management of the guest OS (including updates and security patches), any application software or utilities installed on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance
    • For managed services, you are responsible for configuring logical access controls for the resources, protecting account credentials, and encrypting data at rest and in transit as applicable
    • Identity and access management using AWS IAM, including MFA, password policies, IAM roles, and least-privilege access
    • Data encryption at rest and in transit using services like AWS KMS, ACM, and S3 encryption options

    Shared Responsibility Model Variations

    • Infrastructure Services (EC2, EBS, VPC) – Customer manages OS, patching, firewall, encryption
    • Container Services (RDS, ECS, EMR) – AWS manages OS/platform, customer manages access, firewall rules, data encryption
    • Abstract Services (S3, DynamoDB, Lambda, SQS) – AWS manages platform entirely, customer manages data classification, IAM policies, and encryption options

    AWS Global Infrastructure Security

    AWS Nitro System

    • The AWS Nitro System is the underlying platform for all modern EC2 instances, providing hardware-based security isolation
    • Virtualization resources are offloaded to dedicated hardware and software, minimizing the attack surface
    • Nitro System’s security model is locked down and prohibits administrative access, eliminating the possibility of human error and tampering
    • Nitro Isolation Engine (GA 2025 on Graviton5) – The first commercially deployed formally verified hypervisor, providing mathematically proven isolation between virtual machines
    • Nitro Enclaves – Provides isolated compute environments for processing highly sensitive data (e.g., PII, healthcare, financial data) with no persistent storage, interactive access, or external networking

    AWS Compliance Program

    AWS supports 143 security standards and compliance certifications, including:

    • SOC 1, SOC 2, SOC 3 (covering 188 services as of Spring 2026)
    • ISO 9001, ISO 27001:2022, ISO 27017, ISO 27018, ISO 27701, ISO 22301, ISO 20000-1
    • CSA STAR CCM v4.0
    • FedRAMP (High, Moderate)
    • PCI DSS Level 1
    • FIPS 140-3 (upgraded from FIPS 140-2)
    • HIPAA
    • GDPR
    • NIST 800-171 (CMMC 2.0)
    • C5 (Cloud Computing Compliance Criteria Catalogue)
    • ITAR
    • MTCS Level 3
    • IRAP (Australia)

    Compliance reports are available through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports and select online agreements.

    Physical and Environmental Security

    Storage Decommissioning

    • When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals.
    • AWS uses the techniques detailed in NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process.
    • All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.
    • Media that stored customer data is not removed from AWS control until it has been securely decommissioned.

    Network Security

    Amazon Corporate Segregation

    • AWS Production network is segregated from the Amazon Corporate network and requires a separate set of credentials for logical access.
    • Amazon Corporate network relies on user IDs, passwords, and Kerberos, while the AWS Production network requires SSH public-key authentication through a bastion host.

    Network Monitoring & Protection

    AWS utilizes a wide variety of automated monitoring systems to provide a high level of service performance and availability. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts. The tools have the ability to set custom performance metrics thresholds for unusual activity.

    AWS network provides protection against traditional network security issues:

    1. DDoS – AWS provides AWS Shield Standard (free, automatic L3/L4 DDoS protection for all AWS customers) and AWS Shield Advanced (paid, advanced L3/L4/L7 DDoS protection with 24/7 DDoS Response Team support, DDoS attack flow logs, and cost protection). AWS WAF now includes an Anti-DDoS Managed Rule Group (2025) for automatic application-layer (L7) DDoS mitigation.
    2. Man in the Middle attacks – AWS APIs are available via SSL/TLS-protected endpoints which provide server authentication. AWS Certificate Manager (ACM) provides free public SSL/TLS certificates.
    3. IP spoofing – AWS-controlled, host-based firewall infrastructure will not permit an instance to send traffic with a source IP or MAC address other than its own.
    4. Port Scanning – Unauthorized port scans by Amazon EC2 customers are a violation of the AWS Acceptable Use Policy. When unauthorized port scanning is detected by AWS, it is stopped and blocked.
    5. Packet Sniffing by other tenants – It is not possible for a virtual instance running in promiscuous mode to receive or “sniff” traffic that is intended for a different virtual instance. The Nitro System hypervisor will not deliver any traffic to them that is not addressed to them. Even two virtual instances that are owned by the same customer located on the same physical host cannot listen to each other’s traffic.

    Penetration Testing

    Updated Policy: AWS no longer requires prior approval for penetration testing on the following permitted services:

    • Amazon EC2 instances, WAF, NAT Gateways, and Elastic Load Balancers
    • Amazon RDS
    • Amazon CloudFront
    • Amazon Aurora
    • Amazon API Gateway
    • AWS Lambda and Lambda@Edge functions
    • Amazon Lightsail
    • AWS Elastic Beanstalk

    Prohibited Activities (still require AWS approval): DNS zone walking, DoS/DDoS attacks, port flooding, protocol flooding, request flooding.

    Secure Design Principles

    • Secure software development best practices, which include formal design reviews by the AWS Security Team, threat modeling, and completion of a risk assessment
    • Static code analysis tools are run as a part of the standard build process
    • Recurring penetration testing performed by carefully selected industry experts
    • AWS Nitro System hardware-level isolation with formally verified components
    • Secure by Design principles documented in the 2024 AWS whitepaper “Building Security from the Ground Up”

    AWS Account Security Features

    AWS account security features include credentials for access control, HTTPS endpoints for encrypted data transmission, the creation of separate IAM user accounts, user activity logging for security monitoring, and Trusted Advisor security checks.

    AWS Credentials

    AWS IAM Credentials

    Individual User Accounts

    Do not use the Root account; instead create an IAM User for each user (or use AWS IAM Identity Center, formerly AWS SSO, for centralized workforce identity management) and provide them with a unique set of credentials with least-privilege access required to perform their job function.

    Secure HTTPS Access Points

    Use HTTPS (TLS 1.2 minimum, TLS 1.3 recommended), provided by all AWS services, for data transmissions, which uses public-key cryptography to prevent eavesdropping, tampering, and forgery.

    Security Logs

    Use Amazon CloudTrail which provides logs of all requests for AWS resources within the account and captures information about every API call to every AWS resource you use, including sign-in events. CloudTrail logs can be sent to Amazon S3, CloudWatch Logs, or analyzed through Amazon Security Lake.

    Trusted Advisor Security Checks

    Use AWS Trusted Advisor which inspects your AWS environment and provides recommendations for cost optimization, performance, security, fault tolerance, service limits, and operational excellence. Security checks include open ports, MFA on root account, exposed access keys, and IAM usage.

    AWS Security Services

    AWS provides a comprehensive suite of security services that complement the infrastructure security:

    Threat Detection & Monitoring

    • Amazon GuardDuty – Intelligent threat detection service that continuously monitors for malicious activity and unauthorized behavior. Features Extended Threat Detection (2024) using AI/ML to identify attack sequences.
    • AWS Security Hub – Centralized security posture management with near real-time risk analytics (GA Dec 2025). Unifies GuardDuty, Inspector, Macie, and IAM Access Analyzer findings. Extended plan (2026) offers full-stack enterprise security.
    • Amazon Detective – Analyzes and visualizes security data to investigate potential security issues and identify root cause.
    • AWS CloudTrail – Records API calls and account activity for governance, compliance, operational auditing, and risk auditing.

    Identity & Access Management

    • AWS IAM – Manage access to AWS services and resources securely with users, groups, roles, and policies.
    • AWS IAM Identity Center (formerly AWS SSO) – Centrally manage workforce access to multiple AWS accounts and applications.
    • IAM Access Analyzer – Identifies external access, internal access, and unused access to your resources. Generates least-privilege policies based on CloudTrail activity.

    Data Protection

    • AWS KMS – Create and manage encryption keys for data encryption across AWS services.
    • AWS CloudHSM – Hardware security modules for regulatory compliance requirements.
    • Amazon Macie – Uses machine learning to discover and protect sensitive data in S3.
    • AWS Certificate Manager (ACM) – Provision, manage, and deploy public and private SSL/TLS certificates.

    Network & Application Protection

    • AWS WAF – Web application firewall to protect against common web exploits with Anti-DDoS Managed Rule Group.
    • AWS Shield – Standard (free) and Advanced DDoS protection.
    • AWS Network Firewall – Managed network firewall for VPC traffic filtering.
    • AWS Firewall Manager – Centrally configure and manage firewall rules across accounts.

    Compliance & Governance

    • AWS Artifact – On-demand access to AWS compliance reports (SOC, ISO, PCI, etc.).
    • AWS Config – Assess, audit, and evaluate configurations of AWS resources.
    • AWS Audit Manager – Continuously audit AWS usage to simplify risk and compliance assessment.

    AWS Certification Exam Practice Questions

    • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
    • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
    • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
    • Open to further feedback, discussion and correction.
    1. In the shared security model, AWS is responsible for which of the following security best practices (check all that apply) :
      1. Penetration testing
      2. Operating system account security management (User responsibility)
      3. Threat modeling
      4. User group access management (User responsibility)
      5. Static code analysis (AWS development cycle responsibility)
    2. You are running a web-application on AWS consisting of the following components an Elastic Load Balancer (ELB) an Auto-Scaling Group of EC2 instances running Linux/PHP/Apache, and Relational DataBase Service (RDS) MySQL. Which security measures fall into AWS’s responsibility?
      1. Protect the EC2 instances against unsolicited access by enforcing the principle of least-privilege access (User responsibility)
      2. Protect against IP spoofing or packet sniffing
      3. Assure all communication between EC2 instances and ELB is encrypted (User responsibility)
      4. Install latest security patches on ELB, RDS and EC2 instances (User responsibility for EC2 OS patches; AWS responsibility for ELB and RDS platform patches)
    3. In AWS, which security aspects are the customer’s responsibility? Choose 4 answers
      1. Controlling physical access to compute resources (AWS responsibility)
      2. Patch management on the EC2 instances operating system
      3. Encryption of EBS (Elastic Block Storage) volumes
      4. Life-cycle management of IAM credentials
      5. Decommissioning storage devices (AWS responsibility)
      6. Security Group and ACL (Access Control List) settings
    4. Per the AWS Acceptable Use Policy, penetration testing of EC2 instances:
      1. May be performed by AWS, and will be performed by AWS upon customer request.
      2. May be performed by AWS, and is periodically performed by AWS.
      3. Are expressly prohibited under all circumstances.
      4. May be performed by the customer on their own instances without prior authorization from AWS.
      5. May be performed by the customer on their own instances, only if performed from EC2 instances

      Note: AWS updated their penetration testing policy — prior approval is no longer required for permitted services including EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, and Elastic Beanstalk. DoS/DDoS testing still requires approval.

    5. Which is an operational process performed by AWS for data security?
      1. AES-256 encryption of data stored on any shared storage device (User responsibility)
      2. Decommissioning of storage devices using industry-standard practices
      3. Background virus scans of EBS volumes and EBS snapshots (No virus scan is performed by AWS on User instances)
      4. Replication of data across multiple AWS Regions (AWS does not replicate data across regions unless done by User)
      5. Secure wiping of EBS data when an EBS volume is unmounted (data is not wiped off on EBS volume when unmounted and it can be remounted on other EC2 instance)
    6. Which AWS service provides on-demand access to AWS compliance reports such as SOC and ISO certifications?
      1. AWS Trusted Advisor
      2. AWS Config
      3. AWS Artifact
      4. Amazon Inspector
    7. Which of the following is a key security feature of the AWS Nitro System? (Select TWO)
      1. No administrative access to customer data is possible
      2. Automatic patching of customer operating systems
      3. Hardware-enforced isolation between instances
      4. Automatic encryption of all EBS volumes
      5. Built-in antivirus protection
    8. A company wants to centrally view and manage security findings across multiple AWS accounts. Which service should they use?
      1. Amazon GuardDuty
      2. AWS Security Hub
      3. AWS CloudTrail
      4. Amazon Detective
    9. Which AWS service provides intelligent threat detection by continuously monitoring for malicious activity using AI/ML?
      1. AWS WAF
      2. AWS Shield
      3. Amazon GuardDuty
      4. AWS Config
    10. Under the Shared Responsibility Model, for Amazon RDS, which of the following is the customer’s responsibility? (Select TWO)
      1. Patching the database engine (AWS responsibility for managed services)
      2. Managing database user accounts and permissions
      3. Physical security of the underlying hardware (AWS responsibility)
      4. Configuring Security Groups to control network access
      5. Replacing failed storage hardware (AWS responsibility)

    References