AWS: Securing and Monitoring

Table of Contents

• Module 1: Amazon CloudWatch
  • Amazon CloudWatch Overview
  • Amazon CloudWatch Logs
  • Custom Logging with the CloudWatch Logs Agent
  • Amazon CloudWatch Metrics
  • Demo - Capture Logs and Metrics in Amazon CloudWatch
  • Amazon CloudWatch Alarms
  • Demo - Trigger Actions Using Amazon CloudWatch Alarms
  • Amazon CloudWatch Insights
  • Module 1 Summary and Exam Tips
• Module 2: Miscellaneous Logging and Monitoring Services
  • Amazon Managed Service for Prometheus
  • Amazon Managed Grafana
  • Module 2 Summary and Exam Tips
• Module 3: AWS Organizations and Multi-account Architectures
  • Multi-account Architectures Introduction
  • AWS Organizations Overview
  • Important AWS Organizations Features
  • AWS Organizations Service Control Policies (SCPs)
  • Demo - Creating an Organization
  • AWS Control Tower Overview
  • AWS Resource Access Manager (RAM)
  • Demo - Sharing Organizational Resources with AWS RAM
  • Module 3 Summary and Exam Tips
• Module 4: Account Security and Governance
  • AWS CloudTrail Overview
  • CloudTrail Trails
  • Demo - Creating an AWS CloudTrail Trail
  • AWS Config Overview
  • AWS Config Rules and Remediations
  • Demo - Recording Resource Compliance with AWS Config
  • AWS Trusted Advisor
  • Amazon Inspector
  • Amazon GuardDuty
  • Amazon Macie
  • AWS Security Hub
  • AWS Audit Manager
  • AWS Artifact
  • Module 4 Summary and Exam Tips
• Module 5: Infrastructure and Application Security
  • AWS Certificate Manager (ACM) Overview
  • ACM Public TLS Certs
  • Demo - Issuing a Public TLS Cert with ACM
  • AWS Key Management Service (KMS) Overview
  • AWS KMS Keys
  • AWS KMS Key Policies
  • AWS KMS Multi-region Keys
  • AWS CloudHSM
  • Demo - Encrypting Data with AWS KMS Keys
  • AWS Secrets Manager
  • Demo - Managing Secrets Using AWS Secrets Manager
  • Module 5 Summary and Exam Tips
• Module 6: Network Security
  • AWS Shield and Shield Advanced
  • AWS Web Application Firewall (WAF)
  • Demo - Protecting Resources with AWS WAF
  • AWS Network Firewall
  • AWS Firewall Manager
  • Module 6 Summary and Exam Tips
• Module 7: Cost and Budgeting Services
  • AWS Cost Explorer
  • AWS Budgets
  • Demo - Creating an AWS Budget
  • AWS Cost and Usage Reports (CUR)
  • AWS Cost Anomaly Detection
  • AWS License Manager
  • Module 7 Summary and Exam Tips

Module 1: Amazon CloudWatch

Amazon CloudWatch Overview

Amazon CloudWatch at the highest level is a monitoring and observability platform that is designed to give you many different ways to gain insights of your AWS architectures and the applications that they are running. It is made up of several different tool sets and features that allow you to monitor multiple levels of your applications, so if it is multi-tiered, etc, and it helps you quickly identify potential issues that might be occurring, as well as ways you might be able to optimize your workloads.

Features covered throughout this module include:

• Different ways and different types of metrics you can collect, including system metrics and application metrics
• Collecting logs and log files
• How to use the service to trigger alarms
• How to leverage Insights features provided within CloudWatch

Important: CloudWatch is the service to consider for most things related to monitoring and logging in the AWS cloud. Unless there is a very specific reason not to choose this service, this is likely the one you are going to want.

graph TD
    A[Amazon CloudWatch] --> B[Logs]
    A --> C[Metrics]
    A --> D[Alarms]
    A --> E[Insights]
    B --> B1[Log Events]
    B --> B2[Log Streams]
    B --> B3[Log Groups]
    C --> C1[Default Metrics]
    C --> C2[Custom Metrics]
    D --> D1[Standard Alarms]
    D --> D2[Composite Alarms]
    E --> E1[Logs Insights]
    E --> E2[Container Insights]
    E --> E3[Lambda Insights]
    E --> E4[Contributor Insights]
    E --> E5[Application Insights]

Amazon CloudWatch Logs

We now know what CloudWatch is at a high level. Let us start looking at how we can use the different services and features within it to better our architecture design. First thing we are going to look at is using it to collect our log files.

Consider this scenario: you just deployed your brand-new application to AWS, and you think you have followed all of the best practices, and everything seems to be running appropriately. Within your applications and your systems, you start generating a lot of logs because your user base has really grown tremendously. So now you have:

• EC2 logs where your apps are hosted
• RDS hosting your database, so there are logs coming from RDS as well
• Lambda integrated for some event-driven APIs
• CloudTrail logs for security
• On-prem architecture generating on-prem logs

That is a lot of different logs to keep track of. So how can you centralize those and be more efficient with how you manage them? That is where Amazon CloudWatch Logs comes in.

What CloudWatch Logs provides:

• Monitor, store, and access your log files from a variety of different sources
• Ability to query your logs to easily look for potential issues and data that is relevant and specific to your needs
• Logs are encrypted by default
• If you need to customize the encryption of specific logs, you can use KMS keys to accomplish that
• You can encrypt different log groups containing different logs for different applications however you see fit

Log Destinations:

In addition to centralizing the management of your log files, there are scenarios where you need to send logs to other destinations to analyze, parse, etc. Supported destinations include:

• Amazon S3
• Kinesis Data Streams
• Amazon Data Firehose
• AWS Lambda functions
• OpenSearch clusters and domains

Key CloudWatch Logs Terms

graph LR
    A[Log Event\nTimestamp + Raw Message] -->|Multiple events| B[Log Stream\nSequence from same source]
    B -->|Multiple streams| C[Log Group\nShared retention, monitoring, and access control]
    C -->|Export/Subscribe| D[Destinations\nS3 / Kinesis / Firehose / Lambda / OpenSearch]

Log Event

This is exactly what it sounds like — the events in the record of what actually happened within your application or the AWS service that is generating the log file. Within your events, it is going to have timestamps and raw event messages, including any custom logging events that you might have coded, such as INFO, WARN, ERROR, etc.

Log Stream

A log stream is the collection and sequence of your events from that same source. The easiest way to think of a stream is one continuous set of logs from a single Apache web server instance or maybe the same Lambda function after an initial cold start. Think of it as a stream of events — a stream of logs from a single source.

Log Group

This is the collection of log streams with the same retention, monitoring, and access control settings, such as IAM permissions and encryption. An example for a log group would be grouping all of your Apache web server logs across all hosts together in the same group. The high-level log group is “Apache web server logs,” and then each stream is specific to an instance ID.

Log Retention

When you are configuring your log groups, your log streams, etc., you have to set a log retention setting. CloudWatch Logs allows you to set a customized retention setting for each log group. You use this to set up what your expiration would be. Options range from:

• 1 day
• 7 days
• Up to 10 years
• Never expire

Log Sources

The following are the important services and sources you have to know for this exam:

• AWS SDKs
• CloudWatch Agent (Unified Agent)
• Lambda function logs
• VPC Flow Logs
• Amazon API Gateway
• AWS CloudTrail trails
• Route 53 DNS query logs
• Elastic Beanstalk application and environment logs
• ECS containers

Log Subscription Filters

Sometimes you are going to have scenarios on the exam where you need to send your logs to another destination — not just CloudWatch — because you want to perform actions on those logs. That is where log subscription filters come in.

A subscription filter is a feature that gives you real-time feeds of log events from CloudWatch Logs, and you can have them delivered to other services and locations for both actions and even long-term storage.

Natively supported destinations:

• Kinesis Data Streams
• AWS Lambda functions
• Amazon Data Firehose
• Amazon OpenSearch Service

When you are using your subscription filters, you use a filter pattern which allows you to set which log events you actually want to have delivered to your AWS downstream resources. These log events get sent to the configured downstream resource very soon after being ingested.

Subscription filter scope:

• Account level: One account-level subscription filter per region
• Log group level: Up to two subscription filters per log group

Exporting Logs to Amazon S3

In addition to subscription filters, you can also export logs to Amazon S3 buckets. You would do this if you want to export a lot of logs to your bucket for some type of custom processing or maybe long-term cold archive storage.

