AWS Account Governance

AWS Organizations

AWS Organizations – Overview

• Multi-account management service
  • Consists of 1 management (master) account and 0 or more member accounts
  • Useful when managing multiple accounts: simplifies IAM user management and payment handling

Key Benefits

• SwitchRole feature → seamless switching between accounts without logging out/in
• Centralized permissions management → use Service Control Policies (SCPs) attached to Organizational Units (OUs)
• Consolidated billing → one monthly bill for all accounts
• Aggregated usage discounts → benefit from combined service usage
• Automated account creation → e.g., via API

Limitation

• Free Tier usage is aggregated across accounts → you do not get Free Tier benefits for each account individually

Creating an AWS Organization

1. Start from a standard AWS account
   • Standard account = not yet part of any AWS Organization
   • Log in, create an organization → this account becomes the management account
2. Add member accounts
   • Invite existing accounts → standard account must accept invitation
   • Create new accounts directly inside the organization

Switching Roles in AWS Organizations

• OrganizationAccountAccessRole → IAM role inside a member account granting admin access to the management account
  • Created by default for newly created member accounts
  • Must be manually created if adding a previously standard account
• Using Switch Role:
  • From the management account console, click “Switch Role” and follow the wizard
  • Assign an alias (e.g., PROD, DEV) to track which account/role is active
  • Role switching is seamless and stored in the browser for convenience

Best Practices for Identity Administration:

1. Centralize logins:
   • Single account for IAM users, or
   • Identity Federation with external IDPs (e.g., Microsoft Active Directory)
2. Access other accounts via roles using Switch Role

Hierarchical Structure of AWS Organizations

• Organizational Units (OUs) can contain accounts or other OUs
• Organization Root = top-level OU (not to be confused with root user of management account)
• Nested structure allows complex hierarchies
• SCPs attached to an OU control permissions for all accounts under it
• Management account may or may not belong to an OU

Cost Benefits of AWS Organizations

1. Consolidated Billing
   • Member accounts’ bills are combined → one monthly invoice for the organization
   • Payer account = management account
2. Volume Discounts
   • Aggregated usage can reduce costs
3. Consolidated Reservations
   • Reserved instances can be shared across member accounts

DEMO: Creating an AWS Organization

1. Log in to GENERAL account, create an organization → GENERAL becomes the management account
2. Add existing PROD account
   • Invite PROD to join, PROD accepts → becomes member account
3. Add new DEV account
   • Create inside GENERAL → DEV becomes member account
   • Note: Increase AWS Organization account quota if needed: Service Quotas
4. OrganizationAccountAccessRole
   • Create in PROD to grant admin access to GENERAL
   • DEV role created automatically (since DEV was created inside the organization)
5. Switch Roles Feature
   • From GENERAL account, main menu → Switch Roles → fill in account, role name, alias (e.g., PROD = red, DEV = yellow)

• Role history stored in browser → switch seamlessly between accounts

Service Control Policies (SCPs)

AWS Organizations – Service Control Policies (SCP)

• An SCP is a JSON policy that defines permission limits for member accounts within an organization
  • It does not grant permissions, but instead controls the maximum permissions that can be assigned
  • It acts as an account-level permission boundary
• Important characteristics:
  • The management account is not affected by SCPs
    • Best practice: avoid using the management account for routine operations in production environments
• SCPs can indirectly limit the root user of a member account
  • While the root user cannot be restricted within its own account, SCPs apply at the organization level and therefore affect all identities in the account, including the root user.

SCP Scope and Attachment

An SCP can be applied to:

1. Organization Root → impacts all member accounts in the organization (excluding the management account)
2. Organizational Units (OUs) → affects the OU and all nested accounts and OUs
   • SCPs are inherited downward through the hierarchy
3. Individual member accounts

Default Behavior

• By default, SCPs do not impose restrictions.
• When SCPs are enabled, a FullAWSAccess policy is attached across the organization
• If this policy is removed:
  • The implicit deny model applies, effectively blocking all actions unless explicitly allowed by SCPs.

SCP Design Approaches