• The buckets that you are using can be in the same account or they can be cross-account
• The logs can actually take up to 12 hours to become available before they actually get exported
• This is NOT even close to real time or near real time
• Log groups are regional resources

Custom Logging with the CloudWatch Logs Agent

The default behavior for custom application logs generated by your applications running on your EC2 instances is for them NOT to get sent to CloudWatch Logs automatically. So it is not like Lambda functions or built-in ECS logging. But you can customize this behavior — that is exactly what the CloudWatch Agent does.

What the agent allows you to do:

• Collect detailed EC2 system-level metrics
• Collect system-level metrics from on-prem servers or servers in another cloud
• Retrieve custom metrics from StatsD and collectd services
• Collect logs from EC2, on-prem servers, or external servers in another cloud, and send them to CloudWatch

Exam tip: If you are going to use this agent, you must configure proper IAM permissions for the agent to push to CloudWatch Logs.

Two Versions of the Agent

Original CloudWatch Agent (Deprecated)

• The original version
• More limited support of the logs and metrics that you can collect
• More limited destinations you can send them to
• This version has been deprecated

Unified CloudWatch Agent (Recommended)

• The newer, recommended version
• Can collect additional system-level metrics from Linux and Windows servers that you install it on
• Collects memory utilization metrics (which is NOT a default metric — you must push it as a custom metric using this agent)
• Exposes a lot more configuration options and potential destinations for your logs
• Always use the unified agent over the original CloudWatch agent

Configuring the Unified CloudWatch Agent

Once you have installed the agent, you can configure it using either of the following methods:

The Wizard: A pretty easy setup process because it walks you through the different options step by step.

AWS Systems Manager Parameter Store: You can store your configuration file in Parameter Store, and that gives you the ability to deploy to multiple instances that all read from the same config. This is extremely powerful for scale.

Amazon CloudWatch Metrics

By default, CloudWatch has built-in metrics natively for a lot of services. For example, EC2 has built-in CPU utilization as a metric. In addition to using all of these default metrics, you can always push custom metrics to CloudWatch as well — using either the AWS CLI or through the SDKs available for various programming languages.

Important Default EC2 Metrics

Important: Memory utilization is NOT a default EC2 metric. You must push it as a custom metric using the CloudWatch Unified Agent.

Metric Resolution

• Standard resolution: 1-minute intervals (default)
• High resolution: As frequently as every 1 second

Data retention schedule:

Metric Math

Metric math allows you to use mathematical expressions on multiple CloudWatch metrics to create new time series and visualizations. You can also look at metrics as an aggregate across a bunch of resources using metric aggregation. This is useful when you want to see the big picture.

Custom Metrics

When pushing custom metrics, you must provide:

• Namespace: A container for your metrics (e.g., MyApp/Performance)
• Metric name: The name of the metric (e.g., MemoryUsage)
• Value: The data point value
• Dimensions (optional): Key-value pairs that categorize your metrics (e.g., per instance, per service)

Demo - Capture Logs and Metrics in Amazon CloudWatch

This demo covers installing the CloudWatch Agent on an EC2 instance via User Data, configuring it, and collecting both logs and custom metrics.

Step 1: Install the CloudWatch Agent via User Data

#!/bin/bash
sudo yum update
sudo yum install amazon-cloudwatch-agent -y

Step 2: Run the CloudWatch Agent Configuration Wizard

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

When prompted for a log file to monitor, specify:

/opt/application.log

Step 3: Start the Agent Using Your Config File

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

Step 4: Create a Bash Script to Generate Log Entries

#!/bin/bash
# Ensure the log file exists
LOG_FILE="/opt/application.log"
touch $LOG_FILE

# Function to generate random text
generate_random_text() {
    RANDOM_TEXT=$(shuf -n 10 /usr/share/dict/words | tr '\n' ' ')
    echo $RANDOM_TEXT
}

# Append random text to the log file in loop
x=1
while [ $x -le 5 ]; do
    echo "$(date "+%Y-%m-%d %H:%M:%S") - $(generate_random_text)" >>$LOG_FILE
    x=$(($x + 1))
done
echo "Random text has been appended to $LOG_FILE"

Step 5: CloudWatch Agent Configuration File (config.json)

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "cwagent"
    },
    "metrics": {
        "aggregation_dimensions": [["InstanceId"]],
        "append_dimensions": {
            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "metrics_collected": {
            "cpu": {
                "measurement": [
                    "cpu_usage_idle",
                    "cpu_usage_iowait",
                    "cpu_usage_user",
                    "cpu_usage_system"
                ],
                "metrics_collection_interval": 60,
                "resources": ["*"],
                "totalcpu": false
            },
            "disk": {
                "measurement": ["used_percent", "inodes_free"],
                "metrics_collection_interval": 60,
                "resources": ["*"]
            },
            "mem": {
                "measurement": ["mem_used_percent"],
                "metrics_collection_interval": 60
            },
            "swap": {
                "measurement": ["swap_used_percent"],
                "metrics_collection_interval": 60
            }
        }
    }
}

Amazon CloudWatch Alarms

We talked about collecting logs and metrics in CloudWatch. Now let us look at what we can actually do with that data by setting up CloudWatch Alarms. A CloudWatch Alarm is a feature that allows you to watch a metric over a specified time period. When the metric crosses the threshold you define, the alarm changes state, and you can trigger actions based on those states.

Alarm States

Alarm Configuration

When configuring an alarm, you need to specify:

• The metric to watch
• A period (how long to evaluate the metric)
• The threshold value
• The number of evaluation periods
• What to do when the alarm triggers (the action)

Actions You Can Take When an Alarm Fires

• Send a notification via Amazon SNS
• Trigger an EC2 action: stop, terminate, reboot, or recover an instance
• Trigger an Auto Scaling action: scale in or scale out
• Invoke a Lambda function (through SNS)

Composite Alarms

A composite alarm is an alarm that combines multiple alarms together using logical operators (AND and OR). This is extremely useful because it can reduce alarm noise.

For example, you might only want to fire an alarm if BOTH CPU is high AND network errors are occurring simultaneously, rather than each individually. Composite alarms help you reduce the number of actions being taken unnecessarily.

graph TD
    A[Composite Alarm] -->|AND / OR| B[Alarm: High CPU]
    A -->|AND / OR| C[Alarm: High Network Errors]
    A -->|AND / OR| D[Alarm: Disk Full]
    A -->|triggers| E[Action: SNS Notification]
    A -->|triggers| F[Action: Auto Scaling]
    B -->|monitors| G[EC2 CPU Metric]
    C -->|monitors| H[Network Error Metric]
    D -->|monitors| I[Disk Usage Metric]

Demo - Trigger Actions Using Amazon CloudWatch Alarms

In this demo, a CloudWatch Alarm is set up that triggers a Lambda function through an SNS topic when CPU utilization exceeds 70%.

Simulating High CPU Load for Testing

stress --cpu 2

Lambda Function That Logs the CloudWatch Alarm Event

import logging

def lambda_handler(event, context):
    # Create a logger
    logger = logging.getLogger()
    # Set the log level
    logger.setLevel(logging.INFO)
    
    # Log the received event
    logger.info("Event: %s", event)
    logger.warning("This is a WARNING message.")
    logger.critical("This is a CRITICAL message.")
    
    # Return a response
    return {
        'statusCode': 200,
        'body': 'Event logged successfully!'
    }

Architecture

graph LR
    A[EC2 Instance] -->|CPU Metric| B[CloudWatch\nMonitors CPU]
    B -->|Threshold Breached| C[CloudWatch Alarm\nCPU > 70%]
    C -->|Publishes| D[SNS Topic]
    D -->|Invokes| E[Lambda Function]
    E -->|Logs Event| F[CloudWatch Logs]

Amazon CloudWatch Insights

In addition to alarms, CloudWatch also provides several powerful Insights features that are built in.

CloudWatch Logs Insights

This is an interactive query and analysis tool. You can query your CloudWatch Logs in real time using a specific query language that is provided. CloudWatch Logs Insights allows you to:

• Query and analyze your log data interactively
• Create visualizations — for example, if you see a spike in errors and you want to visualize that as a graph
• Run ad hoc queries against your logs

Container Insights

Designed specifically for ECS, EKS, and Kubernetes clusters. It collects, aggregates, and summarizes metrics and logs from your containerized applications. It gives you detailed visibility into things like CPU, memory, disk, and network usage at the task, pod, and container level.

Lambda Insights

Similar to Container Insights but specifically for Lambda functions. It collects system-level metrics for your Lambda invocations, including:

• Memory, CPU, network, and disk usage
• Diagnostic information like cold starts and Lambda worker shutdowns

Lambda Insights works by using a Lambda layer added to your functions.

Contributor Insights

This feature allows you to analyze log data and create time series that display contributor data. This helps you understand who or what is contributing the most to metrics. For example:

• Identify the top IP addresses making the most requests to your API
• Identify which users are causing the most errors

You create rules that match log data and define what you consider a “contributor.”

Application Insights

A slightly more advanced feature that helps you monitor application health. It automatically detects and sets up monitoring for your .NET and SQL Server workloads. It identifies potential problems and creates CloudWatch alarms and dashboards.

Module 1 Summary and Exam Tips

Key takeaways from this module on Amazon CloudWatch:

• CloudWatch is the primary service for monitoring and observability in AWS
• CloudWatch Logs structure: Log Events → Log Streams → Log Groups
• Log retention is configurable per log group (1 day to never expire)
• Log groups are regional resources
• Log sources include: CloudWatch Agent, Lambda, VPC Flow Logs, API Gateway, CloudTrail, Route 53, Elastic Beanstalk, ECS
• Log subscription filters send real-time data to: Kinesis Data Streams, Lambda, Data Firehose, OpenSearch
• S3 exports can take up to 12 hours — this is NOT real-time
• The Unified CloudWatch Agent is recommended over the original; it requires IAM permissions
• Memory metrics are NOT built-in for EC2 — you must use the CloudWatch agent to push them as custom metrics
• CloudWatch Alarm states: OK, ALARM, INSUFFICIENT_DATA
• Composite Alarms combine multiple alarms using AND/OR logic to reduce alarm noise
• CloudWatch Insights includes: Logs Insights, Container Insights, Lambda Insights, Contributor Insights, Application Insights

Module 2: Miscellaneous Logging and Monitoring Services

Amazon Managed Service for Prometheus

Amazon Managed Service for Prometheus is a serverless Prometheus-compatible service offered by AWS that is meant to be used for securely monitoring container metrics at scale.

Key characteristics:

• AWS manages automatic scaling based on ingestion, storage, and the amount of queries that are going on for your metrics
• AWS replicates all of your data across three Availability Zones within the same region — it is highly available, durable, and redundant
• Data that gets stored is retained in a workspace for 150 days before it is gone
• Uses PromQL (Prometheus Query Language) to explore and extract data for your metrics

Exam tips:

• If you see anything related to PromQL query language for interacting with metrics, that is an immediate indicator of this service
• If you see anything related to requiring leveraging the open-source Prometheus monitoring systems and some type of time series database for metrics, this is a great service to consider
• Commonly used to set up advanced monitoring of your EKS clusters or your self-managed Kubernetes clusters

Common use cases:

• Advanced monitoring of EKS clusters
• Monitoring self-managed Kubernetes clusters
• Container metrics at scale where serverless management is preferred

Amazon Managed Grafana

Amazon Managed Grafana is a fully managed AWS service specific to the Grafana technology. AWS handles the scaling, setup, and maintenance of all your workspaces related to this service.

What it does:

• Secures your data visualizations so you can instantly query, correlate, and visualize operational metrics, logs, and application traces from all of your different sources
• A workspace in terms of Amazon Managed Grafana is a logical Grafana server, and it allows you to separate your data visualizations and your querying tasks

Integrations — it integrates with many different sources including:

• Amazon CloudWatch
• Amazon Managed Service for Prometheus
• Amazon OpenSearch Service
• Amazon Timestream

Use cases:

1. Container and Kubernetes monitoring: Connect to data sources like EKS, ECS, or your own Kubernetes cluster metrics
2. Internet of Things (IoT): A perfect fit for monitoring IoT and edge device data
3. Troubleshooting: Centralizing dashboards for all of your metrics and analytics

Module 2 Summary and Exam Tips

Key takeaways from this module:

• Both Prometheus and Grafana are managed services — you offload infrastructure management like high availability and automatic scaling to AWS
• Amazon Managed Grafana allows you to use several built-in data sources including CloudWatch, Managed Service for Prometheus, and AWS X-Ray
• Amazon Managed Service for Prometheus is the serverless Prometheus-compatible service for securely monitoring primarily container metrics at scale
• With both of these services, you can leverage VPC endpoints for secure VPC access
• PromQL is a dead giveaway for Amazon Managed Service for Prometheus — keep an eye out for it on the exam

Module 3: AWS Organizations and Multi-account Architectures

Multi-account Architectures Introduction

Multi-account architectures are considered a critical design strategy for customers in AWS based on the Well-Architected Framework. Approaches could include:

• Having an account per environment (dev, UAT, prod)
• Separate accounts per department (HR, billing, security operations)

graph TD
    A[AWS Organization] --> B[Management Account]
    A --> C[Root OU]
    C --> D[Security OU]
    C --> E[Development OU]
    C --> F[Production OU]
    C --> G[Sandbox OU]
    D --> D1[Security Account]
    D --> D2[Audit Account]
    D --> D3[Log Archive Account]
    E --> E1[Dev Account]
    E --> E2[UAT Account]
    F --> F1[Prod Account - App]
    F --> F2[Prod Account - DB]
    G --> G1[Experimentation Account]

Design benefits:

1. Stricter controls for security and compliance — allows you to get more granular in an easier way to control what is going on within those accounts
2. Workload isolation and reduced blast radius — if something goes wrong in dev, it does not necessarily impact prod
3. Billing separation — easily separate bills to see exactly what is being spent by whom
4. Optimized Well-Architected Framework adherence

The go-to solution for managing multiple accounts at scale is AWS Organizations.

AWS Organizations Overview

AWS Organizations is a free governance tool and service that allows you to create and manage multiple AWS accounts, all from a single location.

Key concepts:

• Management account (also called the payer account): The main account when you spin up a new organization; it pays the bills for all member accounts
• Member accounts: Other accounts that are part of the org and are NOT the management account; member accounts can only belong to a single organization
• Organizational Unit (OU): A logical grouping used to organize and manage member accounts
• Root OU: The default OU always immediately available when you create a brand-new org; the root OU encompasses everything — all other OUs are nested in it, and all accounts fall underneath it

OU nesting:

You can create OUs for different areas — for example, a Security OU, a Dev OU, a Production OU, etc. You can nest OUs within each other up to five levels deep.

Key features of AWS Organizations:

• Consolidated billing: All accounts can be managed under a single bill; enables volume pricing discounts and Reserved Instance sharing across accounts
• Service Control Policies (SCPs): IAM-like policies that can be applied to OUs or individual accounts to restrict what services and actions can be used
• AWS CloudTrail: You can enable organizational trails that log API activity across all accounts
• Resource sharing: Share services across accounts using AWS Resource Access Manager (RAM)

Important AWS Organizations Features

Consolidated Billing

All of the accounts that are part of your organization can be grouped into a single bill paid by the management account. Any account that joins an org is going to have their bills charged to the management account.

Additional benefits:

• Because you are pooling all of your usage, you can get better pricing benefits through volume discounts (e.g., S3 storage tiers, EC2 usage)
• You can share Reserved Instances and Savings Plans across accounts in the org

Tag Policies

Tag Policies allow you to enforce consistent tagging across your AWS organization. You can create tag policies that define:

• Required tags
• Allowed values for those tags

This helps with cost allocation, security, and compliance.

AI Services Opt-out Policies

You can control whether AWS can use your content to improve their AI services. This is important for data privacy and compliance reasons.

Backup Policies

You can use these to create and enforce AWS Backup plans across your organization.

AWS Organizations Service Control Policies (SCPs)

Service Control Policies (SCPs) are the most important feature of AWS Organizations for the exam. SCPs are IAM-like policies that you can apply to your OUs and accounts to control what services and actions can be used by the identities in those accounts.

Think of SCPs as guardrails.

Critical characteristics of SCPs:

• SCPs do NOT grant permissions — they only restrict what the maximum permissions can be for everyone in that account or OU
• Even the root user of a member account is restricted by SCPs
• SCPs do NOT affect the management account — they never restrict what the management account can do
• SCPs affect all identities in the member accounts (users, roles, even root)
• SCPs use the same policy language (JSON) as IAM policies
• There is a default SCP called FullAWSAccess that allows all actions — it is applied at the root OU by default
• SCPs work as an AND logic with IAM policies — the effective permission is what is allowed by BOTH the SCP and the IAM policy