1. Allow List (Block by Default)

• Remove the default FullAWSAccess policy
• Define SCPs that explicitly allow only specific services or actions
• Advantages:
  • Stronger security control
• Disadvantages:
  • Higher risk of misconfiguration
  • Increased administrative effort
  • Requires updates whenever new AWS services are needed

2. Deny List (Allow by Default)

• Keep the default FullAWSAccess policy
• Add SCPs that explicitly deny specific services or actions
• Advantages:
  • Easier to manage
  • Lower administrative overhead
  • New AWS services are automatically allowed
• Disadvantages:
  • Broader access by default, which may reduce security
• This approach is commonly recommended for most environments

Overlap Between Identity/Resource Policies and SCPs

• SCPs must align with IAM identity policies and/or resource policies for access to be granted.
  • Permissions are effectively determined by the intersection of all applicable policies.
  • Access is only allowed if it is permitted by both the SCP and the identity/resource policies.
• SCPs do not grant permissions on their own.
  • For example, even if an SCP allows access to S3, an identity still cannot access it unless:
    • An IAM policy also allows the action, and/or
    • The resource policy (e.g., S3 bucket policy) permits it.
  • If either side does not allow the action, access is denied.
• SCPs follow the same evaluation logic as IAM policies:
  • Implicit Deny < Explicit Allow < Explicit Deny.
  • When combined with identity and resource policies, this evaluation model still applies across all policies.

Amazon CloudWatch (CW) 101

Amazon CloudWatch – Architecture and Key Components

• Gathers and processes operational information → enables monitoring and operational visibility
  • Operational information includes performance data, metrics, logs, and more
  • Acts as a foundational service leveraged by most AWS services
  • Available as a public AWS service
• Primary components include:

1. CloudWatch Metrics = the core CloudWatch functionality
   • Example: tracking EC2 CPU usage over time or disk usage from on-prem systems
   • Accepts metrics from AWS services, applications, and external environments
   • Certain metrics are automatically collected by AWS services
   • A CloudWatch Agent is required when:
     • Capturing metrics not provided by default within AWS
       • e.g., application-level or OS-level metrics inside an EC2 instance
     • Collecting metrics from non-AWS environments
   • Due to the large volume of metrics, proper organization and separation is important
2. CloudWatch Logs
   • Ingests logs from AWS services, applications, and on-premises systems
   • Some logs are automatically generated by AWS services, while others require the CloudWatch Agent
3. CloudWatch Alarms
   • Initiates alerts or automated actions based on metric thresholds
   • Can send notifications via Amazon SNS
   • Example: trigger an alert when EC2 CPU usage exceeds 90%
   • Billing alerts can also be configured to notify via email when costs exceed a defined threshold
4. CloudWatch Events (now replaced by Amazon EventBridge)
   • Integrates with AWS services and scheduled workflows
   • Produces events that can initiate actions (e.g., sending notifications)
   • Events can be triggered by:
     1. State changes (e.g., EC2 instance launch or termination)
     2. Scheduled timing (e.g., specific time or recurring intervals)

Amazon CloudWatch – Core Concepts

Diagram 1:

• Datapoint = Value + Timestamp pair
  • Example: CPU utilization is 98.3% at 08:45:45 on 2019-12-03
• Metric = A time-ordered collection of datapoints
  • Represents values tracked over time (e.g., CPU usage, network I/O, disk activity)
  • Metrics are not always tied to a single resource
    • For example, CPU utilization may by default represent all EC2 instances combined
    • You must apply filters to view data for a specific instance

Diagram 2:

Namespace = Logical container for related metrics

• Helps organize monitoring data and avoid confusion
• Names must follow AWS naming rules
• Example:
  • AWS/ → general namespace for AWS metrics
  • AWS/EC2 → dedicated namespace for EC2-related metrics

Dimensions = Attributes used to filter and segment a metric

• Allow the same metric to be viewed from different perspectives
• Example: Within the AWS/EC2 namespace, metrics can be separated by Instance ID (Instance A, Instance B, etc.)
• Provides high flexibility and granularity

Diagram 3:

• Alarms take actions based on a specific metric reaching specified values/thresholds
  • e.g., Send a notification when the budget has been exceeded (billing alarm)
  • States:INSUFFICIENT DATA (initial state), OK or ALARM
    • alarm uses Amazon SNS (Simple Notification System) when the state is ALARM

CloudWatch Logs

CloudWatch Logs – Overview

• Used to collect, store, and analyze log data
  • A log entry = timestamp + message content (YYYY-MM-DD::HH:MM:SS message)
    • Example: 2025-02-03::13:40:35 "User signed in"
• Public, region-based service
  • Can be accessed from AWS environments, on-premises systems, or other cloud platforms
• Natively integrated with multiple AWS services (e.g., EC2, VPC Flow Logs, Lambda, CloudTrail)
  • Access control is typically handled through IAM roles or service-linked roles
  • Many AWS services automatically push standard logs to CloudWatch Logs
• CloudWatch Unified Agent
  • A software agent used to send custom logs to CloudWatch from various sources
  • Required for:
    • External (non-AWS) systems to forward logs to CloudWatch
    • Custom application or OS-level logs from EC2 instances
  • Alternative method: use the AWS SDK within application code to send logs directly
  • The Unified Agent is the enhanced and current version of the older CloudWatch Logs Agent

CloudWatch Logs – Architecture

Log sources: AWS services, mobile applications, databases, external APIs, and non-AWS compute systems

• These sources send log events (timestamp + message) into CloudWatch Logs

Log Stream = Ordered sequence of log events from a single source

• Each stream represents logs coming from one specific origin

Log Group = Collection of related log streams

• Aggregates logs from multiple sources of the same type (e.g., several EC2 instances)
• Holds configuration settings for its streams (such as retention policies and access permissions)
• Defines metric filters, which can be used to generate metrics and trigger alarms

Example scenario:

• A fleet of EC2 instances sends /var/log/messages (Linux system logs) to CloudWatch Logs
• A single log group contains all /var/log/messages across those instances
• Each log stream corresponds to one EC2 instance
• Each stream stores its instance’s log events in time order

AWS CloudTrail

AWS CloudTrail (CT) – Overview

• Records API activity and events within an AWS account
  • Examples include launching EC2 instances, deleting S3 buckets, or modifying security groups
  • These actions are captured as CloudTrail Events, representing operations performed by users or services
  • Commonly used for auditing API activity, troubleshooting issues, and security investigations

Types of CloudTrail Events

1. Management Events
   • Represent control plane actions (resource management operations)
     • Examples: creating an EC2 instance, deleting an S3 bucket, setting up a VPC
   • Enabled by default
     • The first copy is free, while additional copies incur charges
2. Data Events
   • Represent data plane operations (interactions within a resource)
     • Examples: uploading objects to S3 or invoking a Lambda function
   • Disabled by default due to the potentially high volume of activity
     • For instance, frequent access to an S3 bucket can generate many events
3. Insight Events(less relevant for SAA-C03)
   • Detect unusual patterns or anomalies in account activity

• By default, CloudTrail stores events in the Event History, which retains data for up to 90 days
  • To persist logs in services like S3 or CloudWatch, a trail must be configured
• Not a real-time service
  • Events are delivered with a delay of up to ~15 minutes, as they are processed in batches multiple times per hour

AWS CloudTrail – Trail

• Trail = The main configuration unit in CloudTrail
  • Determines where and how CloudTrail events are recorded

Types of Trails

1. Single-region trail
   • Records events only within the region where it is created
   • Reminder: CloudTrail is a regional service
2. All-region trail
   • Captures events across all AWS regions
   • Technically, a collection of per-region trails, managed as one logical trail
   • Automatically updated when AWS adds new regions
3. Organizational trail
   • Logs events from all accounts in an AWS Organization across all regions
   • Also, a collection of per-account, per-region trails, managed as one logical entity

Global Services

• Some services (e.g., IAM, STS, CloudFront) are global
  • Their events are always logged in us-east-1 (N. Virginia)
  • A CloudTrail trail must enable global service logging to capture these events
    • Typically enabled by default if created via the AWS console