graph TD
    A[Root OU\nFullAWSAccess SCP] --> B[Security OU\nDeny Delete CloudTrail SCP]
    A --> C[Dev OU\nDeny Prod Services SCP]
    A --> D[Prod OU\nDeny Risky Actions SCP]
    B --> B1[Audit Account]
    B --> B2[Log Archive Account]
    C --> C1[Dev Account\nEffective = FullAccess AND DenyProdServices]
    D --> D1[Prod Account\nEffective = FullAccess AND DenyRiskyActions]

How SCP evaluation works:

The effective permissions for a user in a member account = (IAM permissions) AND (all SCPs in the OU hierarchy)

Example SCP: Deny Leaving the Organization

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": ["organizations:LeaveOrganization"],
            "Resource": "*",
            "Effect": "Deny"
        }
    ]
}

The aws:PrincipalOrgID Condition Key

The aws:PrincipalOrgID condition key is very useful. You can use this in resource-based policies (like S3 bucket policies) to restrict access to only principals that belong to your organization.

Example: Restrict S3 bucket access to org members only

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutObject",
            "Principal": {"AWS": "*"},
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::central-log-bucket/*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": ["o-aa111bb222"]
                }
            }
        }
    ]
}

Example: Restrict to specific accounts within the org

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutObject",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:root",
                    "arn:aws:iam::444455556666:root"
                ]
            },
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::central-log-bucket/*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": ["o-aa111bb222"]
                }
            }
        }
    ]
}

Demo - Creating an Organization

This demo covered creating an AWS Organization, adding member accounts, creating OUs, and applying SCPs. Key actions performed:

• Created a new AWS Organization from the management account
• Created Organizational Units to group member accounts
• Applied an SCP to a member account to deny leaving the organization
• Verified that the SCP prevents the member account from leaving the org

AWS Control Tower Overview

AWS Control Tower is a service that sits on top of AWS Organizations and automates the setup of a multi-account AWS environment. It is essentially a landing zone provisioning and management service.

What is a landing zone?

A landing zone is a well-architected, multi-account AWS environment that follows AWS best practices. Control Tower helps you set up and govern a secure, compliant, multi-account environment.

Key features:

Landing Zone

A baseline multi-account environment with the following accounts already set up:

• Management account
• Log archive account
• Audit account

Guardrails

High-level rules that provide ongoing governance for your environment. There are two types:

• Preventive guardrails: Implemented as SCPs; prevent certain actions from being taken
• Detective guardrails: Implemented as AWS Config rules; detect non-compliant configurations

Account Factory

A feature that allows you to provision new accounts quickly and in a standardized, compliant way. You define templates and configurations, and new accounts get provisioned with all of those settings applied automatically.

Dashboard

A central dashboard that gives you visibility into the compliance status of all of your accounts and guardrails.

Control Tower makes it much easier to implement the multi-account strategy without having to manually set everything up. It is the recommended way to set up an AWS multi-account environment.

AWS Resource Access Manager (RAM)

AWS Resource Access Manager (RAM) is a service that allows you to share AWS resources with other accounts — both within your AWS Organization and with external accounts you specify. The big idea is: instead of duplicating resources across multiple accounts (which costs more money and is harder to manage), you can share a single resource and let multiple accounts access it.

Resources that can be shared with RAM include:

• VPC subnets (most common exam topic)
• Transit Gateways
• Route 53 Resolver rules
• License Manager configurations
• AWS Glue tables and databases
• And more

Sharing VPC Subnets (Most Common Exam Scenario)

When you share a subnet, other accounts can launch their resources (EC2 instances, RDS databases, etc.) directly into that shared subnet, as if it were their own. This allows multiple accounts to use the same VPC networking infrastructure, which is extremely useful for large organizations.

graph TD
    A[Networking Account\nOwns VPC and Subnets] -->|Shares Subnets via RAM| B[App Team Account A]
    A -->|Shares Subnets via RAM| C[App Team Account B]
    A -->|Shares Transit Gateway via RAM| D[App Team Account C]
    B -->|Launches EC2 in shared subnet| E[Shared VPC Subnet]
    C -->|Launches RDS in shared subnet| E
    D -->|Connects via shared TGW| F[Transit Gateway]

Key points about RAM:

• You can share resources within your organization or with individual accounts outside your org
• When sharing within an org, you can enable the “sharing within your organization” feature in RAM which makes it seamless
• Resource owners share resources — participants can use the shared resources but cannot modify or delete them
• There is no charge for using RAM itself, but charges apply for the shared resources

Example Use Case

A networking team manages a Transit Gateway and VPC subnets. Using RAM, they share those subnets with application teams’ accounts. The app teams launch their EC2 instances into the shared subnets without needing to create and manage their own networking infrastructure.

RAM and Managed Prefix Lists

A managed prefix list is a set of one or more CIDR blocks. You can create and manage these centrally, then share them with RAM so all accounts can use the same maintained list in their security groups and route tables.

Example prefix list for S3 IP ranges:

16.15.192.0/18    west
16.182.0.0/16     east
18.34.0.0/19      south
18.182.0.0/16     north

Demo - Sharing Organizational Resources with AWS RAM

This demo covered sharing a managed prefix list across accounts using AWS RAM. Key points:

• Created a managed prefix list
• Shared it via RAM within the organization
• Demonstrated how member accounts can use the shared prefix list in their VPC security group rules

Module 3 Summary and Exam Tips

Key takeaways from this module on AWS Organizations and multi-account architectures:

• Multi-account architectures provide: security isolation, blast radius reduction, billing separation, compliance
• AWS Organizations is free; it organizes accounts into OUs with a management account at the top
• Member accounts can only belong to one organization
• SCPs are guardrails — they restrict maximum permissions but do NOT grant permissions; they do NOT affect the management account
• The aws:PrincipalOrgID condition key can be used to restrict resource access to org members only
• AWS Control Tower automates landing zone setup with guardrails and account factory
• Guardrails are either preventive (SCPs) or detective (Config rules)
• AWS RAM lets you share resources (especially VPC subnets and Transit Gateways) across accounts
• RAM resource sharing works within your org or with external accounts

Module 4: Account Security and Governance

AWS CloudTrail Overview

AWS CloudTrail is a service within AWS that increases the visibility and the ability to govern your AWS accounts by recording user and resource activity. It works by recording management console actions and service API calls.

Important: CloudTrail is enabled by default for all accounts once they get created, and it cannot be turned off.

What CloudTrail allows you to accomplish:

1. After-the-fact incident investigation — who did it, when it occurred, etc.
2. Near real-time detections of API calls — run event-driven automations once the detections occur
3. Helps maintain regulatory compliance

What CloudTrail records:

• Any action taken by a user, role, or AWS service
• API calls made to AWS services
• Console sign-in events
• Who made the call (principal)
• When (timestamp)
• What action was taken (event name)
• From where (source IP address)
• The response

Types of Events in CloudTrail

Management Events (Control Plane)

Operations that are performed ON AWS resources. Examples:

• Creating an EC2 instance
• Creating an S3 bucket
• Attaching an IAM policy

Management events are logged by default.

Data Events (Data Plane)

Operations performed ON or WITHIN a resource. Examples:

• S3 object-level operations (GetObject, PutObject, DeleteObject)
• Lambda function invocations

Data events are NOT logged by default because they can be extremely high volume.

Insights Events

These detect unusual API call rates or error rates in your account.

Sample CloudTrail Management Event

{
    "eventVersion": "1.10",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDAYSMADEUP7LSCI67",
        "arn": "arn:aws:iam::ACCOUNT_ID_HERE:user/cloud_user",
        "accountId": "ACCOUNT_ID_HERE",
        "accessKeyId": "ACCESSKEYHERE",
        "userName": "cloud_user"
    },
    "eventTime": "2025-03-25T15:15:06Z",
    "eventSource": "sqs.amazonaws.com",
    "eventName": "CreateQueue",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "SOURCE_IP_ADDRESS",
    "requestParameters": {
        "queueName": "MySQSQueue"
    },
    "responseElements": {
        "queueUrl": "https://sqs.us-east-1.amazonaws.com/ACCOUNT_ID_HERE/MySQSQueue"
    },
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "eventCategory": "Management"
}

CloudTrail Trails

A CloudTrail Trail is a configuration that enables CloudTrail to deliver log files to an S3 bucket that you specify. By default, CloudTrail provides 90 days of event history viewable in the console — but a Trail allows you to store logs indefinitely (or as long as you keep the S3 bucket).

Types of Trails

Trail Features

• Logs are delivered to an S3 bucket (encrypted by default with SSE-S3; can use SSE-KMS)
• You can enable log file integrity validation — CloudTrail creates a digest file that can be used to verify that log files have not been tampered with
• You can stream CloudTrail events to CloudWatch Logs for real-time monitoring and alerting
• CloudTrail Lake: A newer feature that is a managed data lake for CloudTrail events, allowing SQL-based querying

S3 Storage Path Structure

When a trail is created, log files are stored in S3 with the following path:

s3://bucket-name/AWSLogs/AccountID/CloudTrail/Region/YYYY/MM/DD/

Demo - Creating an AWS CloudTrail Trail

Steps performed in this demo:

1. Created a CloudTrail trail delivering to an S3 bucket
2. Enabled CloudWatch Logs integration
3. Terminated an EC2 instance using the CLI:

aws ec2 terminate-instances --instance-ids <instance_id>

4. Queried CloudTrail logs using Amazon Athena

Creating an External Table in Athena for CloudTrail Logs:

CREATE EXTERNAL TABLE cloudtrail_logs (
eventversion STRING,
userIdentity STRUCT<
  type:STRING,
  principalid:STRING,
  arn:STRING,
  accountid:STRING,
  invokedby:STRING,
  accesskeyid:STRING,
  userName:STRING,
  sessioncontext:STRUCT<
    attributes:STRUCT<
      mfaauthenticated:STRING,
      creationdate:STRING>,
    sessionIssuer:STRUCT<
      type:STRING,
      principalId:STRING,
      arn:STRING,
      accountId:STRING,
      userName:STRING>>>,
eventTime STRING,
eventSource STRING,
eventName STRING,
awsRegion STRING,
sourceIpAddress STRING,
userAgent STRING,
errorCode STRING,
errorMessage STRING,
requestParameters STRING,
responseElements STRING,
additionalEventData STRING,
requestId STRING,
eventId STRING,
resources ARRAY<STRUCT<
  ARN:STRING,accountId:STRING,type:STRING>>,
eventType STRING,
apiVersion STRING,
readOnly STRING,
recipientAccountId STRING,
serviceEventDetails STRING,
sharedEventID STRING,
vpcEndpointId STRING
)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://<Your CloudTrail s3 bucket>/AWSLogs/<AWS_Account_ID>/';

Querying CloudTrail Data in Athena:

-- Find all console login events
SELECT useridentity.username, sourceipaddress, eventtime, additionaleventdata  
FROM cloudtrail_logs   
WHERE eventname = 'ConsoleLogin';

-- Get all events for a specific user
SELECT *
FROM cloudtrail_logs
WHERE useridentity.arn = 'arn:aws:iam::AWS_Account_ID:user/limited_user';

AWS Config Overview

AWS Config is a service that provides you with a detailed view of the configuration of AWS resources in your account and how they have changed over time. It continuously monitors and records your AWS resource configurations and allows you to automate evaluation of recorded configurations against desired configurations. Think of it as a configuration recorder with compliance assessment capabilities.

Key concepts:

What AWS Config tracks:

• Resource configuration changes
• Relationships between resources
• Resource compliance
• Before and after configuration when a change occurs
• Who made the change and when

Important: AWS Config is region-specific. You must enable it in each region you want to monitor. However, you can use aggregators to collect data from multiple accounts and regions.

AWS Config Rules and Remediations

AWS Config Rules allow you to evaluate the configurations of your AWS resources. A rule represents your desired configuration settings. Config continuously evaluates your resource configurations against the rules. If a resource violates a rule, Config marks it as noncompliant.

Types of Config Rules

AWS Managed Rules

Pre-built rules provided by AWS. Examples include:

• s3-bucket-public-read-prohibited
• ec2-instance-no-public-ip
• iam-password-policy
• encrypted-volumes

Custom Rules

Rules you write yourself using Lambda functions or Guard (AWS’s policy-as-code language).

Rule Trigger Types

Remediations

You can configure automatic remediations for noncompliant resources using AWS Systems Manager Automation documents. For example, if a security group opens port 22 to the public, Config can automatically remediate this by removing that rule.

The automation role trust policy (allows SSM to assume the role for remediation):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Demo - Recording Resource Compliance with AWS Config

This demo covered enabling AWS Config, creating a config rule to check for publicly accessible S3 buckets, and setting up an automatic remediation. Key steps:

1. Enabled AWS Config in a region with a configuration recorder
2. Created an S3 bucket and made it publicly accessible
3. Created a managed config rule: s3-bucket-public-read-prohibited
4. Config evaluated the bucket as noncompliant
5. Set up auto-remediation using the AWS-DisableS3BucketPublicReadWrite automation document
6. The remediation ran automatically and brought the bucket back into compliance

AWS Trusted Advisor

AWS Trusted Advisor is a service that acts like a real-time best-practice advisor for your AWS environment. It continuously analyzes your AWS environment and makes recommendations across five categories.

The Five Categories

Access Levels

• All AWS customers: Get basic checks (a subset of checks for free with the Basic support plan)
• Business and Enterprise Support plans: Get access to ALL Trusted Advisor checks

Important Checks for the Exam

Security:

• Identifies security groups that allow unrestricted access
• S3 buckets with open permissions
• IAM use
• MFA on root account
• Exposed access keys

Cost Optimization:

• Identifies idle EC2 instances
• Underutilized EBS volumes
• Unassociated Elastic IPs
• Reserved Instance optimization opportunities

Performance:

• Identifies EC2 instances with high utilization
• Inefficient EBS configuration

Fault Tolerance:

• EBS snapshots age
• Auto Scaling groups
• Multi-AZ RDS

Service Limits:

• Warns when you are approaching service quotas

Advanced Features

Trusted Advisor Priority: A feature for Enterprise support customers that highlights the most important recommendations based on the potential impact.

Trusted Advisor Organizational View: Available for Organizations — allows you to view Trusted Advisor checks across all accounts in your organization from a central location.

Amazon Inspector

Amazon Inspector is an automated vulnerability management service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure. It is focused on finding vulnerabilities in your workloads, not just compliance issues.

What Inspector Scans

EC2 instances:

• Scans for OS vulnerabilities (CVEs) and network exposure issues
• Does this using the SSM agent (Systems Manager agent), which must be installed on the instances

Amazon ECR container images:

• Scans container images stored in ECR for software vulnerabilities

Lambda functions:

• Scans Lambda function code and dependencies for software vulnerabilities

How Inspector Works

• Uses the Common Vulnerabilities and Exposures (CVE) database and other sources to identify vulnerabilities
• Provides a risk score for each finding, helping you prioritize what to fix first
• Inspector findings are automatically sent to AWS Security Hub
• Can also send findings to Amazon EventBridge for automation

Key Exam Points

• Inspector is for vulnerability scanning of EC2, ECR, and Lambda
• It requires the SSM agent on EC2 instances
• It is continuously running — not a one-time scan

Amazon GuardDuty

Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation. It is an intelligent threat detection service powered by machine learning.

What GuardDuty Analyzes

• AWS CloudTrail event logs (management events and data events for S3 and Lambda)
• VPC Flow Logs (network traffic information)
• DNS logs (domain name system query logs from within your VPC)
• Amazon EKS audit logs
• Amazon RDS login events
• Amazon S3 data events
• Amazon ECS runtime monitoring
• Amazon EC2 runtime monitoring

Threats GuardDuty Detects

GuardDuty uses machine learning, anomaly detection, and integrated threat intelligence (from partners like CrowdStrike and Proofpoint) to identify threats such as:

• Cryptocurrency mining activity
• Credential theft and anomalous API calls
• Communication with known malicious IP addresses or domains
• Data exfiltration behaviors
• Unusual EC2 or IAM activity

Multi-account GuardDuty

For multi-account scenarios, you can designate a delegated administrator account for GuardDuty across your organization, allowing centralized management of findings from all accounts.

Key Exam Points

• GuardDuty = threat detection using ML
• Analyzes CloudTrail, VPC Flow Logs, and DNS logs
• Does NOT require you to install any agents (except for runtime monitoring features)
• Findings can trigger automated responses via EventBridge
• Findings are sent to the GuardDuty console and can be sent to CloudWatch Events (EventBridge)

Amazon Macie

Amazon Macie is a data security service that uses machine learning to automatically discover, classify, and protect sensitive data in Amazon S3. It is specifically focused on S3 and sensitive data discovery.

What Macie Does

• Automatically discovers S3 buckets in your account
• Identifies and classifies sensitive data like:
  • PII (Personally Identifiable Information)
  • Financial data (credit card numbers)
  • Credentials
  • Other sensitive content
• Continuously monitors S3 for data security and access control issues
• Generates findings for sensitive data discovered and security issues

Macie Findings

Sensitive data findings: When Macie discovers sensitive data in an S3 object.

Policy findings: When S3 bucket policies or settings change in a way that might reduce security (like making a bucket public).

Key Exam Points

• Macie = S3 data discovery and PII detection using ML
• It is specifically for S3
• Generates findings that can be sent to Security Hub and EventBridge

AWS Security Hub

AWS Security Hub is a cloud security posture management service that performs security best practice checks, aggregates alerts, and enables automated remediation. Think of it as the central place to view all of your security findings from multiple AWS security services.

Services That Integrate with Security Hub

• Amazon GuardDuty
• Amazon Inspector
• Amazon Macie
• AWS Firewall Manager
• AWS IAM Access Analyzer
• AWS Systems Manager Patch Manager
• Third-party partner solutions

Security Standards

Security Hub uses security standards to run automated compliance checks:

• AWS Foundational Security Best Practices
• CIS AWS Foundations Benchmark
• PCI DSS (Payment Card Industry Data Security Standard)
• NIST SP 800-53

Key Exam Points

• Security Hub = centralized security findings aggregation from multiple services
• It requires enabling in each region
• It can be the delegated administrator for security across an organization
• Think of it as the “single pane of glass” for AWS security

AWS Audit Manager

AWS Audit Manager is a service that helps you continuously audit your AWS usage to simplify how you assess risk and compliance with regulations and industry standards. It automates the collection of evidence to help you prepare for audits.

Compliance Frameworks Supported

• GDPR (General Data Protection Regulation)
• HIPAA (Health Insurance Portability and Accountability Act)
• SOC 2 (Service Organization Control 2)
• PCI DSS
• NIST Cybersecurity Framework
• FedRAMP

How It Works

You select a framework, and Audit Manager automatically:

1. Collects evidence (Config snapshots, CloudTrail logs, Security Hub findings)
2. Maps it to the framework controls
3. Stores the evidence in a report that auditors can review

Key Exam Points

• Audit Manager = automated evidence collection for compliance audits
• It maps AWS evidence to common frameworks
• It helps reduce the manual effort of audit preparation

AWS Artifact

AWS Artifact is a self-service portal that provides on-demand access to AWS compliance reports and AWS agreements. It is not a monitoring or security tool — it is a documentation portal.

What You Get from Artifact

AWS compliance reports:

• SOC 1, SOC 2, SOC 3 reports
• PCI DSS attestation
• ISO certifications
• FedRAMP authorizations
• And many more

AWS agreements:

• Business Associate Agreement (BAA) for HIPAA compliance
• Non-Disclosure Agreement (NDA)

Key Exam Points

• Artifact = compliance documentation and agreements
• If you need to prove AWS is compliant or sign a BAA for HIPAA, use Artifact
• It is NOT a tool that scans your environment — it gives you AWS’s own compliance documentation

Module 4 Summary and Exam Tips

Key takeaways from this module on account security and governance:

Module 5: Infrastructure and Application Security

AWS Certificate Manager (ACM) Overview

ACM is the go-to service in AWS that allows you to create, manage, and deploy both public and private TLS certificates with AWS services. It removes a lot of the manual processes that go along with issuing certs, and it enables you to issue your own certs with just a few clicks or automated API calls.

ACM Integrations

ACM commonly integrates with:

• Elastic Load Balancing (Classic, Network, and Application Load Balancers)
• CloudFront distributions (for securing with a custom domain)
• Amazon API Gateway (both regional and edge-optimized)

Important note: ACM cannot directly associate TLS certificates with EC2 instances. For EC2, you would need to manually install a certificate. ACM is specifically designed to work with AWS-managed services.

ACM Public TLS Certs

When using ACM for public TLS certificates, there are important things to know:

Public Certificates from ACM

• Public certificates from ACM are free — you do not pay for the certificate itself
• You can request a public certificate for your domain or subdomains
• ACM handles automatic renewal of these certs before they expire

Domain Validation Methods

DNS validation (recommended):

• ACM provides a CNAME record that you add to your DNS
• ACM checks for this record to validate domain ownership
• This is preferred because it allows for automatic renewal

Email validation:

• ACM sends an email to the domain’s registered contact
• Requires manual action to click an approval link

Certificate Types

Critical Regional Requirement

For CloudFront: If you are using ACM with CloudFront, the certificate MUST be created in US East (N. Virginia) region (us-east-1). This is because CloudFront is a global service that uses the us-east-1 region for its certificates.

This is a very common exam question.

For ALB and other regional services: The ACM certificate must be in the SAME region as the service.

Demo - Issuing a Public TLS Cert with ACM

This demo covered requesting a public ACM certificate, setting up DNS validation via Route 53, and then attaching the certificate to an Application Load Balancer listener on port 443.

Key steps:

1. Request public certificate for your domain
2. Choose DNS validation
3. For Route 53 domains, ACM can create the CNAME record automatically
4. Wait for the certificate to be issued (usually a few minutes)
5. Attach certificate to ALB HTTPS listener
6. Test HTTPS access

AWS Key Management Service (KMS) Overview

AWS Key Management Service (KMS) is a managed service that makes it easy for you to create and control the encryption keys used to encrypt your data. It is deeply integrated with most AWS services for encryption at rest. KMS uses Hardware Security Modules (HSMs) under the hood to protect the security of your keys.

Key Benefits

• Centralized key management: Manage all encryption keys in one place
• Integration with AWS services: S3, EBS, RDS, Lambda, Secrets Manager, Parameter Store, CloudTrail, and many more all support KMS encryption
• Audit key usage: All KMS API calls are logged in CloudTrail
• IAM integration: Key access is controlled through IAM policies and key policies

AWS Shared Responsibility Model for KMS: AWS manages the HSM hardware and the KMS infrastructure. You manage your keys, key policies, and who can use the keys.

AWS KMS Keys

There are different types of KMS keys you need to know.

graph TD
    A[KMS Key Types] --> B[AWS Owned Keys\nFully AWS-managed\nInvisible to you]
    A --> C[AWS Managed Keys\nAWS creates and manages\naws/s3, aws/ebs, etc.\nLimited control]
    A --> D[Customer Managed Keys CMKs\nYou create and manage\nFull control over policy\nRotation and administration]
    D --> E[Symmetric\nAES-256\nSame key encrypt/decrypt\nMost common]
    D --> F[Asymmetric\nRSA or ECC\nPublic/Private key pair\nDigital signing]
    D --> G[Key Material Origin]
    G --> G1[KMS-generated]
    G --> G2[External BYOK]
    G --> G3[AWS CloudHSM]

AWS Managed Keys

• Keys that AWS creates and manages on your behalf
• Created automatically when you enable encryption for a service (like S3 default encryption)
• You cannot manage these keys directly — you cannot rotate them on your schedule, you cannot use them in custom key policies
• Identified by names like aws/s3, aws/ebs, etc.

Customer Managed Keys (CMKs)

• Keys that you create and manage yourself
• Full control: define who can use them, who can administer them, enable and disable them, set rotation policies
• Provide the most flexibility and control

AWS Owned Keys

• Keys owned by AWS services and used across multiple accounts
• You do not see them, you do not manage them — completely managed by AWS

Key Types by Cryptographic Algorithm

Symmetric keys:

• AES-256 encryption
• The same key is used to encrypt and decrypt
• Most common type; most AWS services use this

Asymmetric keys:

• RSA or ECC key pairs (public/private keys)
• Used for digital signing or encryption scenarios where you need to share a public key with external parties

Key Material Origin

• KMS-generated: AWS KMS generates the key material
• External: You provide your own key material (BYOK — Bring Your Own Key)
• AWS CloudHSM: Key material generated in your CloudHSM cluster

Automatic Key Rotation

For CMKs, you can enable automatic key rotation:

• KMS will rotate the key material once per year (or on demand for annual+ rotations)
• The key ID stays the same, but the underlying key material changes
• Old key material is retained so that data encrypted with the old version can still be decrypted

AWS KMS Key Policies

Key policies are the primary way to control access to KMS keys. Every KMS key has a key policy. Unlike IAM policies where everything is deny by default, with KMS, the key policy is what gives you access — IAM policies alone are not sufficient for KMS keys.

Default Key Policy Behavior

When you create a KMS key with the default key policy, the root account principal is given full access to the key. This means all IAM users and roles in the account CAN use the key as long as they have IAM permissions as well.

Example: Key Policy with IAM Delegation

The following policy grants full access to the root account (enabling IAM delegation) plus administrative access to cloud_user:

{
    "Id": "key-policy-only-clouduser-and-use-iam",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"},
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:user/cloud_user"},
            "Action": [
                "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*",
                "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*",
                "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource",
                "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion", "kms:RotateKeyOnDemand"
            ],
            "Resource": "*"
        }
    ]
}

Example: Restrict Key Access to ONLY cloud_user (No IAM Delegation)

Warning: Without the root account statement, if you lock yourself out of a key, only AWS Support can help you recover access.

{
    "Id": "key-policy-only-clouduser",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:user/cloud_user"},
            "Action": [
                "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*",
                "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*",
                "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource",
                "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion", "kms:RotateKeyOnDemand"
            ],
            "Resource": "*"
        }
    ]
}

Example: Allowing Another Admin to Use the Key

{
    "Id": "key-policy-anotheradmin",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"},
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:user/cloud_user"},
            "Action": [
                "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*",
                "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*",
                "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource",
                "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion", "kms:RotateKeyOnDemand"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:user/another_admin"},
            "Action": [
                "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*",
                "kms:GenerateDataKey*", "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::ACCOUNT:user/another_admin"},
            "Action": ["kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant"],
            "Resource": "*",
            "Condition": {
                "Bool": {"kms:GrantIsForAWSResource": "true"}
            }
        }
    ]
}

AWS KMS Multi-region Keys

KMS Multi-region Keys allow you to replicate KMS keys across multiple AWS regions. This means you can have the same key material available in different regions, which enables you to encrypt in one region and decrypt in another without having to re-encrypt.

Use Cases for Multi-region Keys

• Global applications that need to encrypt/decrypt data across regions
• Disaster recovery: Replicate keys to another region so you can decrypt data there if needed
• Active-active multi-region deployments

Important Characteristics

• Multi-region keys share the same key ID, key material, and key policies
• They are NOT global — they still have a primary key in one region and replica keys in other regions
• You can promote a replica key to a primary if needed

For the exam: Multi-region keys are useful when you need to encrypt data in one region and decrypt it in another. They are NOT automatically global — you still have to specify which regions get replicas.

AWS CloudHSM

AWS CloudHSM is a cloud-based hardware security module that enables you to easily generate and use your own encryption keys on the AWS Cloud. The key difference from KMS is that with CloudHSM, AWS does NOT have access to your keys. You are the only one who controls the HSM and the keys within it.

KMS vs. CloudHSM Comparison

CloudHSM Use Cases

• You need to maintain sole control over your encryption keys (regulatory requirement)
• You need FIPS 140-2 Level 3 compliance
• You need to use your own key material that AWS should never have access to
• Oracle TDE (Transparent Data Encryption) key storage

CloudHSM runs in your VPC. You can scale out by adding multiple HSM instances for high availability. AWS manages the hardware, but you manage the HSM partition, users, and keys.

For the exam: If you see “sole custody of keys,” “FIPS 140-2 Level 3,” or “AWS cannot access your keys,” think CloudHSM.

Demo - Encrypting Data with AWS KMS Keys

This demo covered creating a customer managed KMS key, applying key policies, and using the key to encrypt/decrypt data. Key steps:

1. Created a customer managed KMS key
2. Applied a key policy with specific administrators
3. Used the key to encrypt an S3 bucket
4. Tested encryption and decryption with the key
5. Modified the key policy to demonstrate access control

AWS Secrets Manager

AWS Secrets Manager is a service that helps you protect access to your applications, services, and IT resources without the upfront cost and maintenance of a secrets management infrastructure. It enables you to rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.

Key Features

Automatic rotation

The biggest differentiator of Secrets Manager. It can automatically rotate secrets on a schedule. For supported databases (RDS, Redshift, DocumentDB, etc.), it can rotate the password and update the database automatically.

Encryption

All secrets are encrypted using KMS keys.

Access control

IAM policies and resource-based policies control who can access secrets.

Versioning

Secrets are versioned, allowing you to access current and previous versions.

Cross-account access

You can share secrets across accounts using resource-based policies.

How Applications Use Secrets Manager

Instead of hardcoding credentials, applications call Secrets Manager to retrieve the current secret value at runtime via the Secrets Manager API or SDK.

Secrets Manager vs. Parameter Store

This is a common exam comparison:

For the exam: If you see “automatic rotation of database credentials,” think Secrets Manager.

Demo - Managing Secrets Using AWS Secrets Manager

This demo covered creating a secret for RDS database credentials, enabling automatic rotation, and retrieving secrets from application code. Key steps:

1. Created a secret for an RDS database
2. Configured automatic rotation (e.g., every 30 days)
3. Secrets Manager created a Lambda function to perform the rotation
4. Demonstrated retrieving the secret value via the console and CLI
5. Showed how to access the secret ARN for use in application code

Module 5 Summary and Exam Tips

Key takeaways from this module on infrastructure and application security:

• ACM: Manages TLS certificates; public certs are free; CloudFront requires certificate in us-east-1; ALB requires cert in same region; cannot attach to EC2 directly
• KMS: Managed key service using HSMs; AWS Managed Keys vs. Customer Managed Keys vs. AWS Owned Keys; symmetric (AES-256) vs. asymmetric keys; key policies are required (not just IAM); all KMS API calls are logged in CloudTrail
• Multi-region KMS keys: Same key material across regions; useful for cross-region encrypt/decrypt; must specify which regions get replicas
• CloudHSM: Customer-managed HSMs; FIPS 140-2 Level 3; AWS cannot access your keys; runs in your VPC; for “sole custody of keys” requirements
• Secrets Manager: Automatic rotation of secrets; encrypted with KMS; best for database credentials; costs per secret per month
• Parameter Store: General config/secret storage; free tier; no auto-rotation built-in; requires Lambda for rotation

Module 6: Network Security

AWS Shield and Shield Advanced

AWS Shield is a managed DDoS (Distributed Denial of Service) protection service. There are two tiers.

graph TD
    A[AWS Shield] --> B[Shield Standard\nFree for all AWS customers]
    A --> C[Shield Advanced\n$3000/month/org]
    B --> B1[L3/L4 DDoS Protection]
    B --> B2[Automatic - no config needed]
    B --> B3[SYN/UDP floods\nReflection attacks]
    C --> C1[L3/L4/L7 Protection]
    C --> C2[DDoS Response Team\n24/7 access]
    C --> C3[Financial protection\nagainst DDoS scaling costs]
    C --> C4[Integrates with WAF\nat no extra cost]
    C --> C5[Near real-time\nattack visibility]
    C --> C6[Auto L7 mitigation\nwith CloudFront or ALB]

AWS Shield Standard

• Free for all AWS customers
• Automatically protects against common network and transport layer DDoS attacks (Layer 3 and Layer 4)
• Protects resources at the perimeter of your application network
• Applied automatically — no configuration needed
• Provides protection against common attack types like SYN/UDP floods and reflection attacks

AWS Shield Advanced

• Costs $3,000 per month per organization (plus data transfer fees)
• Provides enhanced DDoS protection for:
  • EC2
  • Elastic Load Balancing
  • CloudFront
  • Global Accelerator
  • Route 53
• Includes 24/7 access to the AWS DDoS Response Team (DRT)
• Provides near real-time visibility into DDoS attacks
• Integrates with AWS WAF at no additional cost
• Provides financial protection against DDoS-related scaling costs (AWS credits you for costs incurred due to DDoS scaling)
• Advanced monitoring and detection capabilities using application-layer (Layer 7) traffic analysis
• Automatic application layer DDoS mitigation when associated with CloudFront or ALB

Key exam distinction: Shield Standard = free, basic L3/L4 protection; Shield Advanced = paid, comprehensive protection with DRT access and Layer 7 protection.

AWS Web Application Firewall (WAF)

AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests forwarded to your protected web resources. It allows you to define rules to block, allow, or count requests based on conditions you define.

Resources That WAF Can Protect

• Amazon CloudFront distributions
• Application Load Balancers
• Amazon API Gateway REST APIs
• AWS AppSync GraphQL APIs
• Amazon Cognito user pools

WAF Components

Types of WAF Rules

AWS Managed Rules: Pre-built rule groups maintained by AWS. Examples:

• AWSManagedRulesCommonRuleSet
• AWSManagedRulesKnownBadInputsRuleSet
• AWSManagedRulesSQLiRuleSet

AWS Marketplace Rules: Third-party managed rule groups from security vendors.

Custom Rules: Rules you define yourself.

Rule Conditions You Can Match On

• IP address or IP range
• Geographic location (country)
• String or regex patterns in request headers, body, URI, query string
• SQL injection attacks
• Cross-site scripting (XSS) attacks
• Request size constraints
• Rate-based rules (e.g., limit requests per 5-minute window from a single IP)

Rate-based Rules

Rate-based rules are important for the exam. They let you automatically block IPs that exceed a request rate threshold. For example: more than 1,000 requests per 5 minutes from a single IP.

This is great for protecting against HTTP flood attacks.

Demo - Protecting Resources with AWS WAF

This demo covered creating a Web ACL, attaching it to an Application Load Balancer, and testing rules. Key steps:

1. Created a Web ACL for the regional scope (ALB)
2. Added an AWS Managed Rule Group (Common Rule Set)
3. Added a custom IP-based block rule
4. Added a rate-based rule to limit requests per IP
5. Associated the Web ACL with the ALB
6. Tested the rules by sending requests and observing blocks

AWS Network Firewall

AWS Network Firewall is a managed, stateful network firewall and intrusion prevention system (IPS) service for your VPC. It provides deep packet inspection and network traffic filtering at the VPC level. It is more powerful than security groups and NACLs.

Key Features

• Stateful inspection: Tracks connection state; can allow return traffic automatically
• Deep packet inspection: Can inspect the content of network packets
• Intrusion prevention: Can detect and block known threats using Suricata-compatible rules
• Web filtering: Can filter traffic based on domain names (FQDNs), URLs
• Centralized management: Can be deployed in a centralized VPC (inspection VPC) using Transit Gateway

Deployment

AWS Network Firewall is deployed into specific VPC subnets (dedicated firewall subnets) in each AZ. Traffic is routed through the firewall endpoint using VPC routing.

Network Firewall Rule Types

For the exam: Network Firewall is for VPC-level deep packet inspection and IPS; it is more powerful than security groups/NACLs; it uses Suricata-compatible rules.

AWS Firewall Manager

AWS Firewall Manager is a security management service that allows you to centrally configure and manage firewall rules across your accounts and applications in AWS Organizations. It simplifies your WAF, Shield Advanced, and Network Firewall management.

What Firewall Manager Can Centrally Manage

• AWS WAF rules (Web ACLs)
• AWS Shield Advanced protections
• Amazon VPC security groups
• AWS Network Firewall policies
• Amazon Route 53 Resolver DNS Firewall rules

Requirements

• Your accounts must be part of AWS Organizations
• You must enable AWS Config in each account and region
• You must designate an administrator account for Firewall Manager

How It Works

You create Firewall Manager policies in the administrator account, and Firewall Manager automatically applies them to all existing and new accounts in your organization (or specific OUs). This ensures consistent security posture across the organization.

For the exam: If you see “centrally manage WAF rules across multiple accounts,” or “enforce consistent firewall policies across an organization,” think Firewall Manager.

graph TD
    A[Firewall Manager\nAdministrator Account] -->|Manages policies| B[WAF Web ACLs]
    A -->|Manages policies| C[Shield Advanced\nProtections]
    A -->|Manages policies| D[Network Firewall\nPolicies]
    A -->|Manages policies| E[VPC Security Groups]
    A -->|Manages policies| F[Route 53 Resolver\nDNS Firewall]
    B -->|Auto-applied to| G[Account 1 - ALB]
    B -->|Auto-applied to| H[Account 2 - CloudFront]
    D -->|Auto-applied to| I[Account 3 - VPC]
    D -->|Auto-applied to| J[Account 4 - VPC]

Module 6 Summary and Exam Tips

Key takeaways from this module on network security:

Module 7: Cost and Budgeting Services

AWS Cost Explorer

AWS Cost Explorer is a tool that enables you to visualize, understand, and manage your AWS costs and usage over time. It provides a rich set of default reports and the ability to create custom views of your cost and usage data.

Key Features

Pre-built reports:

• Service costs over time
• Cost by linked account
• Cost by usage type
• Reserved Instance coverage and utilization

Filtering and grouping: Filter by service, region, account, tag, usage type, etc.

Forecasting: Cost Explorer can forecast future costs based on historical usage patterns (up to 12 months ahead).

Savings Plans and Reserved Instance recommendations: It analyzes your usage and recommends Savings Plans or RIs that would save you money.

Granularity: Can view costs at monthly, daily, or hourly granularity (hourly requires additional configuration).

Data Availability

• Cost Explorer data goes back up to 13 months
• Provides forecasts up to 12 months into the future
• Resource-level granularity: For EC2, you can see costs broken down by individual instance; for S3, by bucket

For the exam: Cost Explorer is for visualizing and understanding AWS costs; it provides recommendations for savings; it is the go-to tool for understanding “why did my bill go up?”

AWS Budgets

AWS Budgets is a service that allows you to set custom cost and usage budgets that alert you when your actual or forecasted costs exceed a threshold you define.

Types of Budgets

Budget Alerts

• You can set multiple thresholds per budget (e.g., alert at 50%, 80%, and 100% of budget)
• Alerts can be sent via email or SNS
• You can alert on actual spend OR forecasted spend
• You can create up to 62 alert thresholds per budget

Budget Actions

A powerful feature that allows you to automatically take actions when a budget threshold is breached:

• Apply an IAM policy to a user, group, or role (e.g., apply a DenyAll policy)
• Apply an SCP to an OU
• Stop specific EC2 or RDS instances

This means you can automatically stop spending when a budget is exceeded.

Demo - Creating an AWS Budget

This demo covered creating a monthly cost budget with email alerts and a budget action:

1. Set a monthly cost budget of $50
2. Set alert thresholds: 80% actual ($40) and 100% actual ($50)
3. Configured email notification to the budget owner
4. Added a budget action: when 100% threshold is hit, apply a DenyAll policy to a specified IAM user
5. Tested by manually triggering the budget action

AWS Cost and Usage Reports (CUR)

AWS Cost and Usage Reports (CUR) is the most comprehensive set of AWS cost and usage data available. It includes additional metadata about AWS services, pricing, and reservations that is not available in other reports.

Key Characteristics

CUR is the raw data export — it is not a visualization tool. You use other tools (Athena, QuickSight) to analyze the data.

For the exam: CUR provides the most detailed cost data; delivered to S3; used with Athena for custom analysis; it is the foundation for custom billing dashboards.

AWS Cost Anomaly Detection

AWS Cost Anomaly Detection is a service that uses machine learning to continuously monitor your cost and usage and automatically detect unusual spending patterns. It can alert you to cost anomalies that might indicate a problem (like unexpected resource usage or a compromised account spending money).

How It Works

1. You create a monitor that watches a specific cost dimension (service, linked account, cost category, or cost allocation tags)
2. Anomaly Detection uses ML to learn your normal spending patterns
3. When spending deviates significantly from the expected pattern, it creates an anomaly
4. You configure subscriptions (alerts) to be notified via email or SNS when anomalies are detected

Anomaly Alerts Include

• Which service or resource caused the anomaly
• The expected spend vs. actual spend
• The impact (how much extra was spent)
• The duration of the anomaly

For the exam: Cost Anomaly Detection uses ML to detect unusual spend; it is proactive monitoring vs. the reactive threshold-based alerts of Budgets.

AWS License Manager

AWS License Manager is a service that makes it easier to manage your software licenses from software vendors like Microsoft, SAP, Oracle, and IBM, across AWS and on-premises environments. It helps you set rules to prevent license violations.

Key Features

• License tracking: Track license usage against your purchased entitlements
• License rules: Set limits to prevent going over licensed quantities and get alerts when approaching limits
• AMI management: Associate licenses with AMIs so that when instances are launched from those AMIs, License Manager tracks the license
• Cross-account and cross-region license tracking (with Organizations support)

Common Use Cases

• Microsoft SQL Server licenses (per-core licensing)
• Oracle Database licenses
• Windows Server licenses (tracked via BYOL scenarios)
• SAP licenses

For the exam: License Manager = managing BYOL (Bring Your Own License) software licenses for commercial software on AWS; prevents license violations; tracks usage.

Module 7 Summary and Exam Tips

Key takeaways from this module on cost and budgeting services:

Search Terms

aws · securing · monitoring · core · services · amazon · web · cloudwatch · exam · manager · types · agent · features · logs · insights · kms · points · security · acm · cloudtrail · config · firewall · managed · policies