Trail Outputs

• Apart from the default CloudTrail Event History, trails can store logs in:
  1. Amazon S3 – logs formatted in JSON; durable and convenient for storage
  2. CloudWatch Logs – enables metric filters and alarms; more functionality than S3
• Key retention points:
  • Event History: limited to 90 days
  • S3 and CloudWatch Logs: can be stored indefinitely

AWS CloudTrail – Pricing

• Basic CloudTrail service (enabled by default)
  • Stores 90 days of management event history in CloudTrail Event History
  • Free of charge
  • No need to create a trail for this basic functionality
  • To use advanced features (e.g., custom trails, logging to S3/CloudWatch), you must create one or more trails, which incurs additional costs

Additional Costs

1. Management events
   • First copy in all regions is included in the free basic service
   • Extra copies cost $2 per 100,000 events
2. Data events
   • Charged at $0.10 per 100,000 events
   • Typically, much higher in volume than management events
   • No free allowance – charged from the first event

AWS Control Tower 101

AWS Control Tower – Key Concepts

• Service that automates the setup and governance of multi-account AWS environments
  • Orchestrates core services like AWS Organizations, IAM Identity Center (formerly AWS SSO), CloudFormation, and AWS Config
  • Think of it as AWS Organizations with superpowers

Control Tower Dashboard

• Provides a single-page overview of the entire AWS environment
  • Centralized visibility for monitoring accounts, OUs, and compliance

Control Tower Landing Zone

• A well-architected multi-account environment
  • Created automatically when an account enables Control Tower (takes <1 hour)
  • That account becomes the management account
• Home region
  • The region where the Control Tower is initialized
  • Guaranteed to be available; other regions are not automatically covered
• Centralized Identity Management via IAM Identity Center
  • Provides Single Sign-On (SSO) for users
  • Supports internal identities, cross-account identities, and federated identities
• Centralized Logging & Auditing
  • Uses AWS Config, CloudTrail, and CloudWatch to track compliance and activity
• Default Architecture Built by Control Tower:
  1. Security OU
     • Log Archive Account: Aggregates all logs from the environment
     • Audit Account: For 3rd-party auditing and security operations
  2. Custom OU (Sandbox)
     • Flexible security rules for testing or experimentation
     • Typically, where additional accounts are provisioned via Account Factory

AWS Control Tower – Guardrails

• Predefined rules for multi-account governance
  • Detect or enforce compliance across all accounts
  • Helps prevent accounts from drifting away from best practices

• Types of Guardrails:
  1. Mandatory – must be applied in all accounts
  2. Strongly Recommended – suggested, but can be overridden in rare cases
  3. Elective – optional, applied based on organizational needs
• Modes of Operation:
  1. Preventive – blocks non-compliant actions
     • Implemented via AWS Organizations Service Control Policies (SCPs)
     • States: enforced or not enabled
     • Example: restrict deployments to certain regions, enforce bucket policies
  2. Detective – observes compliance without preventing actions
     • Implemented via AWS Config rules
     • States: clear, in violation, or not enabled
     • Can log violations/events to CloudTrail
     • Example: detect if CloudTrail is enabled in an account, or if EC2 instances have public IPv4 addresses
  3. Proactive – checks compliance before resources are provisioned
     • Validates resources via CloudFormation templates
     • Prevents creation of resources that would violate guardrails

AWS Control Tower – Account Factory

• Automates and standardizes account creation and provisioning
  • Supports both long-term and temporary accounts
  • Accounts can be provisioned by cloud admins or end-users (self-service)
    • End-users typically provision through AWS Service Catalog, using pre-approved stacks
• Automatic application of guardrails to new accounts
• Standardized templates/blueprints ensure consistent account and network setup:
  • Account creator receives admin permissions
  • Configured IP addressing avoids overlaps across accounts
  • Predefined business-specific configurations
• Lifecycle management: accounts can be provisioned, closed, or repurposed
  • Fully integratable with SDLC using APIs, SDKs, IaC, and CI/CD pipelines