AWS

AWS EC2 EBS Monitoring

~ Last updated on : ~ jayendrapatil ~ 2 Comments

EBS Monitoring

AWS supports EBS monitoring by automatically providing data, such as CloudWatch metrics and volume status checks to help monitor EBS volumes.

CloudWatch Monitoring

  • CloudWatch metrics are statistical data that you can use to view, analyze, and set alarms on the operational behavior of the EBS volumes.
  • All Amazon EBS volume types automatically send 1-minute metrics to CloudWatch at no additional charge, but only when the volume is attached to an instance.
  • Some metrics have differences on Nitro-based instances vs. Xen-based instances.
  • EBS Metrics (AWS/EBS namespace)
    • VolumeReadBytes & VolumeWriteBytes
      • Provides information on the I/O operations in a specified period of time, in bytes.
    • VolumeReadOps & VolumeWriteOps
      • Total number (count) of I/O operations in a specified period of time.
    • VolumeTotalReadTime & VolumeTotalWriteTime
      • Total number of seconds spent by all operations that were completed in a specified period of time.
      • For Xen instances, data is reported only when there is read/write activity on the volume.
    • VolumeIdleTime
      • Total number of seconds, in a specific period, when the volume was idle (no read and write operations).
    • VolumeQueueLength
      • Number of read and write operations, in a specific period, waiting to be completed.
    • VolumeThroughputPercentage (Provisioned IOPS SSD volumes only)
      • Percentage of I/O operations per second (IOPS) delivered of the total IOPS provisioned.
    • VolumeConsumedReadWriteOps (Provisioned IOPS SSD volumes only)
      • Total amount of read and write operations (normalized to 256K capacity units) consumed in a specified period of time.
    • BurstBalance (gp2, st1, and sc1 volumes only)
      • Percentage of I/O credits (for gp2) or throughput credits (for st1 and sc1) remaining in the burst bucket.
      • Data is reported only when the volume is active. If the baseline performance exceeds the maximum burst performance, credits are never spent and burst balance remains at 100%.

I/O Latency Metrics (Nitro Instances Only – Added Oct 2024)

  • VolumeReadLatency
    • The per-minute average read I/O latency for the EBS volume, in milliseconds.
  • VolumeWriteLatency
    • The per-minute average write I/O latency for the EBS volume, in milliseconds.
  • Available at 1-minute granularity at no additional charge for all EBS volumes attached to EC2 Nitro instances.
  • Helps identify if latency is a result of under-provisioned EBS volumes.

Performance Exceeded Check Metrics (Nitro Instances Only – Added Oct 2024)

  • VolumeIOPSExceededCheck
    • Reports whether an application consistently attempted to drive IOPS that exceeds the volume’s provisioned IOPS performance within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • VolumeThroughputExceededCheck
    • Reports whether an application consistently attempted to drive throughput that exceeds the volume’s provisioned throughput performance within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • Supported for all volume types except magnetic (standard) attached to Nitro instances.
  • Not supported with Multi-Attach enabled volumes.

Average Performance Metrics (Nitro Instances Only – Added Oct 2025)

  • VolumeAvgIOPS
    • The average read and write IOPS driven to the volume in a minute.
    • Returns zero if no operations were driven to the volume within the last minute.
  • VolumeAvgThroughput
    • The average read and write throughput (KiB/s) driven to the volume in a minute.
    • Returns zero if no operations were driven to the volume within the last minute.
  • Useful for tracking performance trends, detecting bottlenecks, and right-sizing provisioned performance.

Instance-Level EBS Metrics (AWS/EC2 Namespace – Nitro Instances)

  • InstanceEBSIOPSExceededCheck (Added Oct 2025)
    • Reports whether driven IOPS is exceeding the maximum EBS IOPS that the instance can support within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • InstanceEBSThroughputExceededCheck (Added Oct 2025)
    • Reports whether driven throughput is exceeding the maximum EBS throughput limits for the instance within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • EBSReadOps & EBSWriteOps
    • Completed read/write operations from all EBS volumes attached to the instance.
  • EBSIOBalance% & EBSByteBalance%
    • Percentage of I/O credits and throughput credits remaining for burst-capable instances.
    • Available for instances that burst to their maximum performance for 30 minutes at least once every 24 hours.

CloudWatch Agent – EBS Detailed Performance Statistics (Added Jun 2025)

  • The CloudWatch agent can collect NVMe-based detailed performance statistics from EBS volumes attached to Nitro instances.
  • Metrics include queue depth, number of operations, bytes sent and received, and time spent on read and write I/O operations.
  • Available at sub-minute granularity as custom metrics in CloudWatch.
  • Provides deeper visibility beyond standard CloudWatch metrics for performance-sensitive workloads.

Volume Status Checks Monitoring

EC2 EBS Volume Status Check Monitoring

  • Volume status checks are automated tests that run every 5 minutes and return a pass or fail status.
  • Volume check status
    • Ok – all the status checks passed
    • Impaired – if the status checks failed
    • Insufficient-Data – checks are still in progress
    • Warning – the I/O performance of the volume is below expectations
  • When EBS determines the volume’s data is potentially inconsistent, it disables the I/O to the EBS volume from the attached EC2 instance to prevent any data corruption. This leads to the status check to fail and the volume status being impaired. Amazon waits for the I/O to be enabled, giving you an opportunity to perform consistency checks.
  • If the auto disabling of I/O is not needed, it can be overridden by enabling the Auto-Enabled IO flag, which would make the EBS volume auto-available immediately after the impaired status.
  • Events would be fired for notification whenever the I/O for an EBS volume is disabled.
  • I/O performance status checks compare actual volume performance with the expected volume performance and alert if performing below expectations. Applicable to io1, io2, and gp3 volumes.
  • While initializing Provisioned IOPS (SSD) volumes that were restored from snapshots, the performance of the volume may drop below 50 percent of its expected level, which causes the volume to display a warning state in the I/O Performance status check. This is expected and can be ignored.

EC2 EBS Volume Status

Attached EBS Status Checks (Added Aug 2024)

  • Amazon EC2 now includes a third type of status check — Attached EBS Status Check — that monitors whether the EBS volumes attached to an instance are reachable and can complete I/O operations.
  • The CloudWatch metric StatusCheckFailed_AttachedEBS reports a binary value:
    • 0 – All attached EBS volumes are reachable and can complete I/O.
    • 1 – One or more attached EBS volumes are impaired and unable to complete I/O operations.
  • Available for Nitro-based EC2 instances.
  • Enables creating CloudWatch alarms to automatically detect and respond to EBS volume reachability issues at the instance level.
  • Three types of EC2 status checks now exist:
    • System status checks – monitor the AWS systems the instance runs on.
    • Instance status checks – monitor the instance’s software and network configuration.
    • Attached EBS status checks – monitor reachability of attached EBS volumes.

Volume Initialization Status Monitoring (Added Jul 2025)

  • EBS now provides visibility into volume initialization status for volumes created from snapshots.
  • Allows you to validate when all blocks have been downloaded and written to the volume, enabling fully provisioned performance.
  • Can be used to time application launches to align with volume initialization completion.
  • EBS also supports Provisioned Rate for Volume Initialization (Added May 2025) that allows specifying a volume initialization rate between 100-300 MiB/s for faster initialization of snapshot-restored volumes.
  • EventBridge events are published for volume initialization state changes.

Volume Events Monitoring

  • EBS sends events to Amazon EventBridge for volume status changes and actions performed on volumes and snapshots.
  • Each event includes a start time that indicates the time at which the event occurred and a duration that indicates how long I/O for the volume was disabled.
  • Events description can be:
    • Awaiting Action: Enable IO – Volume data is potentially inconsistent, I/O is disabled.
    • IO Enabled – I/O operations were explicitly enabled for this volume.
    • IO Auto-Enabled – I/O operations were automatically enabled on this volume after an event.
    • Normal – For io1, io2, and gp3 volumes only. Volume performance is as expected.
    • Degraded – For io1, io2, and gp3 volumes only. Volume performance is below expectations.
    • Severely Degraded or Stalled – Volume performance significantly impacted.
  • EventBridge rules can trigger programmatic actions in response to these events (e.g., send notifications, invoke Lambda functions).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has configured CloudWatch monitoring on an EBS backed EC2 instance. If the user has not attached any additional device, which of the below mentioned metrics will always show a 0 value?
    1. DiskReadBytes
    2. NetworkIn
    3. NetworkOut
    4. CPUUtilization
  2. What does it mean if you have zero IOPS and a non-empty I/O queue for all EBS volumes attached to a running EC2 instance?
    1. The I/O queue is buffer flushing.
    2. Your EBS disk head(s) is/are seeking magnetic stripes.
    3. The EBS volume is unavailable. (EBS volumes are unavailable when all of the attached volumes perform zero read write IO, with pending IO in the queue. Refer link)
    4. You need to re-mount the EBS volume in the OS.
  3. While performing the volume status checks, if the status is insufficient-data, what does it mean?
    1. checks may still be in progress on the volume
    2. check has passed
    3. check has failed
  4. An application running on an EC2 instance with an io2 EBS volume is experiencing intermittent latency spikes. Which NEW CloudWatch metrics should be used to identify if the volume is under-provisioned? (Choose 2)
    1. VolumeReadLatency and VolumeWriteLatency
    2. VolumeQueueLength
    3. VolumeIOPSExceededCheck
    4. VolumeIdleTime
    5. VolumeTotalReadTime
  5. A company wants to monitor whether EBS volume performance bottlenecks are caused by the volume limits or the EC2 instance limits. Which combination of metrics should be used?
    1. VolumeReadOps and VolumeWriteOps
    2. BurstBalance and VolumeQueueLength
    3. VolumeIOPSExceededCheck (volume-level) and InstanceEBSIOPSExceededCheck (instance-level)
    4. EBSIOBalance% and VolumeThroughputPercentage
  6. After the August 2024 update, how many types of EC2 status checks are available?
    1. One – System status check
    2. Two – System and Instance status checks
    3. Three – System, Instance, and Attached EBS status checks
    4. Four – System, Instance, EBS Volume, and Network status checks

References

AWS EC2 Instance Metadata & User Data – IMDSv2

~ Last updated on : ~ jayendrapatil ~ 4 Comments

EC2 Instance Metadata & Userdata

⚠️ Important Update (2024): Starting mid-2024, all newly released Amazon EC2 instance types use IMDSv2 only by default. AWS strongly recommends migrating from IMDSv1 to IMDSv2 across all existing infrastructure. Amazon Linux 2023 enforces IMDSv2 by default with IMDSv1 disabled.

  • Instance metadata and user data can be used for Self Configuration allowing EC2 instances answer the question Who am I? What should I do?
  • Instance metadata and user data can be accessed from within the instance itself
  • Data is not protected by authentication or cryptographic methods. Anyone who can access the instance can view its metadata and should not be used to store any sensitive data, such as passwords, as user data.
  • Both the metadata and user data are available from the IP address 169.254.169.254 (IPv4) or fd00:ec2::254 (IPv6, on Nitro instances) and have the latest as well as previous versions available
  • Metadata and User data can be retrieved using simple curl or GET command and these requests are not billed

Instance Metadata

  • Instance metadata is data about the instance and allows you to get answers to the Who am I?
  • is divided into two categories
    • Instance metadata
      • includes metadata about the instance such as instance id, AMI id, hostname, IP address, role, etc
      • Can be accessed from http://169.254.169.254/latest/meta-data/
    • Dynamic data
      • is generated when the instances are launched such as instance identity documents, instance monitoring, etc
      • Can be accessed from http://169.254.169.254/latest/dynamic/
  • can be used for managing and configuring running instances
  • allows access to user data that specified when launching the instance

Instance Metadata Access Methods

  • Instance metadata can be accessed from a running instance using one of the following methods:
    • Instance Metadata Service Version 2 (IMDSv2) – a session-oriented method (Recommended)
    • Instance Metadata Service Version 1 (IMDSv1) – a request/response method (Legacy, being phased out)
  • By default, either IMDSv1 or IMDSv2, or both can be used on older instance types.
  • Starting mid-2024, all newly released EC2 instance types use IMDSv2 only by default.
  • Instance metadata service distinguishes between IMDSv1 and IMDSv2 requests based on whether, for any given request, either the PUT or GET headers, which are unique to IMDSv2, are present in that request.
  • Instance metadata service can be configured on each instance so that local code or users must use IMDSv2. When IMDSv2 is enforced, IMDSv1 no longer works.
  • IMDS can also be completely disabled on an instance if instance metadata access is not needed.

IMDSv2

  • IMDSv2 uses session-oriented requests.
  • With session-oriented requests, a session token that defines the session duration is created, which can be a minimum of one second and a maximum of six hours.
  • During the specified duration, the same session token can be used for subsequent requests.
  • After the specified duration expires, a new session token to use for future requests must be created.
  • IMDSv2 provides additional protection against the following vulnerabilities:
    • Open website application firewalls
    • Open reverse proxies
    • Server-Side Request Forgery (SSRF) vulnerabilities
    • Open Layer 3 firewalls and NATs
  • HTTP PUT response hop limit controls the number of network hops the token can travel.
    • Default is 1 for standard instances
    • Should be set to 2 or higher for instances running containers (Docker, ECS, EKS) as the container adds an extra network hop
    • Maximum value is 64

IMDSv2 Example Usage

IMDSv2 Migration and Enforcement

  • AWS IMDSv2 Default Timeline:
    • November 2023: All console Quick Start launches use IMDSv2-only
    • March 2024: Account-level API (ModifyInstanceMetadataDefaults) to set IMDSv2 as default for all new launches
    • Mid-2024: All newly released EC2 instance types use IMDSv2 only (IMDSv1 can still be re-enabled)
    • Amazon Linux 2023: IMDSv1 disabled by default, hop limit set to 2
  • Methods to enforce IMDSv2:
    • Set IMDSv2 as default at the account level using ModifyInstanceMetadataDefaults API
    • Use Declarative Policies in AWS Organizations to enforce across multiple accounts and Regions simultaneously
    • Configure the instance at launch time
    • Configure the AMI to require IMDSv2
    • Use IAM policies to require IMDSv2
  • Use the MetadataNoToken CloudWatch metric to identify IMDSv1 usage before enforcing IMDSv2
  • Use the IMDS Packet Analyzer tool to pinpoint exactly which software needs updating for IMDSv2 compatibility

IMDS IPv6 Support

  • On Nitro-based instances, IMDS is also accessible via IPv6 at fd00:ec2::254
  • The IPv6 endpoint can be explicitly enabled on instances
  • Useful for dual-stack or IPv6-only environments

Instance Tags in Metadata

  • Instance tags can be accessed from the instance metadata (available since January 2022)
  • By default, access to instance tags in metadata is disabled and must be explicitly enabled
  • Can be enabled at launch or after launch on a running or stopped instance
  • Tags can be accessed from http://169.254.169.254/latest/meta-data/tags/instance
  • Useful for self-configuration without needing IAM permissions to call the EC2 API

IMDS Security Considerations

  • IMDS runs on a loopback network interface and network calls never leave the EC2 instance
  • IMDSv2 protects against SSRF attacks by requiring a PUT request (which most SSRF exploits cannot make)
  • The hop limit of 1 in IMDSv2 prevents token retrieval from outside the instance
  • AWS issued a security bulletin (AWS-2025-021) regarding potential IMDS impersonation scenarios, reinforcing the importance of using IMDSv2
  • Ensure all SDKs, CLIs, and tools support IMDSv2 before disabling IMDSv1

User Data

  • User data can be used for bootstrapping (launching commands when the machine starts) EC2 instance and helps answer the What should I do?
  • is supplied when launching a EC2 instance and executed at boot time
  • can be in the form of parameters or user defined script executed when the instance is launched for e.g. perform software patch updates, load and update the application from an S3 bucket etc
  • can be used to build more generic AMIs, which can then be configured at launch time dynamically
  • can be retrieved from http://169.254.169.254/latest/user-data
  • By default, user data scripts and cloud-init directives run only during the first boot cycle when an EC2 instance is launched.
  • If you stop an instance, modify the user data, and start the instance, the new user data is not executed automatically.
  • However, user data script and cloud-init directives can be configured with a MIME multi-part file. A MIME multi-part file allows the script to override how frequently user data is executed in the cloud-init package.
  • is treated as opaque data and returned as is.
  • is limited to 16 KB. This limit applies to the data in raw form, not base64-encoded form.
  • must be base64-encoded before being submitted to the API. EC2 command line tools perform the base64 encoding. The data is decoded before being presented to the instance.

Cloud-Init & EC2Launch

  • Cloud-Init and EC2Launch agents provide the ability to parse the user-data script on the instance and run the instructions
  • Cloud-Init
    • Amazon Linux AMI supports Cloud-Init, which is an open source application built by Canonical.
    • is installed on Amazon Linux 2, Amazon Linux 2023, Ubuntu, and RHEL AMIs
    • enables using the EC2 UserData parameter to specify actions to run on the instance at boot time
    • User data is executed on first boot using Cloud-Init, if the user data begins with #!
  • EC2Launch v2 (Current – Windows Server 2022 and later)
    • EC2Launch v2 is the latest Windows launch agent that replaces both EC2Config and EC2Launch v1
    • Pre-installed on Windows Server 2022 and Windows Server 2025 AMIs
    • Supports all EC2Config and EC2Launch features with additional capabilities
    • Uses a YAML-based configuration for better control over launch tasks
    • User data is executed if it begins with <script> or <powershell>
    • Runs tasks at instance startup and supports task scheduling
    • Includes Sysprep support for creating custom Windows AMIs
    • Supports IMDSv2 natively
  • EC2Launch v1 (Legacy – Windows Server 2016/2019)
    • Replaced EC2Config on Windows Server 2016 and 2019
    • Version 1.3.2002730 or later required for IMDSv2 support
    • AWS recommends migrating to EC2Launch v2
  • EC2Config (Deprecated)
    • EC2Config was used on Windows Server 2012 and earlier
    • EC2Config is deprecated — the Windows Server versions it supports (2012 and earlier) are no longer supported by Microsoft
    • AWS strongly recommends upgrading to EC2Launch v2 on a supported OS version
    • Documentation is maintained for historical reference only

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. How can software determine the public and private IP addresses of the Amazon EC2 instance that it is running on?
    1. Query the local instance metadata
    2. Query the appropriate Amazon CloudWatch metric.
    3. Query the local instance userdata.
    4. Use ipconfig or ifconfig command.
  2. The base URI for all requests for instance metadata is ___________
    1. http://254.169.169.254/latest/
    2. http://169.169.254.254/latest/
    3. http://127.0.0.1/latest/
    4. http://169.254.169.254/latest/
  3. Which Amazon Elastic Compute Cloud feature can you query from within the instance to access instance properties?
    1. Instance user data
    2. Resource tags
    3. Instance metadata
    4. Amazon Machine Image
  4. You need to pass a custom script to new Amazon Linux instances created in your Auto Scaling group. Which feature allows you to accomplish this?
    1. User data
    2. EC2Config service
    3. IAM roles
    4. AWS Config
  5. By default, when an EBS volume is attached to a Windows instance, it may show up as any drive letter on the instance. You can change the settings of the _____ Service to set the drive letters of the EBS volumes per your specifications.
    1. EBSConfig Service
    2. AMIConfig Service
    3. EC2Launch v2 Service (Note: Previously EC2Config Service. EC2Launch v2 is the current service for Windows Server 2022+)
    4. Ec2-AMIConfig Service
  6. How can software determine the public and private IP addresses of the Amazon EC2 instance that it is running on?
    1. Query the appropriate Amazon CloudWatch metric.
    2. Use ipconfig or ifconfig command.
    3. Query the local instance userdata.
    4. Query the local instance metadata.
  7. A security team wants to ensure that all EC2 instances in their account use only IMDSv2 and IMDSv1 is disabled. Which of the following approaches can achieve this? (Select TWO)
    1. Use the ModifyInstanceMetadataDefaults API to set IMDSv2 as required at the account level
    2. Disable the instance metadata service entirely
    3. Use Declarative Policies in AWS Organizations to enforce IMDSv2 across the organization
    4. Set the hop limit to 0
    5. Create a security group rule to block IMDSv1 requests
  8. An application running in a Docker container on an EC2 instance is unable to retrieve the IMDSv2 session token. What is the most likely cause?
    1. The security group is blocking metadata access
    2. The HTTP PUT response hop limit is set to 1, which does not allow the token to reach the container
    3. IMDSv2 does not support containerized workloads
    4. The container is not using the correct IP address
  9. Which of the following is the IPv6 address for accessing the Instance Metadata Service on Nitro-based instances?
    1. fe80::254
    2. fc00:ec2::254
    3. fd00:ec2::254
    4. ::1/metadata
  10. A company wants to allow EC2 instances to access their own tags without making API calls. What should they do?
    1. Tags are automatically available in instance metadata
    2. Enable the “Allow access to tags in instance metadata” option for the instance
    3. Attach an IAM role with ec2:DescribeTags permission
    4. Install a special agent to retrieve tags

References

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

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

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

⚠️ EXAM VERSION UPDATE

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

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

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

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

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

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

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

Domain % of Exam
Domain 1: Detection 16%
Domain 2: Incident Response 14%
Domain 3: Infrastructure Security 18%
Domain 4: Identity and Access Management 20%
Domain 5: Data Protection 18%
Domain 6: Security Foundations and Governance 14%

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

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

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

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

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

Security, Identity & Compliance

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

Networking & Content Delivery

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

Management & Governance Tools

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

Storage & Databases

Compute

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

Generative AI Security (New in SCS-C03)

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

Integration Tools

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

Whitepapers and Articles

On the Exam Day

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

Finally, All the Best 🙂

AWS EC2 Networking – ENI, ENA & EFA

~ Last updated on : ~ jayendrapatil ~ 24 Comments

EC2 Network Features

EC2 Network covers a lot of features for low latency access, High Performance Computing, Enhanced Networking, ENA Express, Elastic Fabric Adapter, etc.

📌 Key Updates (2024-2026):

  • EC2-Classic fully retired (August 2023) – All instances now run in VPC only
  • Public IPv4 address charges – $0.005/IP/hour for ALL public IPv4 addresses (February 2024)
  • ENA Express – Up to 25 Gbps single-flow bandwidth using SRD protocol, now supports cross-AZ traffic (2026)
  • Network bandwidth – Up to 600 Gbps with C8gn/R8gn instances (6th gen Nitro Cards)
  • Jumbo frames – Cross-region VPC peering now supports up to 8500 bytes MTU (March 2025)
  • Instance Bandwidth Weighting – Adjust VPC/EBS bandwidth split by up to 25% (December 2024)

EC2 and VPC

  • All EC2 instances run exclusively within a VPC
  • EC2-Classic was fully retired in August 2023. All instances must be launched in a VPC.
  • Launching an EC2 instance within a VPC provides the following benefits
    • Assign static private IP addresses to instances that persist across starts and stops
    • Assign multiple IP addresses to the instances
    • Define network interfaces, and attach one or more network interfaces to the instances
    • Change security group membership for the instances while they’re running
    • Control the outbound traffic from the instances (egress filtering) in addition to controlling the inbound traffic to them (ingress filtering)
    • Add an additional layer of access control to the instances in the form of network access control lists (ACL)
    • Run the instances on single-tenant dedicated hardware
    • Launch instances in IPv6-only, dual-stack, or IPv4-only subnets

EC2 Instance IP Addressing

  • Private IP address & Internal DNS Hostnames
    • Private IP address is the IP address that’s not reachable over the internet and can be resolved only within the network
    • When an instance is launched, the default network interface eth0 is assigned a private IP address and an internal DNS hostname, which resolves to the private IP address and can be used for communication between the instances in the same network only
    • Private IP address and DNS hostname cannot be resolved outside the network that the instance is in.
    • Private IP address behaviour
      • remains associated with the instance when it is stopped or rebooted
      • is disassociated only when the instance is terminated
    • An instance when launched can be assigned a private IP address or EC2 will automatically assign an IP address to the instance within the address range of the subnet
    • Additional private IP addresses, known as secondary private IP addresses can also be assigned. Unlike primary private IP addresses, secondary private IP addresses can be reassigned from one instance to another.
  • Public IP address and External DNS hostnames
    • A public IP address is reachable from the Internet
    • Each instance assigned a public IP address is also given an External DNS hostname.
    • External DNS hostname resolves to the public IP address outside the network and to the private IP address within the network.
    • Public IP address is associated with the primary Private IP address through NAT
    • Within a VPC, an instance may or may not be assigned a public IP address depending upon the subnet Assign Public IP attribute
    • Public IP address assigned to the pool is from the public IP address pool and is assigned to the instance, and not to the AWS account. It cannot be reused once disassociated and is released back to the pool
    • Public IP address behaviour
      • cannot be manually associated or disassociated with an instance
      • is released when an instance is stopped or terminated.
      • a new public IP address is assigned when a stopped instance is started
      • is released when an instance is assigned an Elastic IP address
      • is not assigned if there is more than one network interface attached to the instance
    • As of February 2024, all public IPv4 addresses incur a charge of $0.005 per IP per hour, whether attached to a service or not. This applies to both auto-assigned public IPs and Elastic IPs.
  • IPv6 Addresses
    • IPv6 addresses are globally unique and reachable over the Internet
    • An instance can be launched in an IPv6-only subnet (Nitro-based instances only), dual-stack subnet, or IPv4-only subnet
    • IPv6 addresses persist when an instance is stopped and started
    • IPv6 addresses are not charged, making them a cost-effective alternative to public IPv4
  • Multiple Private IP addresses
    • Multiple private IP addresses can be specified to the instances.
    • This can be useful in the following cases
      • Host multiple websites on a single server by using multiple SSL certificates on a single server and associating each certificate with a specific IP address.
      • Operate network appliances, such as firewalls or load balancers, that have multiple private IP addresses for each network interface.
      • Redirect internal traffic to a standby instance in case the instance fails, by reassigning the secondary private IP address to the standby instance.
    • Multiple IP addresses work with Network Interfaces
      • Secondary IP address can be assigned to any network interface, which can be attached or detached from an instance
      • Secondary IP address must be assigned from the CIDR block range of the subnet for the network interface
      • Security groups apply to network interfaces and not to IP addresses
      • Secondary private IP addresses that are assigned to ENIs attached to running or stopped instances.
      • Secondary private IP addresses that are assigned to a network interface can be reassigned to another one if you explicitly allow it.
      • Primary private IP addresses, secondary private IP addresses, and any associated Elastic IP addresses remain with the network interface when it is detached from an instance or attached to another instance.
      • Although the primary network interface cannot be moved from an instance, the secondary private IP address of the primary network interface can be reassigned to another network interface.
  • IP Prefix Delegation
    • Instead of assigning individual secondary IP addresses, you can assign IP address prefixes to network interfaces
    • IPv4 prefixes: /28 (16 IP addresses) can be assigned per prefix
    • IPv6 prefixes: /80 can be assigned per prefix
    • Significantly increases the number of IP addresses available per ENI
    • Particularly useful for container workloads (e.g., Amazon EKS with VPC CNI plugin) to increase pod density per node
    • Can be auto-assigned or manually specified when creating or modifying a network interface

Elastic IP Addresses

  • An Elastic IP address is a static IPv4 address designed for dynamic cloud computing.
  • An elastic IP address can help mask the failure of an instance or software by rapidly remapping the address to another instance in the account.
  • The elastic IP address is associated with the AWS account and it remains associated with the account until released explicitly
  • An elastic IP address is NOT associated with a particular instance
  • An instance launched in a non-default VPC is assigned only a private IP address unless a public address is specifically requested or the subnet public IP attribute is enabled
  • When an Elastic IP address is assigned to an instance, the public IP address is disassociated with the instance
  • For an instance, without a public IP address, to communicate to the internet it must be assigned an Elastic IP address
  • When the Elastic IP address is dissociated the public IP address is assigned back to the instance. However, if a secondary network interface is attached to the instance, the public IP address is not automatically assigned
  • Elastic IP Address Pricing (Updated February 2024)
    • All public IPv4 addresses (including EIPs) are now charged at $0.005 per IP per hour (~$3.60/month), whether in-use or idle
    • This replaces the previous model where only unused EIPs were charged
    • AWS Free Tier includes 750 hours of public IPv4 address usage per month for the first 12 months
    • You are NOT charged for IP addresses you own and bring to AWS using BYOIP (Bring Your Own IP)
    • Consider migrating to IPv6 to reduce costs
  • All AWS accounts are limited to 5 EIPs per Region (soft limit, can request increase)
  • Elastic IP supports tagging for cost allocation and organization

Elastic Network Interfaces (ENI)

  • Elastic Network Interfaces (ENIs) are virtual network interfaces that can be attached to instances running in a VPC
  • ENI consists of the following
    • A primary private IPv4 address
    • One or more secondary private IPv4 addresses
    • One Elastic IP address per private IPv4 address
    • One public IPv4 address, which can be auto-assigned to the elastic network interface for eth0 when an instance is launched
    • One or more IPv6 addresses
    • One or more security groups
    • A MAC address
    • A source/destination check flag
    • A description
    • IPv4 prefixes (/28) and IPv6 prefixes (/80) for prefix delegation
  • ENI can be created without being attached to an instance
  • ENI can be attached to an instance, detached from that instance and attached to another instance. Attributes of an ENI like elastic IP address, private IP address follow the ENI and when moved from one instance to another instance, all traffic to the ENI will be routed to the new instance.
  • An instance in VPC always has a default primary ENI attached (eth0) with a private IP address assigned from the VPC range and cannot be detached
  • Additional ENI (eth1-ethn) can be attached to the instance and the number varies depending upon the instance type
  • Most important difference between eth0 and eth1 is that eth0 cannot be dynamically attached or detached from a running instance.
  • Primary ENIs (eth0) are created automatically when an EC2 instance is launched and are also deleted automatically when the instance is terminated unless the administrator has changed a property of the ENI to keep it alive afterwards.
  • Multiple elastic network interfaces are useful for use cases:
    • Create a management network
      • Primary ENI eth0 handles backend with more restrictive control
      • Secondary ENI eth1 handles the public facing traffic
    • Licensing authentication
      • Fixed MAC address associated with a license authentication
    • Use network and security appliances in your VPC
      • configure a third-party network and security appliances (load balancers, NAT, proxy) with the secondary ENI
    • Create dual-homed instances with workloads/roles on distinct subnets.
    • Create a low-budget, high-availability solution
      • If one of the instances serving a particular function fails, its elastic network interface can be attached to a replacement or hot standby instance pre-configured for the same role in order to rapidly recover the service
      • As the interface maintains its private IP, EIP, and MAC address, network traffic will begin flowing to the standby instance as soon as it is attached to the replacement instance
  • ENI Best Practices
    • ENI can be attached to an instance when it’s running (hot attach), when it’s stopped (warm attach), or when the instance is being launched (cold attach).
    • Primary (eth0) interface can’t be detached
    • Secondary (ethN) ENI can be detached when the instance is running or stopped.
    • ENI in one subnet can be attached to an instance in another subnet, but the same AZ and same VPC
  • When launching an instance from the CLI or API, both the primary (eth0) and additional elastic network interfaces can be specified
  • Launching an Amazon Linux or Microsoft Windows Server instance with multiple network interfaces automatically configures interfaces, private IP addresses, and route tables on the operating system of the instance.
  • A warm or hot attach of an additional ENI may require bringing up the second interface manually, configure the private IP address, and modify the route table accordingly.
  • Instances running Amazon Linux or Microsoft Windows Server automatically recognize the warm or hot attach and configure themselves.
  • Attaching another ENI to an instance is not a method to increase or double the network bandwidth to or from the dual-homed instance.
  • ENA Queue Allocation (2025) – EC2 now supports flexible ENA queue allocation per ENI, enabling efficient load-balancing of network traffic across available queues on each network interface.

Placement Groups

  • EC2 Placement groups determine how the instances are placed on the underlying hardware.
  • AWS provides three types of placement groups
    • Cluster – clusters instances into a low-latency group in a single AZ
    • Partition – spreads instances across logical partitions, ensuring that instances in one partition do not share underlying hardware with instances in other partitions
    • Spread – strictly places a small group of instances across distinct underlying hardware to reduce correlated failures
  • On-Demand Capacity Reservations in Cluster Placement Groups (2025)
    • CPG-ODCRs provide assured capacity with low latency and high throughput within a Cluster Placement Group
    • Supports sharing and targeting capabilities for cross-account usage
    • Can be scheduled up to 120 days in advance with future-dated capacity reservations

Network Maximum Transmission Unit – MTU

  • MTU of a network connection is the size, in bytes, of the largest permissible packet that can be transferred over the connection.
  • The larger the MTU of the connection the more the data can be transferred in a single packet
  • Largest ethernet packet size supported over most of the internet is 1500 MTU
  • Jumbo Frames
    • Jumbo frames are Ethernet frames that allow more than 1500 bytes of data by increasing the payload size per packet and thus increasing the percentage of the packet that is not packet overhead.
    • Fewer packets are needed to send the same amount of usable data
    • Jumbo frames should be used with caution for Internet-bound traffic or any traffic that leaves a VPC.
    • Packets are fragmented by intermediate systems, which slows down this traffic.
  • Maximum supported MTU for an instance depends on its instance type
  • All EC2 instance types support 1500 MTU, and many current instance sizes support 9001 MTU or Jumbo frames
  • Traffic is limited to a maximum MTU of 1500 in the following cases:
    • Traffic over VPN connections
    • Traffic over an internet gateway
  • Updated MTU Support (March 2025):
    • Cross-region VPC peering now supports jumbo frames up to 8500 bytes MTU (previously limited to 1500)
    • EC2 now supports full instance bandwidth for inter-region VPC peering traffic and to AWS Direct Connect
    • Transit Gateway supports 8500 MTU for all attachments
    • Intra-region VPC peering continues to support 9001 MTU (jumbo frames)
  • For instances that are collocated inside a placement group, jumbo frames help to achieve the maximum network throughput possible, and they are recommended in this case.

Enhanced Networking

  • Enhanced networking results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability, and lower jitter.
  • EC2 provides enhanced networking capabilities using single root I/O virtualization (SR-IOV) on supported instance types
    • SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization
  • Two mechanisms for enhanced networking:
    • Elastic Network Adapter (ENA) – supports network speeds of up to 100 Gbps (up to 600 Gbps on network-optimized instances). All instances built on the AWS Nitro System use ENA.
    • Intel 82599 Virtual Function (VF) interface – uses the Intel ixgbevf driver, supports up to 10 Gbps. Only for legacy Xen-based instance types (C3, C4, R3, I2, M4, D2).
  • All current-generation instances support enhanced networking via ENA
  • Enhanced networking is available only within a VPC

ENA Express

  • ENA Express is an enhanced networking feature that uses the AWS Scalable Reliable Datagram (SRD) protocol to improve network performance
  • SRD is a high-performance network transport protocol that uses dynamic routing to increase throughput and minimize tail latency
  • Key Benefits:
    • Increases maximum single-flow bandwidth from 5 Gbps up to 25 Gbps (up to the aggregate instance limit)
    • Reduces tail latency by up to 93% (P99.9) during periods of high network load
    • Detects and avoids congested network paths through multi-pathing
    • Handles packet reordering and most retransmits in the network layer, freeing the application layer
  • How it works:
    • Enabled per network interface attachment via API call or AWS Console toggle
    • Sending instance initiates SRD communication if both sender and receiver have ENA Express enabled
    • Falls back to standard ENA transmission if the receiving instance does not support ENA Express
    • Works transparently with TCP and UDP protocols
  • Scope:
    • Originally supported traffic within the same Availability Zone only
    • May 2026: ENA Express now supports cross-AZ traffic within a Region, delivering up to 25 Gbps single-flow bandwidth between AZs
  • Supported on a wide range of instance types (120+ instance types as of 2025)
  • ENA Express traffic cannot be sent in a Local Zone
  • Best suited for workloads requiring high single-flow throughput; for workloads needing lowest latency with high PPS during non-congestion, standard enhanced networking may be preferable

Instance Bandwidth Weighting

  • Launched December 2024 – allows adjusting the VPC networking and EBS bandwidth allocation on EC2 instances
  • Customers can shift bandwidth by up to 25% between VPC and EBS in either direction
  • When increasing bandwidth for one service (e.g., VPC), the available bandwidth for the other (EBS) is reduced by the same absolute amount
  • Useful for workloads that are either network-intensive or storage-intensive but not both simultaneously
  • Burst bandwidth remains the same for the selected option on most instance types

Network Bandwidth Capabilities (2025-2026)

  • Network-optimized instances now support up to 600 Gbps network bandwidth:
    • C8gn – Graviton4-based, up to 600 Gbps (GA June 2025)
    • R8gn – Graviton4-based, up to 600 Gbps (GA September 2025)
    • M8gn – Graviton4-based, up to 600 Gbps (GA December 2025)
    • R8in/R8idn – Intel-based, up to 600 Gbps (2026)
  • These instances feature 6th generation AWS Nitro Cards
  • Previous generation network-optimized instances (C6in, R6in, R6idn) support up to 200 Gbps

Elastic Fabric Adapter – EFA

  • An Elastic Fabric Adapter (EFA) is a network device that can be attached to the EC2 instance to accelerate High Performance Computing (HPC) and machine learning applications.
  • EFA helps achieve the application performance of an on-premises HPC cluster, with the scalability, flexibility, and elasticity provided by AWS.
  • EFA provides lower and more consistent latency and higher throughput than the TCP transport traditionally used in cloud-based HPC systems.
  • EFA enhances the performance of inter-instance communication which is critical for scaling HPC and machine learning applications.
  • EFA is optimized to work on the existing AWS network infrastructure and it can scale depending on application requirements.
  • EFAs provide all of the same traditional IP networking features as ENAs, and they also support OS-bypass capabilities. OS-bypass enables HPC and machine learning applications to bypass the operating system kernel and to communicate directly with the EFA device.
  • EFA uses the AWS Scalable Reliable Datagram (SRD) protocol to increase network throughput utilization
  • EFA Updates (2024-2026):
    • Cross-subnet communication (July 2024) – EFA now supports traffic across subnets for both existing and new instances. Requires security group rules to allow cross-subnet traffic.
    • EFA-only interface (October 2024) – New interface type that decouples EFA from ENA. Allows standalone EFA devices on secondary interfaces without requiring IP addresses, solving IPv4 address exhaustion and IP routing challenges for AI/ML clusters.
    • New EFA observability metrics (September 2025) – Metrics for retransmitted packets/bytes, retransmit timeout events, impaired remote connections, and unresponsive remote receiver events.
    • NIXL support with EFA (March 2026) – Accelerates LLM inference at scale through increased KV-cache throughput, reduced inter-token latency, and optimized KV-cache memory utilization.
    • Kubernetes Dynamic Resource Allocation for EFA (May 2026) – Amazon EKS supports DRA for EFA, simplifying RDMA configuration for AI/ML and HPC workloads.
    • SageMaker HyperPod EFA-only support (June 2026) – Dedicated EFA devices without traditional ENA for IP networking in SageMaker clusters.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user is launching an EC2 instance in the US East region. Which of the below mentioned options is recommended by AWS with respect to the selection of the availability zone?
    1. Always select the US-East-1-a zone for HA
    2. Do not select the AZ; instead let AWS select the AZ
    3. The user can never select the availability zone while launching an instance
    4. Always select the AZ while launching an instance
  2. You have multiple Amazon EC2 instances running in a cluster across multiple Availability Zones within the same region. What combination of the following should be used to ensure the highest network performance (packets per second), lowest latency, and lowest jitter? Choose 3 answers
    1. Amazon EC2 placement groups (would not work for multiple AZs. Defaults to Cluster)
    2. Enhanced networking (provides network performance, lowest latency)
    3. Amazon PV AMI (Needs HVM)
    4. Amazon HVM AMI
    5. Amazon Linux (Can work on other flavors of Unix as well)
    6. Amazon VPC (Enhanced networking works only in VPC)
  3. Regarding the attaching of ENI to an instance, what does ‘warm attach’ refer to?
    1. Attaching an ENI to an instance when it is stopped
    2. Attaching an ENI to an instance when it is running
    3. Attaching an ENI to an instance during the launch process
  4. Can I detach the primary (eth0) network interface when the instance is running or stopped?
    1. Yes, You can.
    2. You cannot
    3. Depends on the state of the interface at the time
  5. By default what are ENIs that are automatically created and attached to instances using the EC2 console set to do when the attached instance terminates?
    1. Remain as is
    2. Terminate
    3. Hibernate
    4. Pause
  6. Select the incorrect statement
    1. In Amazon VPC, the private IP addresses only returned to Amazon EC2 when the instance is terminated
    2. In Amazon VPC, an instance retains its private IP addresses when the instance is stopped.
    3. In Amazon VPC, an instance does NOT retain its private IP addresses when the instance is stopped
    4. In Amazon VPC, the private IP address is associated exclusively with the instance for its lifetime
  7. To ensure failover capabilities, consider using a _____ for incoming traffic on a network interface”.
    1. primary public IP
    2. secondary private IP
    3. secondary public IP
    4. add on secondary IP
  8. Which statements are true about Elastic Network Interface (ENI)? (Choose 2 answers)
    1. You can attach an ENI in one AZ to an instance in another AZ
    2. You can change the security group membership of an ENI
    3. You can attach an instance to two different subnets within a VPC by using two ENIs
    4. You can attach an ENI in one VPC to an instance in another VPC
  9. A user is planning to host a web server as well as an app server on a single EC2 instance, which is a part of the public subnet of a VPC. How can the user setup to have two separate public IPs and separate security groups for both the application as well as the web server?
    1. Launch a VPC instance with two network interfaces. Assign a separate security group to each and AWS will assign a separate public IP to them. (AWS cannot assign public IPs for instance with multiple ENIs)
    2. Launch VPC with two separate subnets and make the instance a part of both the subnets.
    3. Launch a VPC instance with two network interfaces. Assign a separate security group and elastic IP to them.
    4. Launch a VPC with ELB such that it redirects requests to separate VPC instances of the public subnet.
  10. An organization has created multiple components of a single application for compartmentalization. Currently all the components are hosted on a single EC2 instance. Due to security reasons the organization wants to implement two separate SSLs for the separate modules although it is already using VPC. How can the organization achieve this with a single instance?
    1. Create a VPC instance, which will have both the ACL and the security group attached to it and have separate rules for each IP address.
    2. Create a VPC instance, which will have multiple network interfaces with multiple elastic IP addresses.
    3. You have to launch two instances each in a separate subnet and allow VPC peering for a single IP.
    4. Create a VPC instance, which will have multiple subnets attached to it and each will have a separate IP address.
  11. Your system automatically provisions EIPs to EC2 instances in a VPC on boot. The system provisions the whole VPC and stack at once. You have two of them per VPC. On your new AWS account, your attempt to create a Development environment failed, after successfully creating Staging and Production environments in the same region. What happened?
    1. You didn’t choose the Development version of the AMI you are using.
    2. You didn’t set the Development flag to true when deploying EC2 instances.
    3. You hit the soft limit of 5 EIPs per region and requested a 6th. (There is a soft limit of 5 EIPs per Region for VPC on new accounts. The third environment could not allocate the 6th EIP)
    4. You hit the soft limit of 2 VPCs per region and requested a 3rd.
  12. A user has created a VPC with a public subnet. The user has terminated all the instances, which are part of the subnet. Which of the below mentioned statements is true with respect to this scenario?
    1. The user cannot delete the VPC since the subnet is not deleted
    2. All network interface attached with the instances will be deleted
    3. When the user launches a new instance it cannot use the same subnet
    4. The subnet to which the instances were launched with will be deleted
  13. A company wants to reduce AWS costs after learning about the new public IPv4 address charges. Which combination of approaches would help minimize public IPv4 costs? (Choose 2 answers)
    1. Migrate workloads to IPv6-only subnets where possible (IPv6 addresses are free and eliminate the need for public IPv4)
    2. Use more Elastic IP addresses instead of auto-assigned public IPs (Both EIPs and auto-assigned public IPs are now charged equally at $0.005/IP/hour)
    3. Use NAT Gateway with private subnets for outbound-only internet access (Reduces number of public IPs needed; instances use private IPs)
    4. Switch from VPC to EC2-Classic networking (EC2-Classic was fully retired in August 2023)
  14. Which of the following is a feature of ENA Express? (Choose 2 answers)
    1. Increases maximum single-flow bandwidth from 5 Gbps to 25 Gbps
    2. Requires application code changes to use SRD protocol
    3. Reduces tail latency (P99.9) for network traffic between EC2 instances
    4. Works only with EFA-enabled instances
  15. A machine learning team needs to scale their training cluster to thousands of instances but is running out of private IPv4 addresses. Which EFA feature should they use?
    1. EFA cross-subnet communication
    2. EFA-only network interfaces (EFA-only interfaces decouple EFA from ENA, allowing standalone EFA devices without requiring IP addresses)
    3. ENA Express with SRD protocol
    4. IP prefix delegation on ENIs
  16. An application requires high single-flow network throughput between EC2 instances across Availability Zones. Which feature should be enabled?
    1. Enhanced networking with Intel 82599 VF
    2. Elastic Fabric Adapter (EFA)
    3. ENA Express (ENA Express supports cross-AZ traffic as of May 2026, delivering up to 25 Gbps single-flow bandwidth)
    4. Jumbo frames (9001 MTU)

References

AWS X-Ray

~ Last updated on : ~ jayendrapatil

AWS X-Ray

⚠️ X-Ray SDK/Daemon Maintenance Mode Notice

As of February 25, 2026, the AWS X-Ray SDKs and Daemon have entered maintenance mode. AWS will limit releases to security fixes only — no new feature enhancements.

The X-Ray service itself remains fully supported and continues to receive new features (e.g., native OpenTelemetry support, CloudWatch Transaction Search).

Recommended Migration Path:

  • AWS Distro for OpenTelemetry (ADOT) — AWS’s distribution of OpenTelemetry with zero-code auto-instrumentation
  • OpenTelemetry SDKs — Industry-standard open-source instrumentation with X-Ray as backend
  • CloudWatch Agent — Unified agent that can collect and send traces to X-Ray via OTLP

See Migration Guide for detailed instructions.

  • AWS X-Ray helps developers analyze and debug production, distributed applications for e.g. built using a microservices lambda architecture
  • provides an end-to-end view of requests as they travel through the application, and shows a map of the application’s underlying components.
  • helps to understand how the application and its underlying services are performing to identify and troubleshoot the root cause of performance issues and errors.
  • can help analyze applications in development and in production, from simple three-tier applications to complex microservices applications consisting of thousands of services.
  • can be used with distributed applications of any size to trace and debug both synchronous requests and asynchronous events.
  • can be used to track requests flowing through applications or services across multiple regions. Data is stored locally in the processed region and customers can build a solution over it to combine the data.
  • makes the Trace data available for retrieval and filtering within 30 seconds of it being received by the service.
  • stores trace data for the last 30 days.
  • encrypts traces and related data at rest and supports encryption in transit.
  • Integration
    • X-Ray integrates with applications running on EC2, ECS, Lambda, Elastic Beanstalk, EKS, App Runner, and API Gateway.
    • X-Ray SDK automatically captures metadata for API calls made to AWS services using the AWS SDK
    • X-Ray SDK provides add-ons for MySQL and PostgreSQL drivers.
    • For Elastic Beanstalk, include the language-specific libraries in the application code.
    • Applications running on other AWS services, such as EC2 or ECS, install the X-Ray agent and instrument the application code
    • CloudWatch Agent can now collect and send traces to X-Ray using the OpenTelemetry Protocol (OTLP), providing a unified agent for metrics, logs, and traces.

X-Ray Architecture

X-Ray Core Concepts

  • Segment
    • A Segment encapsulates all the data points for a single component of the distributed application for e.g. authorization component.
    • A segment provides the resource’s name, details about the request, and details about the work done.
    • Segments include system-defined and user-defined data in the form of annotations and are composed of one or more sub-segments that represent remote calls made from the service. for e.g. database call and its result within the overall request/response
  • Subsegments
    • A segment can break down the data about the work done into subsegments.
    • Subsegments provide more granular timing information and details about downstream calls that the application made to fulfill the original request.
    • A subsegment can contain additional details about a call to an AWS service, an external HTTP API, or an SQL database.
    • Arbitrary subsegments can be defined to instrument specific functions or lines of code in the application.
  • Trace
    • Trace collects all the segments generated by a single request.
    • Trace is a set of data points that share the same trace ID.
    • Trace helps track the request, which is assigned a unique trace id, while it navigates through services
    • Piece of information relayed by each service in the application to X-Ray is a segment, and a trace is a collection of segments.
  • Filter Expressions
    • Filter expressions can be used to find traces related to specific paths or users.
  • Annotations and Metadata
    • Annotations are simple key-value pairs that are indexed for use with filter expressions.
    • Metadata are key-value pairs with values of any type, including objects and lists, but that is not indexed.
    • An Annotation is system-defined or user-defined data
      • System-defined annotations include data added to the segment by AWS services
      • User-defined annotations are metadata added to a segment by a developer
    • Annotations and metadata are aggregated at the trace level and can be added to any segment or subsegment.
    • Annotation and metadata are associated with a segment and a segment can contain multiple annotations.
  • Errors, Faults, and Exceptions
    • X-Ray errors are system annotations associated with a segment for a call that results in an error response.
    • Error includes the error message, stack trace, and any additional information for e.g, version to associate the error with a source file.
    • Error – Client errors (400 series errors)
    • Fault – Server faults (500 series errors)
    • Throttle – Throttling errors (429 Too Many Requests)
  • Sampling
    • X-Ray collects data for a significant number of requests, instead of each request sent to an application, for performant and cost-effectiveness
    • X-Ray should not be used as an audit or compliance tool because it does not guarantee data completeness.
    • By default, the X-Ray SDK records the first request each second, and five percent of any additional requests.
    • Sampling rules can be configured centrally in the X-Ray console or API without redeploying applications. Rules can match on service name, HTTP method, URL path, resource ARN, and other attributes.
    • Both ADOT and X-Ray SDK honor centrally configured sampling rules from the X-Ray service.
  • Groups
    • Groups are collections of traces defined by a filter expression.
    • Groups can be used to generate additional service graphs and supply Amazon CloudWatch metrics.
    • Groups enable focused analysis of specific services, environments, or request patterns.

X-Ray Insights

  • X-Ray Insights continuously analyzes trace data to identify emergent issues in applications using anomaly detection.
  • When fault rates exceed the expected range, X-Ray creates an insight that records the issue and tracks its impact until resolved.
  • Insights capabilities:
    • Identify where issues are occurring, root cause, and associated impact
    • Impact analysis to derive severity and priority
    • Receive notifications as issues change over time via Amazon EventBridge
    • Automate alerts based on issue severity
  • X-Ray uses statistical modeling to predict expected fault rates and detects anomalies in nodes of the service map.
  • Insights must be enabled per group in X-Ray settings.

X-Ray Daemon

  • X-Ray daemon is a software application that listens for traffic on UDP port 2000, gathers raw segment data, and relays it to the AWS X-Ray API.
  • Daemon works in conjunction with the AWS X-Ray SDKs and must be running so that data sent by the SDKs can reach the X-Ray service.
  • Note: As of February 25, 2026, the X-Ray Daemon is in maintenance mode. AWS recommends migrating to the CloudWatch Agent or ADOT Collector for trace collection.

X-Ray API

  • X-Ray API provides access to all X-Ray functionality through the AWS SDK, AWS Command Line Interface, or directly over HTTPS.

X-Ray with VPC Endpoints

  • X-Ray can be configured to use an Interface VPC endpoint, that enables you to privately access X-Ray APIs through private IP addresses.
  • AWS PrivateLink restricts all network traffic between the VPC and X-Ray to the Amazon network. You don’t need an internet gateway, a NAT device, or a virtual private gateway.

OpenTelemetry and X-Ray

  • AWS X-Ray has transitioned to OpenTelemetry (OTel) as its primary instrumentation standard for application tracing.
  • OpenTelemetry is an industry-wide open-source standard (CNCF project) providing standardized protocols and tools for collecting and routing telemetry data.
  • AWS Distro for OpenTelemetry (ADOT)
    • AWS’s distribution of OpenTelemetry for collecting metrics, traces, and logs.
    • Supports auto-instrumentation (zero-code) for Java, Python, Node.js, .NET, and Go.
    • Traces collected via ADOT are sent to X-Ray backend for visualization and analysis.
    • Provides broader library/framework coverage than X-Ray SDKs.
  • X-Ray OTLP Endpoint
    • Customers can send traces directly to X-Ray using the OpenTelemetry Protocol (OTLP) without needing the X-Ray Daemon.
    • Enables use of any OTLP-compatible exporter to send traces to X-Ray.
    • Required when using CloudWatch Transaction Search features.
  • CloudWatch Agent for Traces
    • The unified CloudWatch Agent can now collect traces via OTLP and forward them to X-Ray.
    • Provides a single agent for metrics, logs, and traces collection.
  • Migration Benefits:
    • Zero-code auto-instrumentation (no code changes needed)
    • Broader language and framework support
    • Industry-standard APIs portable across observability backends
    • Access to CloudWatch Application Signals and Transaction Search

CloudWatch Integration

  • CloudWatch ServiceLens
    • Brings together metrics, logs, and X-Ray traces into a unified service map view.
    • Correlates trace data with CloudWatch metrics and logs for faster troubleshooting.
    • Provides drill-down from service map nodes to specific traces, metrics, and log groups.
  • CloudWatch Application Signals (GA June 2024)
    • Application Performance Monitoring (APM) solution built on X-Ray traces and OpenTelemetry.
    • Provides pre-built dashboards showing volume, availability, latency, faults, and errors.
    • Supports Service Level Objectives (SLOs) to track application performance against KPIs.
    • Automatic instrumentation across ECS, EKS, Lambda, EC2, and App Runner.
    • Supports Java, Python, Node.js, and .NET applications.
  • CloudWatch Transaction Search (Launched November 2024)
    • Interactive analytics experience for complete visibility into application transaction spans.
    • Enables searching and analyzing spans across all traces without sampling limitations.
    • Bundles X-Ray tracing capabilities with Application Signals features under a unified pricing model.
    • Supports spans sent via X-Ray SDK, ADOT, or OTLP endpoint.
  • CloudWatch RUM (Real-User Monitoring)
    • Integrates with X-Ray to analyze and debug the request path from end users through downstream services.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is facing performance issues with their microservices architecture deployed on AWS. Which service can help them debug and analyze the issue? [CCP]
    1. AWS Inspector
    2. CodeDeploy
    3. X-Ray
    4. AWS Config
  2. A development team wants to instrument their distributed application for tracing with AWS X-Ray. Which approach does AWS currently recommend? [DVA-C02]
    1. Install the X-Ray SDK and X-Ray Daemon on each service instance
    2. Use AWS Distro for OpenTelemetry (ADOT) with auto-instrumentation
    3. Write custom segments directly to the X-Ray API
    4. Use CloudWatch Logs Insights to trace requests
  3. A developer needs to add custom metadata to X-Ray traces that can be used to filter and search traces later. Which X-Ray concept should they use? [DVA-C02]
    1. Metadata key-value pairs
    2. Subsegments
    3. Annotations
    4. Groups
  4. A company wants a unified view that correlates application traces, CloudWatch metrics, and logs to troubleshoot issues in their distributed application. Which AWS feature provides this capability? [SOA-C02]
    1. X-Ray Trace Map
    2. CloudWatch Dashboards
    3. CloudWatch ServiceLens
    4. X-Ray Insights
  5. A team wants to be automatically notified when their application experiences an increase in fault rates. They are using AWS X-Ray for tracing. Which X-Ray feature, combined with which AWS service, provides proactive anomaly detection and notifications? [SOA-C02]
    1. X-Ray Groups with CloudWatch Alarms
    2. X-Ray Insights with Amazon EventBridge
    3. X-Ray Sampling Rules with SNS
    4. X-Ray Trace Map with CloudWatch Logs
  6. An organization is migrating from X-Ray SDK instrumentation. They want zero-code auto-instrumentation with the ability to send traces to X-Ray and also use CloudWatch Application Signals. Which solution meets these requirements? [DVA-C02]
    1. Install the X-Ray Daemon and configure it to forward to CloudWatch
    2. Use the CloudWatch Logs agent with X-Ray integration
    3. Deploy AWS Distro for OpenTelemetry (ADOT) auto-instrumentation agent
    4. Configure the application to write traces directly to the X-Ray API

References

AWS S3 Subresources

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS S3 Subresources

  • S3 Subresources provides support to store, and manage the bucket configuration information.
  • S3 subresources only exist in the context of a specific bucket or object
  • S3 subresources are associated with buckets and objects.
  • S3 Subresources are subordinates to objects; i.e. they do not exist on their own, they are always associated with some other entity, such as an object or a bucket.
  • S3 supports various options to configure a bucket for e.g., the bucket can be configured for website hosting, configuration added to manage the lifecycle of objects in the bucket, and to log all access to the bucket.

S3 Default Security Settings

  • Starting April 2023, Amazon S3 applies two default security settings for all new S3 buckets:
    • S3 Block Public Access is enabled by default
    • S3 Access Control Lists (ACLs) are disabled by default (Bucket owner enforced setting)
  • Starting January 5, 2023, all new object uploads to S3 are automatically encrypted with server-side encryption using Amazon S3 managed keys (SSE-S3) at no additional cost.
  • Starting April 2026, SSE-C (server-side encryption with customer-provided keys) is disabled by default on all new general purpose buckets. It can be re-enabled if needed.
  • These defaults help enforce security best practices without requiring manual configuration.

S3 Object Lifecycle

Refer blog post @ S3 Object Lifecycle Management

Static Website Hosting

  • S3 can be used for Static Website hosting with Client-side scripts.
  • S3 does not support server-side scripting.
  • S3, in conjunction with Route 53, supports hosting a website at the root domain which can point to the S3 website endpoint
  • S3 website endpoints do not support HTTPS or access points. For HTTPS, use Amazon CloudFront to serve a static website hosted on Amazon S3.
  • For S3 website hosting the content should be made publicly readable which can be provided using a bucket policy.
  • Users can configure the index, and error document as well as configure the conditional routing of an object name
  • Requester Pays buckets do not allow access through the website endpoint. Any request to such a bucket will receive a 403 – Access Denied response
  • AWS Amplify Hosting now integrates with S3 (announced 2024), allowing static websites stored in S3 buckets to be served over a CDN with custom domains, HTTPS, and CI/CD pipelines with just a few clicks.

S3 Versioning

Refer blog post @ S3 Object Versioning

Policy & Access Control List (ACL)

Refer blog post @ S3 Permissions

  • Important (April 2023): ACLs are now disabled by default for all new S3 buckets. S3 Object Ownership is set to “Bucket owner enforced” by default, meaning the bucket owner automatically owns and has full control over every object in the bucket.
  • AWS recommends keeping ACLs disabled and using bucket policies for access management in most modern use cases.
  • ACLs can still be re-enabled by changing the Object Ownership setting if required for legacy compatibility.

CORS (Cross Origin Resource Sharing)

  • All browsers implement the Same-Origin policy, for security reasons, where the web page from a domain can only request resources from the same domain.
  • CORS allows client web applications loaded in one domain access to the restricted resources to be requested from another domain.
  • With CORS support, S3 allows cross-origin access to S3 resources
  • CORS configuration rules identify the origins allowed to access the bucket, the operations (HTTP methods) that would be supported for each origin, and other operation-specific information.
  • In the S3 console, the CORS configuration must be a JSON document (XML format was deprecated).

S3 Access Logs

  • S3 Access Logs enable tracking access requests to an S3 bucket.
  • S3 Access logs are disabled by default.
  • Each access log record provides details about a single access request, such as the requester, bucket name, request time, request action, response status, and error code, etc.
  • Access log information can be useful in security and access audits and also help learn about the customer base and understand the S3 bill.
  • S3 periodically collects access log records, consolidates the records in log files, and then uploads log files to a target bucket as log objects.
  • Logging can be enabled on multiple source buckets with the same target bucket which will have access logs for all those source buckets, but each log object will report access log records for a specific source bucket.
  • Source and target buckets should be in the same region.
  • Source and target buckets should be different to avoid an infinite loop of logs issue.
  • Target bucket can be encrypted using SSE-S3 default encryption. However, Default encryption with AWS KMS keys (SSE-KMS) is not supported.
  • S3 Object Lock cannot be enabled on the target bucket.
  • S3 uses a special log delivery account to write server access logs.
    • AWS recommends updating the bucket policy on the target bucket to grant access to the logging service principal (logging.s3.amazonaws.com) for access log delivery.
    • Access for access log delivery can also be granted to the S3 log delivery group through the bucket ACL. Granting access to the S3 log delivery group using your bucket ACL is not recommended.
  • Access log records are delivered on a best-effort basis. The completeness and timeliness of server logging is not guaranteed i.e. log record for a particular request might be delivered long after the request was actually processed, or it might not be delivered at all.
  • S3 Access Logs can be analyzed using data analysis tools or Amazon Athena.
  • AWS recommends using AWS CloudTrail for logging bucket-level and object-level actions for S3 resources, as it provides more comprehensive logging with identity context.
  • S3 Metadata journal tables (launched 2024) provide another logging option focused on object state changes—capturing storage class transitions, encryption changes, tag modifications, and Object Lock events in query-optimized Parquet format.

Tagging

  • S3 provides the tagging subresource to store and manage tags on a bucket
  • Cost allocation tags can be added to the bucket to categorize and track AWS costs.
  • AWS can generate a cost allocation report with usage and costs aggregated by the tags applied to the buckets.
  • Object tags can also be used for S3 Lifecycle rules, replication rules, access control, and S3 Analytics.

Location

  • AWS region needs to be specified during bucket creation and it cannot be changed.
  • S3 stores this information in the location subresource and provides an API for retrieving this information
  • S3 supports two bucket types:
    • General purpose buckets – the original S3 bucket type, recommended for most use cases, supporting all storage classes except S3 Express One Zone.
    • Directory buckets – use the S3 Express One Zone storage class for single-digit millisecond latency, with data stored in a specific Availability Zone.

Event Notifications

  • S3 notification feature enables notifications to be triggered when certain events happen in the bucket.
  • Notifications are enabled at the Bucket level
  • Notifications can be configured to be filtered by the prefix and suffix of the key name of objects. However, filtering rules cannot be defined with overlapping prefixes, overlapping suffixes, or prefix and suffix overlapping
  • S3 can publish the following events
    • New Object created events
      • Can be enabled for PUT, POST, or COPY operations
      • You will not receive event notifications from failed operations
    • Object Removal events
      • Can publish delete events for object deletion, version object deletion or insertion of delete marker
      • You will not receive event notifications from automatic deletes from lifecycle policies or from failed operations.
    • Restore object events
      • restoration of objects archived to the S3 Glacier storage classes
    • Lifecycle transition events
      • notification when an object is transitioned from one storage class to another by an S3 Lifecycle configuration
    • Lifecycle expiration events
      • notification when S3 Lifecycle deletes an object or creates a delete marker
    • S3 Intelligent-Tiering archive events
      • notification when objects are moved to Archive Access or Deep Archive Access tiers
    • Object tagging events
      • notification when tags are added, updated, or deleted on an object
    • Object ACL events
      • notification when an object ACL is put
    • Replication events
      • for replication configurations that have S3 replication metrics or S3 Replication Time Control (S3 RTC) enabled
  • S3 can publish events to the following destinations
    • SNS topic
    • SQS queue
    • AWS Lambda
    • Amazon EventBridge – allows matching any attribute or combination of attributes (object size, time range, etc.) for filtering before invoking targets. Unlike other destinations, EventBridge does not require selecting specific event types.
  • For S3 to be able to publish events to the destination, the S3 principal should be granted the necessary permissions
  • S3 event notifications are designed to be delivered at least once. Typically, event notifications are delivered in seconds but can sometimes take a minute or longer.

Cross-Region Replication & Same-Region Replication

  • S3 Replication enables automatic, asynchronous copying of objects across S3 buckets in the same or different AWS regions.
  • S3 Cross-Region Replication – CRR is used to copy objects across S3 buckets in different AWS Regions.
  • S3 Same-Region Replication – SRR is used to copy objects across S3 buckets in the same AWS Regions.
  • S3 Replication helps to
    • Replicate objects while retaining metadata
    • Replicate objects into different storage classes
    • Maintain object copies under different ownership
    • Keep objects stored over multiple AWS Regions
    • Replicate objects within 15 minutes (with S3 Replication Time Control – RTC)
  • S3 can replicate all or a subset of objects with specific key name prefixes or tags
  • S3 encrypts all data in transit across AWS regions using SSL
  • Object replicas in the destination bucket are exact replicas of the objects in the source bucket with the same key names and the same metadata.
  • Objects may be replicated to a single destination bucket or multiple destination buckets.
  • S3 Batch Replication allows replication of existing objects that were created before a replication configuration was added, objects that previously failed to replicate, or objects that were already replicated. It uses an S3 Batch Operations job.
  • Two-way (bi-directional) replication enables data to be fully synchronized between two or more buckets, keeping replicas in sync using replica modification sync.
  • Cross-Region Replication can be useful for the following scenarios:-
    • Compliance requirement to have data backed up across regions
    • Minimize latency to allow users across geography to access objects
    • Operational reasons compute clusters in two different regions that analyze the same set of objects
  • Same-Region Replication can be useful for the following scenarios:-
    • Aggregate logs into a single bucket
    • Configure live replication between production and test accounts
    • Abide by data sovereignty laws to store multiple copies
  • Replication Requirements
    • source and destination buckets must be versioning-enabled
    • for CRR, the source and destination buckets must be in different AWS regions.
    • S3 must have permission to replicate objects from that source bucket to the destination bucket on your behalf.
    • If the source bucket owner also owns the object, the bucket owner has full permission to replicate the object. If not, the source bucket owner must have permission for the S3 actions s3:GetObjectVersion and s3:GetObjectVersionACL to read the object and object ACL
    • Setting up cross-region replication in a cross-account scenario (where the source and destination buckets are owned by different AWS accounts), the source bucket owner must have permission to replicate objects in the destination bucket.
    • if the source bucket has S3 Object Lock enabled, the destination buckets must also have S3 Object Lock enabled.
    • destination buckets cannot be configured as Requester Pays buckets
  • Replicated & Not Replicated
    • Only new objects created after you add a replication configuration are replicated. S3 does NOT retroactively replicate objects that existed before you added replication configuration. Use S3 Batch Replication to replicate existing objects.
    • Objects encrypted using SSE-C, SSE-S3, or SSE-KMS can all be replicated.
    • S3 replicates only objects in the source bucket for which the bucket owner has permission to read objects and read ACLs
    • Any object ACL updates are replicated, although there can be some delay before S3 can bring the two in sync. This applies only to objects created after you add a replication configuration to the bucket.
    • S3 does NOT replicate objects in the source bucket for which the bucket owner does not have permission.
    • Updates to bucket-level S3 subresources are NOT replicated, allowing different bucket configurations on the source and destination buckets
    • Only customer actions are replicated & actions performed by lifecycle configuration are NOT replicated
    • S3 does NOT replicate the delete marker by default. However, you can add delete marker replication to non-tag-based rules to override it.
    • S3 does NOT replicate deletion by object version ID. This protects data from malicious deletions.

S3 Inventory

  • S3 Inventory helps manage the storage and can be used to audit and report on the replication and encryption status of the objects for business, compliance, and regulatory needs.
  • S3 inventory provides a scheduled alternative to the S3 synchronous List API operation.
  • S3 inventory provides CSV, ORC, or Apache Parquet output files that list the objects and their corresponding metadata on a daily or weekly basis for an S3 bucket or a shared prefix.
  • S3 Express One Zone directory buckets now also support S3 Inventory (2026).

S3 Metadata

  • Amazon S3 Metadata (launched at re:Invent 2024, GA in January 2025) delivers queryable object metadata in near real-time.
  • S3 Metadata automatically captures metadata from objects as they are uploaded and makes it queryable in a read-only Apache Iceberg table.
  • The metadata schema includes over 20 elements: bucket name, object key, creation/modification time, storage class, encryption status, tags, and user metadata.
  • Metadata tables can be queried using Amazon Athena and other analytics engines.
  • S3 Metadata now supports visibility into all existing objects (not just new/changed objects).
  • S3 Annotations (launched 2026) allow attaching up to 1 GB of rich, queryable context (JSON, XML, YAML, or plain text) directly to S3 objects without re-writing the objects.
  • S3 Metadata provides an alternative to S3 Inventory for real-time metadata analysis, while S3 Inventory is better for scheduled batch reporting.

Requester Pays

  • By default, buckets are owned by the AWS account that created it (the bucket owner) and the AWS account pays for storage costs, downloads, and data transfer charges associated with the bucket.
  • Using Requester Pays subresource:-
    • Bucket owner specifies that the requester requesting the download will be charged for the download
    • However, the bucket owner still pays the storage costs
  • Enabling Requester Pays on a bucket
    • disables anonymous access to that bucket
    • cannot be enabled for end-user logging bucket

Object ACL

Refer blog post @ S3 Permissions

  • Note: Starting April 2023, ACLs are disabled by default on new buckets. AWS recommends using bucket policies instead of ACLs for access management.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. An organization’s security policy requires multiple copies of all critical data to be replicated across at least a primary and backup data center. The organization has decided to store some critical data on Amazon S3. Which option should you implement to ensure this requirement is met?
    1. Use the S3 copy API to replicate data between two S3 buckets in different regions
    2. You do not need to implement anything since S3 data is automatically replicated between regions
    3. Use the S3 copy API to replicate data between two S3 buckets in different facilities within an AWS Region
    4. You do not need to implement anything since S3 data is automatically replicated between multiple facilities within an AWS Region
  2. A customer wants to track access to their Amazon Simple Storage Service (S3) buckets and also use this information for their internal security and access audits. Which of the following will meet the Customer requirement?
    1. Enable AWS CloudTrail to audit all Amazon S3 bucket access.
    2. Enable server access logging for all required Amazon S3 buckets
    3. Enable the Requester Pays option to track access via AWS Billing
    4. Enable Amazon S3 event notifications for Put and Post.
  3. A user is enabling a static website hosting on an S3 bucket. Which of the below mentioned parameters cannot be configured by the user?
    1. Error document
    2. Conditional error on object name
    3. Index document
    4. Conditional redirection on object name
  4. Company ABCD is running their corporate website on Amazon S3 accessed from http//www.companyabcd.com. Their marketing team has published new web fonts to a separate S3 bucket accessed by the S3 endpoint: https://s3-us-west1.amazonaws.com/abcdfonts. While testing the new web fonts, Company ABCD recognized the web fonts are being blocked by the browser. What should Company ABCD do to prevent the web fonts from being blocked by the browser?
    1. Enable versioning on the abcdfonts bucket for each web font
    2. Create a policy on the abcdfonts bucket to enable access to everyone
    3. Add the Content-MD5 header to the request for webfonts in the abcdfonts bucket from the website
    4. Configure the abcdfonts bucket to allow cross-origin requests by creating a CORS configuration
  5. Company ABCD is currently hosting their corporate site in an Amazon S3 bucket with Static Website Hosting enabled. Currently, when visitors go to http://www.companyabcd.com the index.html page is returned. Company C now would like a new page welcome.html to be returned when a visitor enters http://www.companyabcd.com in the browser. Which of the following steps will allow Company ABCD to meet this requirement? Choose 2 answers.
    1. Upload an html page named welcome.html to their S3 bucket
    2. Create a welcome subfolder in their S3 bucket
    3. Set the Index Document property to welcome.html
    4. Move the index.html page to a welcome subfolder
    5. Set the Error Document property to welcome.html
  6. A company needs to replicate existing objects that were uploaded before a replication rule was configured. Which S3 feature should they use?
    1. S3 Cross-Region Replication with versioning
    2. S3 Same-Region Replication with lifecycle policies
    3. S3 Batch Replication
    4. S3 Transfer Acceleration
  7. A company wants to receive S3 event notifications and route them to multiple targets based on object attributes like size and key prefix patterns. Which destination should be configured?
    1. Amazon SNS
    2. Amazon SQS
    3. AWS Lambda
    4. Amazon EventBridge
  8. What security settings are applied by default to all new S3 buckets created after April 2023? (Choose 2)
    1. S3 Block Public Access is enabled
    2. Server-side encryption with KMS keys (SSE-KMS) is applied
    3. ACLs are disabled (Bucket owner enforced)
    4. Versioning is enabled
    5. Cross-region replication is configured

AWS EC2 Amazon Machine Image – AMI

~ Last updated on : ~ jayendrapatil ~ 6 Comments

Amazon Machine Image – AMI

  • An Amazon Machine Image – AMI provides the information required to launch an instance, which is a virtual server in the cloud.
  • An AMI is basically a template and can be used to launch as many instances as needed
  • Within a VPC, instances can be launched from as many different AMIs
  • An AMI includes the following:
    • One or more EBS snapshots, or, for instance-store-backed AMIs, a template for the root volume of the instance for e.g, an operating system, an application server, and applications
    • Launch permissions that control which AWS accounts can use the AMI to launch instances for e.g. AWS account ids whom the AMI is shared
    • A block device mapping that specifies the volumes to attach to the instance when it’s launched
  • Amazon Machine Images can be either
    • AWS managed, provided, and published AMIs
    • Third-party or Community provided public custom AMIs
    • Private AMIs created by other AWS accounts and shared with you
    • Private and Custom AMIs created by you

AMI Types

  • Region & Availability Zone
    • are regional but can be copied over to other regions
  • Operating system
    • are available in a variety of OS flavors for e.g. Linux, windows, etc.
  • Architecture (32-bit, 64-bit x86_64, or 64-bit ARM arm64)
    • ARM-based (arm64) AMIs are used with AWS Graviton processors (Graviton2, Graviton3, Graviton4) for better price-performance
  • Launch Permissions
    • Launch permissions define who has access to the AMI
      • Public – Accessible to all AWS accounts
      • Explicit – Shared with specific AWS accounts, Organizations, or Organizational Units (OUs)
      • Private/Implicit – Owned and available for AMI creator account only
  • Boot Mode
    • AMIs can be configured with a boot mode parameter: legacy-bios, uefi, or uefi-preferred
    • UEFI boot mode is required for Graviton instances and supports features like UEFI Secure Boot and NitroTPM
    • If no boot mode parameter is set, Graviton instances default to uefi, while Intel/AMD default to legacy-bios
  • Root device storage
    • can have EBS or Instance store as the root device storage
    • EBS backed
      • EBS volumes are independent of the EC2 instance lifecycle and can persist independently
      • EBS backed instances can be stopped without losing the volumes
      • EBS instance can also be persisted without losing the volumes on instance termination if the Delete On Termination flag is disabled
      • EBS backed instances boot up much faster than the Instance store backed instances as only the parts required to boot the instance needs to be retrieved from the snapshot before the instance is made available
      • AMI creation is much easier for AMIs backed by EBS. The CreateImage API action creates the EBS-backed AMI and registers it
      • EBS-backed AMIs are the recommended and standard approach for all new workloads
    • Instance Store backed
      • Instance store-backed AMIs are considered end of life and are not recommended for new usage.
      • They are only supported on older instance types: C1, C3, D2, I2, M1, M2, M3, R3, and X1.
      • Instance store is ephemeral storage and is dependent on the lifecycle of the Instance
      • Instance store is deleted if the instance is terminated or if the EBS backed instance, with attached instance store volumes, is stopped
      • Instance store volumes cannot be stopped
      • Instance store volumes have their AMI in S3 and have higher boot times compared to EBS backed instances, as all the parts have to be retrieved from S3 before the instance is made available
      • To create Linux AMIs backed by the instance store, you must create an AMI from your instance on the instance itself using the Amazon EC2 AMI tools.

More detailed @ EBS vs Instance Store

Linux Virtualization Types

  • Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM).
  • Main difference between PV and HVM AMIs is the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.
  • AWS recommends the use of current generation instance types and HVM AMIs for all workloads. PV AMIs are legacy and only supported on older instance types.
  • HVM AMIs
    • HVM AMIs are presented with a fully virtualized set of hardware and boot by executing the master boot record of the root block device of the image.
    • HVM virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification as if it were run on bare-metal hardware.
    • EC2 host system emulates some or all of the underlying hardware that is presented to the guest.
    • HVM guests, unlike PV guests, can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system.
    • HVM AMIs are required to take advantage of enhanced networking and GPU processing. In order to pass through instructions to specialized network and GPU devices, the OS needs to be able to have access to the native hardware platform; HVM virtualization provides this access.
    • All current generation instance types support HVM AMIs only. HVM is the only virtualization type supported on Nitro-based instances.
  • PV AMIs
    • PV AMIs are legacy. Historically, PV guests had better performance than HVM guests in many cases, but because of enhancements in HVM virtualization and the availability of PV drivers for HVM AMIs, this is no longer true.
    • PV AMIs boot with a special boot loader called PV-GRUB, which starts the boot cycle and then chain loads the kernel specified in the menu.lst file on your image.
    • Paravirtual guests can run on host hardware that does not have explicit support for virtualization, but they cannot take advantage of special hardware extensions such as enhanced networking or GPU processing
    • PV is only supported on older instance types such as C1, C3, M1, M2, M3, and T1.

AMI Lifecycle

  • AMI lifecycle includes the following stages:
    • Create and register an AMI
    • Launch new instances (You can also launch instances from an AMI if the AMI owner grants you launch permissions)
    • Copy an AMI to the same region or to different regions
    • Deprecate the AMI to mark it as outdated
    • Disable the AMI to prevent new launches while retaining it
    • Deregister the AMI when no longer needed

AMI Lifecycle

AMI Deprecation

  • An AMI can be deprecated to indicate that it is out of date and should not be used.
  • Deprecated AMIs are hidden from AMI listings, but users and services can continue to use deprecated AMIs if they know the AMI ID.
  • Public AMIs are automatically deprecated after 2 years from their creation date.
  • Deprecation can be set to a future date (up to 10 years for private AMIs, 2 years for public AMIs).
  • Deprecation does not affect running instances launched from the AMI.

AMI Disable

  • An AMI can be disabled to prevent new instance launches while retaining the AMI and its snapshots.
  • Disabling an AMI changes its state to disabled, makes it private (removes all sharing permissions), and prevents any new EC2 instance launches.
  • Useful for retaining old AMIs for compliance or audit purposes while preventing accidental usage.
  • A disabled AMI can be re-enabled later if needed.

AMI Deregistration Protection

  • AMIs can be marked as protected from accidental deregistration (launched May 2024).
  • A protected AMI cannot be deregistered until deregistration protection is explicitly disabled.
  • Supports a 24-hour cooldown period — after disabling protection, you must wait 24 hours before the AMI can be deregistered.
  • Deregistration protection is turned off by default on all existing and new AMIs.

AMI Creation

EBS-Backed Linux AMI

Screen Shot 2016-04-12 at 7.39.18 AM.png

  • EBS-Backed Linux AMI can be created from the instance directly or from the EBS snapshot
  • EBS-backed Linux AMI creation process:-
    1. Select an AMI #1 similar to what you want to have your new AMI #2
    2. Launch an Instance from AMI #1 and configure it accordingly
    3. Stop the instance to ensure data integrity
    4. Create AMI #2 OR create an EBS snapshot and then create an AMI #2 from the snapshot
    5. Amazon automatically register the EBS-backed AMI
    6. AMI #2 can be now used to launch new instances
  • By default, EC2 shuts down the instance, takes snapshots of any attached volumes, creates and registers the AMI, and then reboots the instance.
  • No Reboot option
    • No Reboot option prevents the instance from shut down & reboot
    • AMI will be crash consistent as all the volumes are snapshotted at the same time
    • However, AMI is not application consistent as all the operating system buffers are not flushed to disk before the snapshots are created and file system integrity can’t be guaranteed
  • EC2 creates snapshots of the instance’s root volume and any other EBS volumes attached to the instance. If any volumes attached to the instance are encrypted, the new AMI only launches successfully on instances that support Amazon EBS encryption
  • For any additional instance-store volumes or EBS volumes, the block device mapping for the new AMI contains information for these volumes and the block device mappings for instances that you launch from the new AMI automatically contain information for these volumes.
  • While data on EBS volumes persist, the Instance-store volumes specified in the block device mapping for the new instance are new and don’t contain any data from the instance store volumes of the instance you used to create the AMI.
  • It’s more efficient to create an EBS-backed AMI with EBS snapshots already taken as the snapshot created during AMI creation is just an incremental one
  • You are charged for the storage of both the image and the snapshots

Instance Store-Backed Linux AMI

Screen Shot 2016-04-12 at 7.39.28 AM.png

  • Note: Instance store-backed AMIs are considered end of life and not recommended for new usage. They are only supported on C1, C3, D2, I2, M1, M2, M3, R3, and X1 instance types.
  • Instance Store-Backed Linux AMI creation process
    1. Select an AMI #1 similar to what you want to have your new AMI #2
    2. Launch an Instance from AMI #1 and configure the instance accordingly
    3. Bundle the Instance. It takes several minutes for the bundling process to complete.
    4. After the process completes, you have a bundle, which consists of an image manifest (image.manifest.xml) and files (image.part.xx) that contain a template for the root volume.
    5. Upload the bundle to the S3 bucket
    6. Register the Instance Store-backed AMI.
    7. Launching an instance using the new AMI #2, the root volume for the instance is created using the bundle that you uploaded to S3.
  • Charges are incurred for the storage space used by the bundle in S3 until deleted
  • For additional instance store volumes, not root volumes, the block device mapping for the new AMI contains information for these volumes and the block device mappings for instances that you launch from the new AMI automatically contain information for these volumes.

Amazon EBS-backed AMI vs Instance Store-backed AMI

Deregistering AMI

  • Charges are incurred on the AMI created and they can be deregistered, if not needed.
  • Deregistering an AMI does not delete the EBS snapshots or the bundles in the S3 buckets and have to be removed separately
  • Once deregistered, new instances cannot be launched from the AMI. However, it does not impact already created instances from the AMI
  • An AMI that has deregistration protection enabled cannot be deregistered until protection is disabled.
  • Clean up EBS-Backed AMI

Screen Shot 2016-04-12 at 8.11.28 AM.png

    • Deregister the EBS-Backed AMI
    • Delete the EBS Snapshot, as deregistering the AMI doesn’t impact the snapshot
  • Clean up Instance Store-backed AMI

Screen Shot 2016-04-12 at 8.11.21 AM.png

    • Deregister the Instance Store-Backed AMI
    • Delete the bundle from the S3 bucket, as deregistering the AMI doesn’t affect the bundles stored in the S3 bucket

AMI Lineage and Ancestry

  • AMI Lineage (launched Nov 2024) provides source details for AMIs, enabling tracing of copied or derived AMIs back to their original source.
  • AMI Ancestry (launched Nov 2025) extends this by enabling complete lineage tracing from any AMI back to the root AMI through each preceding generation.
  • Key benefits:
    • Track AMI derivatives to ensure compliance with internal policies
    • Identify potentially vulnerable AMIs when a security issue is found in an ancestor AMI
    • Maintain visibility of AMI origins across multiple Regions
  • When an AMI is created or copied, the new AMI retains the ID and Region of its source (parent) AMI.
  • Ancestry information is maintained even if intermediate generation AMIs are deleted.
  • Use the GetImageAncestry API or describe-image-ancestry CLI command to retrieve lineage information.

AMI Usage Monitoring

  • Last Launched Time (launched 2022, enhanced May 2024)
    • Tracks when an AMI was last used to launch an EC2 instance
    • Helps identify unused AMIs for cleanup and cost optimization
    • Available via DescribeImages API and EC2 console
  • AMI Usage Reports (launched Sep 2025)
    • Generate reports listing accounts using your AMIs in EC2 instances and launch templates
    • Check utilization of any AMI within your account across instances, launch templates, Image Builder recipes, and SSM parameters
    • Reports are automatically deleted after 30 days

AMI Governance – Allowed AMIs

  • Allowed AMIs (launched Dec 2024) is an account-wide setting that enables limiting the discovery and use of AMIs within AWS accounts.
  • Specify criteria that AMIs must meet to be visible and available within the account.
  • Criteria parameters include:
    • ImageProviders – AMI providers (AWS account IDs, amazon, aws-marketplace, aws-backup-vault aliases)
    • ImageNames – AMI names with wildcard support
    • MarketplaceProductCodes – AWS Marketplace product codes
    • CreationDateCondition – Maximum age for allowed AMIs
    • DeprecationTimeCondition – Maximum period since deprecation
  • Operational states:
    • Enabled – Criteria enforced, only allowed AMIs visible and launchable
    • Disabled – No restrictions
    • Audit mode – Criteria evaluated but not enforced (for testing)
  • Does NOT restrict AMIs owned by your own account — only controls public AMIs and AMIs shared with your account.
  • Can be configured via declarative policies in AWS Organizations for multi-account and multi-region enforcement.
  • Integrates with AWS Config (Mar 2025) using the ec2-instance-launched-with-allowed-ami rule.

AMI Block Public Access

  • AMI Block Public Access (BPA), launched Sep 2023, is an account-wide setting that prevents public sharing of AMIs in a region.
  • Enabled by default for all new AWS accounts and existing accounts that have not owned a public AMI since July 2023.
  • When enabled, prevents making any AMI public in that region.
  • Existing public AMIs remain publicly available — BPA only blocks new public sharing.
  • Must be explicitly disabled if you need to share AMIs publicly.

Shared AMIs

  • Shared AMI is an AMI that can be created and shared with others for use
  • A Shared AMI with all the components needed can be used to get started and then add custom components as and when needed
  • Shared AMI can be risky as Amazon does not perform detailed checks and vouch for the integrity and security of these AMIs
  • Before using a Shared AMI, check for any pre-installed credentials that would allow unwanted access to the instance by a third party and no pre-configured remote logging that could transmit sensitive data to a third party
  • Amazon allows you to share an image, by defining launch permissions, to all (making it public) or only to specific AWS accounts, Organizations, or Organizational Units (OUs)
  • Launch permissions work at the AWS account level, or at the AWS Organizations/OU level for broader sharing.
  • Sharing an image does not affect the ownership of the AMI
  • Only AMIs with unencrypted volumes or encrypted with a customer-managed key can be shared.
  • AMIs are a regional resource. Therefore, sharing an image makes it available in that Region. To make an image available in a different Region, copy the AMI to the Region and then share it.
  • Share with Organizations/OUs
    • AMIs can be shared with an entire AWS Organization or specific OUs using the Org ID or OU ID in launch permissions.
    • When shared with an organization or OU, all children accounts gain access to the AMI.
    • If shared with encrypted snapshots, the Organizations or OUs must also be allowed to use the KMS keys used to encrypt the snapshots.
  • Make AMI Public
    • AMIs with encrypted volumes cannot be made public.
    • AMI with product codes or snapshots of an encrypted volume can’t be made public; they can be shared only with specific AWS accounts.
    • AMI Block Public Access must be disabled in the region before an AMI can be made public.
  • Guidelines for Shared Linux AMIs
    • Update the AMI Tools at Boot-Time
      • Update the AMI tools or any software during startup.
      • Take into account the software updates do not break any software and consider the WAN traffic as the downloads will be charged to the AMI user
    • Disable Password-Based Remote Logins for Root
      • Fixed root passwords can be a security risk and need to be disabled
    • Disable Local Root Access
      • disable direct root logins
    • Remove SSH Host Key Pairs
      • Remove the existing SSH host key pairs located in /etc/ssh, which forces SSH to generate new unique SSH key pairs when someone launches an instance using your AMI, improving security and reducing the likelihood of “man-in-the-middle” attacks
    • Install Public Key Credentials
      • EC2 allows users to specify a public-private key pair name when launching an instance.
      • A valid key pair name needs to be provided when launching an instance, the public key, the portion of the key pair that EC2 maintains on the server, is made available to the instance through an HTTP query against the instance metadata and appended to the authorized keys
      • Users can launch instances of the AMI with a key pair and log in without requiring a root password
    • Disabling sshd DNS Checks (Optional)
      • Disabling sshd DNS checks slightly weaken the sshd security. However, if DNS resolution fails, SSH logins still work. If you do not disable sshd checks, DNS resolution failures prevent all logins.
    • Identify Yourself
      • AMI is only represented by an account ID without any further information, so it is better to provide more information to help describe the AMI
    • Protect Yourself
      • Don’t store any sensitive data or software on the AMI
      • Exclude & Skip any directories holding sensitive data or secret information and delete the shell history before creating an AMI

AMIs with Encrypted Snapshots

  • AMIs, with EBS backed snapshots, can be attached with both an encrypted root and data volume
  • AMIs copy image can be used to create AMIs with encrypted snapshots from AMIs with unencrypted snapshots. By default, copy image preserves the encryption status of the snapshots
  • Snapshots can be encrypted with either the default AWS managed key or a customer managed KMS key

AMI Copying

  • EBS-backed AMIs and instance store-backed AMIs can be copied.
  • Copying an AMI
    • An identical target AMI is created, but with its own unique identifier
    • For EBS backed AMI, identical but distinct root and data snapshots are created
    • Encryption status of the snapshots are preserved
    • However, Launch permissions, user-defined tags, or S3 bucket permissions are not copied from the source AMI to the new AMI. After the copy operation is complete, different launch permissions, user-defined tags, and S3 bucket permissions to the new AMI
  • Source AMI can be deregistered without any impact to the Target AMI
  • AMIs owned or shared with proper permissions can be copied
  • AMIs are created specific to a region and can be copied within or across regions which can help to aid in the consistent global deployment and build highly scalable and available applications
  • AMI copy image can be used to encrypt an AMI from an unencrypted AMI
  • AMIs with encrypted snapshots can be copied and also encryption status changed during the copy process.
  • AWS Marketplace AMI cannot be copied, regardless of whether obtained directly or shared. Instead, launch an EC2 instance using the AWS Marketplace AMI and then create an AMI from the instance.
  • AMI Lineage is maintained through copies — the copied AMI retains the source AMI ID and Region for tracking.

Amazon Linux 2023

⚠️ Amazon Linux Version Status:

  • Amazon Linux 1 (AL1) reached End of Life on December 31, 2023. No security updates since January 1, 2024.
  • Amazon Linux 2 (AL2) will reach End of Life on June 30, 2026. Migrate to AL2023.
  • Amazon Linux 2023 (AL2023) is the current recommended version with support until June 30, 2029.

Amazon Linux 2023 (AL2023)

Amazon Linux 2023 is the latest generation of Amazon Linux, a cloud-optimized Linux distribution with long-term support provided by AWS.

  • A stable, secure, and high-performance execution environment for applications running on EC2.
    • does not allow remote root SSH by default.
    • Password authentication is disabled to prevent brute-force password attacks.
    • Instances launched using Amazon Linux AMI must be provided with a key pair at launch to enable SSH logins
    • Inbound security group must allow SSH access
    • By default, the only account that can log in remotely using SSH is ec2-user; this account also has sudo privileges.
    • are configured to download and install security updates at launch time.
  • Provided at no additional charge to Amazon EC2 users.
  • Key improvements over Amazon Linux 2:
    • Deterministic updates through versioned repositories (locking to a specific version)
    • FIPS 140-3 certification for enhanced security compliance
    • Kernel livepatch support for applying security patches without rebooting
    • SELinux support in permissive mode by default
    • Uses dnf package manager (replaces yum)
    • Uses IMDSv2 by default (Instance Metadata Service Version 2)
    • Modern system components with regular major version updates
  • Support lifecycle: 5 years per major version (2 years standard + 3 years maintenance)
  • Includes pre-installed packages to enable easy integration with AWS services, such as the AWS CLI, Amazon EC2 API tools, the Boto3 library for Python, and SSM Agent.

Amazon Linux 2 (AL2) – End of Life June 30, 2026

  • Amazon Linux 2 continues to receive maintenance updates until June 30, 2026.
  • AWS recommends migrating to Amazon Linux 2023 for new workloads.
  • ECS-optimized AL2 AMIs and EKS-optimized AL2 AMIs also end support in 2025-2026.

EC2 Image Builder

  • EC2 Image Builder is a fully managed AWS service that makes it easier to automate the creation, management, and deployment of customized, secure, and up-to-date server images that are pre-installed and pre-configured with software and settings to meet specific IT standards
  • EC2 Image Builder simplifies the building, testing, and deployment of Virtual Machine and container images for use on AWS or on-premises.
  • Image Builder significantly reduces the effort of keeping images up-to-date and secure by providing a simple graphical interface, built-in automation, and AWS-provided security settings.
  • Image Builder removes any manual steps for updating an image and you do not have to build your own automation pipeline.
  • Image Builder provides a one-stop-shop to build, secure, and test up-to-date Virtual Machine and container images using common workflows.
  • Image Builder allows image validation for functionality, compatibility, and security compliance with AWS-provided tests and your own tests before using them in production.
  • Image Builder is offered at no cost, other than the cost of the underlying AWS resources used to create, store, and share the images.
  • Lifecycle Management (launched Nov 2023)
    • Automates deprecating, disabling, and deleting outdated images and associated resources
    • Supports wildcard patterns in lifecycle policies (enhanced Feb 2026)
    • Helps save costs by cleaning up unused images that accumulate storage charges
  • Flexible AMI Distribution (launched Nov 2025)
    • Distribute existing AMIs to multiple regions and accounts without running a full pipeline build
    • Specify AMI and distribution configuration, and Image Builder handles copying and sharing
  • AWS Marketplace Components (launched 2025)
    • Procure third-party components from AWS Marketplace directly in the Image Builder console
    • Streamlines AMI creation with pre-built software components
  • Pipeline Management Enhancements (launched Oct 2025)
    • Automatically disables pipelines after consecutive failures
    • Custom log groups for image pipelines for better visibility
  • Supports sharing AMIs with AWS Organizations and Organizational Units

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has launched an EC2 instance from an instance store backed AMI. The infrastructure team wants to create an AMI from the running instance. Which of the below mentioned credentials is not required while creating the AMI?
    1. AWS account ID
    2. 509 certificate and private key
    3. AWS login ID to login to the console
    4. Access key and secret access key
  2. A user has launched an EC2 Windows instance from an instance store backed AMI. The user wants to convert the AMI to an EBS backed AMI. How can the user convert it?
    1. Attach an EBS volume to the instance and unbundle all the AMI bundled data inside the EBS
    2. A Windows based instance store backed AMI cannot be converted to an EBS backed AMI
    3. It is not possible to convert an instance store backed AMI to an EBS backed AMI
    4. Attach an EBS volume and use the copy command to copy all the ephemeral content to the EBS Volume
  3. A user has launched two EBS backed EC2 instances in the US-East-1a region. The user wants to change the zone of one of the instances. How can the user change it?
    1. Stop one of the instances and change the availability zone
    2. The zone can only be modified using the AWS CLI
    3. From the AWS EC2 console, select the Actions – > Change zones and specify new zone
    4. Create an AMI of the running instance and launch the instance in a separate AZ
  4. A user has launched a large EBS backed EC2 instance in the US-East-1a region. The user wants to achieve Disaster Recovery (DR) for that instance by creating another small instance in Europe. How can the user achieve DR?
    1. Copy the running instance using the “Instance Copy” command to the EU region
    2. Create an AMI of the instance and copy the AMI to the EU region. Then launch the instance from the EU AMI
    3. Copy the instance from the US East region to the EU region
    4. Use the “Launch more like this” option to copy the instance from one region to another
  5. A user has launched an EC2 instance store backed instance in the US-East-1a zone. The user created AMI #1 and copied it to the Europe region. After that, the user made a few updates to the application running in the US-East-1a zone. The user makes an AMI#2 after the changes. If the user launches a new instance in Europe from the AMI #1 copy, which of the below mentioned statements is true?
    1. The new instance will have the changes made after the AMI copy as AWS just copies the reference of the original AMI during the copying. Thus, the copied AMI will have all the updated data
    2. The new instance will have the changes made after the AMI copy since AWS keeps updating the AMI
    3. It is not possible to copy the instance store backed AMI from one region to another
    4. The new instance in the EU region will not have the changes made after the AMI copy
  6. George has shared an EC2 AMI created in the US East region from his AWS account with Stefano. George copies the same AMI to the US West region. Can Stefano access the copied AMI of George’s account from the US West region?
    1. No, copy AMI does not copy the permission
    2. It is not possible to share the AMI with a specific account
    3. Yes, since copy AMI copies all private account sharing permissions
    4. Yes, since copy AMI copies all the permissions attached with the AMI
  7. EC2 instances are launched from Amazon Machine images (AMIS). A given public AMI can:
    1. be used to launch EC2 Instances in any AWS region.
    2. only be used to launch EC2 instances in the same country as the AMI is stored.
    3. only be used to launch EC2 instances in the same AWS region as the AMI is stored. (An AMI is tied to the region where its files are located within Amazon S3)
    4. only be used to launch EC2 instances in the same AWS availability zone as the AMI is stored.
  8. A company wants to ensure that only approved AMIs can be used to launch EC2 instances in their AWS account. They want to restrict the use of community AMIs and only allow AMIs from trusted providers. Which feature should they use?
    1. AMI Block Public Access
    2. AMI Deprecation
    3. Allowed AMIs
    4. AMI Deregistration Protection
  9. An organization needs to track the complete lineage of an AMI that has been copied across multiple regions over several years. Which AWS feature provides this capability?
    1. AMI Last Launched Time
    2. AMI Usage Reports
    3. AMI Deprecation
    4. AMI Ancestry
  10. A team wants to prevent critical production AMIs from being accidentally deregistered while still allowing cleanup of development AMIs. What is the most appropriate approach?
    1. Use IAM policies to deny DeregisterImage on all AMIs
    2. Disable the AMIs instead of deregistering them
    3. Enable deregistration protection on production AMIs
    4. Use AMI Block Public Access
  11. Which of the following statements about Amazon Linux versions is correct? (Choose 2)
    1. Amazon Linux 1 continues to receive security updates
    2. Amazon Linux 2023 is supported until June 2029
    3. Amazon Linux 2 has no announced end of life date
    4. Amazon Linux 2 reaches end of life on June 30, 2026
    5. Amazon Linux 2023 uses yum as its package manager
  12. A security team wants to disable an old AMI so no new instances can be launched from it, but needs to retain it for compliance auditing. Which approach should they use?
    1. Deregister the AMI and keep the snapshots
    2. Remove all launch permissions from the AMI
    3. Set the AMI to disabled state
    4. Deprecate the AMI

References

Amazon CloudWatch Agent

~ Last updated on : ~ jayendrapatil ~ 1 Comment

Amazon CloudWatch Agent

  • CloudWatch Agent is a unified software component that collects metrics, logs, and traces from EC2 instances, on-premises servers, and containerized applications and sends them to CloudWatch and AWS X-Ray.
  • CloudWatch agent helps to
    • Collect internal system-level metrics from EC2 instances across operating systems. The metrics can include in-guest metrics, in addition to the metrics for EC2 instances.
    • Collect system-level metrics from on-premises servers. These can include servers in a hybrid environment as well as servers not managed by AWS.
    • Retrieve custom metrics from the applications or services using the StatsD and collectd protocols. StatsD is supported on both Linux servers and servers running Windows Server. collectd is supported only on Linux servers.
    • Collect logs from EC2 instances and on-premises servers, running either Linux or Windows Server.
    • Collect traces from OpenTelemetry or X-Ray client SDKs and send them to AWS X-Ray (agent version 1.300025.0 and later).
    • Collect metrics for individual processes using the procstat plugin stored in the procstat namespace.
    • Collect NVIDIA GPU metrics including utilization, memory usage, temperature, and power draw from accelerated EC2 instances.
  • Default namespace for metrics collected by the agent is CWAgent, although a different namespace can be configured.
  • Logs collected by the unified agent are processed and stored in CloudWatch Logs.
  • Agent can be installed on Amazon Linux 2, Amazon Linux 2023, and all supported operating systems (Linux, Windows Server, macOS), manually or using AWS Systems Manager.
  • CloudWatch agent needs permissions to write metrics/logs to CloudWatch and traces to X-Ray. An IAM role for EC2 instances or an IAM user for on-premises servers should be assigned.
  • AWS provides managed IAM policies for the agent:
    • CloudWatchAgentServerPolicy – allows the agent to read configuration from SSM Parameter Store and publish metrics, logs, and traces to CloudWatch and X-Ray. Attach to all instances running the agent.
    • CloudWatchAgentAdminPolicy – includes additional permissions to write agent configuration to SSM Parameter Store. Attach only to the instance used for creating/storing agent configuration.
  • The older CloudWatch Logs agent (awslogs) is deprecated and no longer supported. Use the unified CloudWatch agent instead.

CloudWatch Agent

CloudWatch Agent Configuration

  • Agent configuration is defined in a JSON file with three main sections:
    • agent – general configuration such as metrics collection interval, run_as_user, and debug logging.
    • metrics – specifies which system-level and custom metrics to collect.
    • logs – specifies which log files or Windows event logs to collect.
    • traces – configures trace collection using OpenTelemetry Protocol (OTLP) or X-Ray SDK.
  • Configuration can be created using the agent configuration wizard (amazon-cloudwatch-agent-config-wizard).
  • Configuration can be stored in AWS Systems Manager Parameter Store for centralized fleet management. Parameter names must start with AmazonCloudWatch-.
  • Multiple configuration files can be appended together for modular configuration management.

In-Console Agent Management (2025)

  • CloudWatch provides an in-console experience for automated installation and configuration of the agent on EC2 instances (launched November 2025).
  • Features include:
    • Fleet Visibility – view agent status across your entire EC2 fleet.
    • Automatic Workload Detection – detects running applications and services (NGINX, Tomcat, JVM, Kafka, NVIDIA GPU) and recommends monitoring configurations.
    • One-Click Installation – deploy the agent to individual instances without manual SSH or SSM commands.
    • Tag-Based Policies – create automated fleet-wide management policies that apply to new instances, including auto-scaling instances.
    • Visual Configuration Editor (April 2026) – build agent configurations graphically, selecting metrics, log sources, and deployment targets without hand-editing JSON.
  • Accessible from the EC2 console → instance detail page → Monitoring tab.
  • Available in all AWS Commercial Regions at no additional cost (standard CloudWatch pricing applies for collected telemetry).

OpenTelemetry and Traces Support

  • CloudWatch agent version 1.300025.0+ supports collecting traces from OpenTelemetry SDKs or X-Ray client SDKs.
  • Supports the OpenTelemetry Protocol (OTLP) for receiving metrics and traces.
  • Can act as an OTLP collector endpoint, allowing applications instrumented with OpenTelemetry to send telemetry directly to the CloudWatch agent.
  • Traces are sent to AWS X-Ray for distributed tracing and service map visualization.
  • Metrics received via OTLP are published to CloudWatch Metrics.
  • Enables single-agent deployment replacing the need for separate X-Ray daemon and ADOT collector in many scenarios.

CloudWatch Observability Solutions

  • CloudWatch provides pre-built observability solutions (launched November 2024) that offer workload-specific agent configurations and dashboards.
  • Available solutions include:
    • Amazon EC2 Health – system-level metrics and dashboards.
    • NVIDIA GPU on EC2 – GPU utilization, memory, temperature, and power metrics.
    • NGINX on EC2 – web server monitoring with traffic analysis.
    • Apache Tomcat on EC2 – server monitoring with JVM performance metrics.
    • JVM on EC2 – Java Virtual Machine heap, GC, and thread metrics.
    • Apache Kafka on EC2 – broker and topic monitoring.
  • Each solution includes pre-configured agent configuration, recommended metrics, and a curated CloudWatch dashboard.
  • Solutions are deployed through the in-console agent management experience.

Container Insights Integration

  • CloudWatch agent is used for Container Insights to collect infrastructure metrics from containerized workloads.
  • Amazon EKS:
    • Deployed via the Amazon CloudWatch Observability EKS add-on.
    • Collects cluster, node, pod, and container-level metrics.
    • Container Insights with enhanced observability provides additional dimensions and deep container-level visibility.
    • Supports Windows worker nodes.
  • Amazon ECS:
    • Container Insights with enhanced observability for ECS (December 2024) supports EC2 and Fargate launch types.
    • Auto-collects detailed infrastructure telemetry from cluster level down to container level.
    • Provides curated dashboards for faster problem isolation.

CloudWatch Application Signals

  • Application Signals is an APM capability that uses the CloudWatch agent for automatic instrumentation of applications.
  • Automatically collects metrics and traces without code changes using AWS Distro for OpenTelemetry (ADOT) auto-instrumentation.
  • Provides key metrics: call volume, availability, latency, faults, and errors.
  • Supports Java, Python, .NET, and Node.js applications.
  • Works on EKS (with auto-monitor support since May 2025), ECS, and EC2.
  • Enables Service Level Objectives (SLOs) for tracking application performance against business goals.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company has a set of servers sitting in AWS and a set of them sitting in their On-premise locations. They want to monitor the system-level metrics for both sets of servers and have a unified dashboard for monitoring. As a system administrator, which of the following can help in this regard?
    1. Install the CloudWatch agent on both sets of servers
    2. Migrate the on-premise servers to AWS to ensure they can be monitored
    3. Setup the metrics dashboard in CloudWatch
    4. Setup the metrics dashboard in AWS Inspector
    5. Setup the metrics dashboard in AWS Config
  2. A Developer has a legacy application that is hosted on-premises. Other applications hosted on AWS depend on the on-premises application for proper functioning. In case of any application errors, the Developer wants to be able to use Amazon CloudWatch to monitor and troubleshoot all applications from one place. How can the Developer accomplish this?
    1. Install an AWS SDK on the on-premises server to automatically send logs to CloudWatch.
    2. Download the CloudWatch agent to the on-premises server. Configure the agent to use IAM user credentials with permissions for CloudWatch.
    3. Upload log files from the on-premises server to Amazon S3 and have CloudWatch read the files.
    4. Upload log files from the on-premises server to an Amazon EC2 instance and have the instance forward the logs to CloudWatch.
  3. A company runs a fleet of EC2 instances hosting Java applications behind an Application Load Balancer. The operations team needs to monitor application-level metrics such as JVM heap usage, garbage collection times, and thread counts in CloudWatch. What is the MOST operationally efficient approach?
    1. Write a custom script to parse JVM metrics and publish them using the PutMetricData API.
    2. Use the CloudWatch agent with the JVM observability solution to automatically collect and visualize JVM metrics.
    3. Install a third-party monitoring agent and export metrics to CloudWatch using metric streams.
    4. Enable detailed monitoring on the EC2 instances to capture JVM metrics.
  4. A DevOps engineer needs to deploy the CloudWatch agent across 200 EC2 instances with consistent configuration. The instances are launched by Auto Scaling groups, and new instances must automatically receive the same monitoring configuration. What approach should the engineer use?
    1. Include the agent installation in the AMI and store the configuration file locally on each instance.
    2. Use a Lambda function triggered by Auto Scaling lifecycle hooks to install and configure the agent.
    3. Store the agent configuration in SSM Parameter Store and use the in-console agent management with tag-based policies for automated fleet-wide deployment.
    4. Create a cron job on each instance to pull the latest configuration from S3 every hour.
  5. A company wants to collect both application traces and system metrics from their EC2 instances using a single agent. They are using OpenTelemetry-instrumented applications. Which CloudWatch agent capability supports this requirement?
    1. Configure the CloudWatch agent with StatsD protocol to receive trace data.
    2. Install both the CloudWatch agent and X-Ray daemon as separate processes.
    3. Configure the CloudWatch agent (version 1.300025.0+) with OTLP support to collect both metrics and traces, sending traces to X-Ray.
    4. Use CloudWatch Embedded Metric Format to combine traces with metric data.

References

AWS Macie

Amazon Macie
~ Last updated on : ~ jayendrapatil

AWS Macie

  • Macie is a data security service that discovers sensitive data by using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks.
  • provides an inventory of the S3 general purpose buckets and automatically evaluates and monitors the buckets for security and access control.
  • automates the discovery, classification, and reporting of sensitive data.
  • generates a finding for you to review and remediate as necessary if it detects a potential issue with the security or privacy of the data, such as a bucket that becomes publicly accessible.
  • provides multi-account support using AWS Organizations to enable Macie across all of the accounts.
  • is a regional service and must be enabled on a region-by-region basis and helps view findings across all the accounts within each Region.
  • supports VPC Interface Endpoints and endpoint policies to access Macie privately from a VPC without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
  • can perform preventative control monitoring for up to 10,000 S3 general purpose buckets per account.
  • stores policy and sensitive data findings for 90 days.
  • offers a 30-day free trial that includes automated sensitive data discovery and S3 bucket-level evaluation, plus 1 GB of data processed per month at no cost (free tier does not expire).
  • integrates with AWS Security Hub, Amazon EventBridge, and AWS User Notifications for centralized monitoring and remediation.

Amazon Macie

Macie Sensitive Data Discovery

  • Macie provides two ways to discover sensitive data:
    • Automated Sensitive Data Discovery – continuously evaluates S3 bucket inventory, samples and analyzes representative objects, and builds sensitivity profiles for each bucket.
    • Sensitive Data Discovery Jobs – on-demand, daily, weekly, or monthly jobs that analyze all or a subset of objects in specified S3 buckets.
  • Macie uses Managed Data Identifiers (built-in ML and pattern matching) to detect common sensitive data types including:
    • Personally identifiable information (PII) – names, addresses, passport numbers, national IDs
    • Financial data – credit card numbers, bank account numbers, IBANs (50+ countries)
    • Credentials – AWS secret keys, API keys (Google Cloud, Stripe), HTTP authorization headers, JSON Web Tokens
  • Custom Data Identifiers allow detection of organization-specific sensitive data using regex patterns, keywords, and proximity rules.
  • Allow Lists define text or patterns for Macie to ignore, enabling exceptions for known safe data (e.g., public representative names, test data).
  • Macie supports analysis of objects encrypted with SSE-S3, SSE-KMS, and DSSE-KMS (dual-layer server-side encryption).
  • Supports S3 storage classes including Standard, Intelligent-Tiering, and S3 Glacier Instant Retrieval.

Automated Sensitive Data Discovery

  • Continually evaluates and samples S3 objects across all buckets, providing ongoing discovery without manual job creation.
  • Builds an interactive data map of where sensitive data resides across accounts.
  • Provides a sensitivity score for each bucket (1-100) with a corresponding sensitivity label.
  • Administrators can enable/disable automated discovery for individual accounts in an organization.
  • Member accounts have read access to statistics and inventory data produced by automated discovery.
  • Uses a dynamic, recommended default set of managed data identifiers optimized for common sensitive data categories.
  • Resource coverage page provides unified view of coverage statistics and remediation guidance for analysis issues.

Sensitive Data Discovery Jobs

  • Jobs can analyze data across up to 1,000 buckets spanning up to 1,000 accounts in an organization.
  • Can specify which managed data identifiers a job should use, or use the recommended set.
  • Support runtime criteria for dynamic bucket selection based on inventory changes.
  • Can use S3 object prefixes for custom include/exclude criteria to refine scope.
  • Jobs can be paused and resumed.
  • Estimated costs are calculated and displayed during job creation.
  • CloudWatch Logs can be used to monitor and analyze events during job execution.

Macie Findings

  • Macie generates two categories of findings:
    • Policy Findings – from continuous monitoring of S3 bucket configurations and policies (no active scanning required).
    • Sensitive Data Findings – from discovery jobs or automated discovery that inspects object content.
  • Policy finding types include:
    • Policy:IAMUser/S3BlockPublicAccessDisabled
    • Policy:IAMUser/S3BucketPublic
    • Policy:IAMUser/S3BucketReplicatedExternally
    • Policy:IAMUser/S3BucketSharedExternally
    • Policy:IAMUser/S3BucketSharedWithCloudFront – indicates bucket shared with CloudFront OAI or OAC.
    • Policy:IAMUser/S3BucketEncryptionDisabled
  • Findings are retained for 90 days and can be viewed in the console or via API.
  • Findings can be published to AWS Security Hub and Amazon EventBridge for centralized monitoring.
  • Findings are consolidated by object or bucket with severity-based prioritization.
  • Sensitive Data Samples – Macie can retrieve and reveal samples of sensitive data reported in findings to verify the nature of detected data. Supports configuring an IAM role for cross-account access.
  • Suppression rules (filter rules) can be used to automatically archive findings that match specific criteria.

Macie Multiple Accounts

  • Macie provides multi-account support using AWS Organizations to enable Macie across all of the accounts.
  • An organization consists of a designated administrator account and one or more associated member accounts.
  • Accounts can be associated in two ways,
    • by integrating AWS Organizations (Recommended) or
    • by sending and accepting membership invitations
  • The designated administrator can assess and monitor the overall security posture of the organization’s S3 data estate, and discover sensitive data in the organization’s S3 buckets.
  • The administrator can also perform various account management and administration tasks at scale, such as monitoring estimated usage costs and assessing account quotas.
  • Can manage Macie for up to 10,000 accounts in an organization.
  • Administrator can enable/disable automated sensitive data discovery for individual accounts or all accounts selectively.

Macie Integration with AWS Security Hub

  • Macie publishes both policy findings and sensitive data findings to AWS Security Hub.
  • Security Hub provides security controls that check:
    • Macie.1 – whether Macie is enabled for an AWS account.
    • Macie.2 – whether automated sensitive data discovery is enabled for a Macie account.
  • Integrates with AWS User Notifications for configuring custom notification rules and delivery channels.

Macie Pricing

  • Charged based on three dimensions:
    • Number of S3 buckets evaluated for bucket inventory and monitoring (up to 10,000 per account).
    • Number of S3 objects monitored for automated data discovery.
    • Quantity of data inspected for sensitive data discovery jobs.
  • 30-day free trial includes automated sensitive data discovery and S3 bucket-level security evaluation.
  • 1 GB of data processed per month at no cost (perpetual free tier, not limited to trial).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which AWS service makes it easy to automate the process of discovering, classifying, and protecting data stored in AWS?
    1. AWS Shield
    2. AWS WAF
    3. AWS GuardDuty
    4. AWS Macie
  2. A company needs to continuously monitor its S3 buckets for sensitive data such as PII and financial information across multiple AWS accounts. They want an automated solution that provides sensitivity scores and an interactive data map. Which approach should they use?
    1. Create individual S3 event notifications for each bucket
    2. Enable Amazon Macie automated sensitive data discovery across the organization
    3. Write custom Lambda functions to scan S3 objects on upload
    4. Use AWS Config rules to check for sensitive data
  3. A security team wants to identify sensitive data in S3 that matches their company’s proprietary data formats, in addition to standard PII detection. Which Macie feature should they use?
    1. Managed data identifiers only
    2. Custom data identifiers with regex patterns and keywords
    3. S3 Object Lock
    4. AWS Config custom rules
  4. An organization is using Macie and wants to prevent findings from being generated for known safe data patterns, such as test credit card numbers used in development environments. What should they configure?
    1. Suppression rules
    2. Custom data identifiers with exclusion patterns
    3. Allow lists
    4. IAM policies to restrict Macie access to development buckets
  5. How does Amazon Macie integrate with AWS Security Hub? (Select TWO)
    1. Macie publishes policy and sensitive data findings to Security Hub
    2. Security Hub triggers Macie scans automatically
    3. Security Hub provides controls to verify Macie is enabled (Macie.1) and automated discovery is active (Macie.2)
    4. Security Hub manages Macie pricing
    5. Macie uses Security Hub to store discovery results

References

AWS CloudTrail

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS CloudTrail

  • AWS CloudTrail helps you enable governance, compliance, operational, and risk auditing of the AWS account.
  • CloudTrail helps to get a history of AWS API calls and related events for the AWS account.
  • CloudTrail records actions taken by a user, role, or AWS service.
  • CloudTrail tracking includes calls made by using the AWS Management Console, AWS SDKs, Command-line tools (CLI), APIs, and higher-level AWS services (such as AWS CloudFormation)
  • CloudTrail helps to identify which users and accounts called AWS, the source IP address the calls were made from, and when the calls occurred.
  • CloudTrail is enabled on your AWS account when you create it.
  • CloudTrail is per AWS account and per region for all the supported services.
  • CloudTrail AWS API call history enables security analysis, resource change tracking, and compliance auditing.
  • CloudTrail event history provides a viewable, searchable, and downloadable record of the past 90 days of CloudTrail management events.
  • CloudTrail logs can be encrypted by using default S3 SSE-S3 or KMS.
  • CloudTrail log file integrity validation can be used to check whether a log file was modified, deleted, or unchanged after CloudTrail delivered it.
  • CloudTrail integrates with AWS Organizations and provides an organization trail that enables the delivery of events in the management account, delegated administrator account, and all member accounts in an organization to the same S3 bucket, CloudWatch Logs, and CloudWatch Events.
  • CloudTrail Insights can be enabled on a trail to help identify and respond to unusual activity associated with both management events and data events.
  • CloudTrail Lake helps run fine-grained SQL-based queries on events. Note: CloudTrail Lake is no longer open to new customers starting May 31, 2026. Existing customers can continue to use it. AWS recommends Amazon CloudWatch for similar capabilities.
  • CloudTrail supports Network Activity Events (GA Feb 2025) that capture AWS API calls made through VPC endpoints, providing visibility into data perimeter security.
  • CloudTrail supports Data Event Aggregation (Nov 2025) that consolidates high-volume data events into 5-minute summaries for efficient monitoring.
  • CloudTrail now integrates directly with Amazon CloudWatch via service-linked channels (SLCs) (Dec 2025), enabling simplified event delivery without requiring trails.

CloudTrail Works

CloudTrail Flow
  • AWS CloudTrail captures AWS API calls and related events made by or on behalf of an AWS account and delivers log files to a specified S3 bucket.
  • S3 lifecycle rules can be applied to archive or delete log files automatically.
  • Log files contain API calls from all of the account’s CloudTrail-supported services.
  • Log files from all the regions can be delivered to a single S3 bucket and are encrypted, by default, using S3 server-side encryption (SSE). Encryption can be configured with AWS KMS.
  • CloudTrail publishes new log files multiple times an hour, usually about every 5 mins, and typically delivers log files within 15 mins of an API call.
  • CloudTrail can be configured, optionally, to deliver events to a log group to be monitored by CloudWatch Logs.
  • SNS notifications can be configured to be sent each time a log file is delivered to your bucket.
  • A Trail is a configuration that enables logging of the AWS API activity and delivery of events to a specified S3 bucket.
  • Trail can be created with CloudTrail console, AWS CLI, or CloudTrail API.
  • Events in a trail can also be delivered and analyzed with CloudWatch Logs and EventBridge.
  • A Trail can be applied to all regions or a single region
    • A trail that applies to all regions
      • When a trail is created that applies to all regions, CloudTrail creates the same trail in each region, records the log files in each region, and delivers the log files to the specified single S3 bucket (and optionally to the CloudWatch Logs log group).
      • Default setting when a trail is created using the CloudTrail console.
      • A single SNS topic for notifications and CloudWatch Logs log group for events would suffice for all regions.
      • Advantages
        • configuration settings for the trail apply consistently across all regions.
        • manage trail configuration for all regions from one location.
        • immediately receive events from a new region.
        • receive log files from all regions in a single S3 bucket and optionally in a CloudWatch Logs log group.
        • create trails in regions not used often to monitor for unusual activity.
    • A trail that applies to one region
      • An S3 bucket can be specified that receives events only from that region and it can be in any region that you specify.
      • Additional individual trails are created that apply to specific regions, those trails can deliver event logs to a single S3 bucket.
  • Turning on a trail means creating a trail and start logging.
  • CloudTrail supports five trails per region. A trail that applies to all regions counts as one trail in every region.
  • As a best practice, a trail can be created that applies to all regions in the AWS partition e.g. AWS for all standard AWS regions or aws-cn for China
  • IAM can control which AWS users can create, configure, or delete trails, start and stop logging, and access the buckets containing log information.
  • Log file integrity validation can be enabled to verify that log files have remained unchanged since CloudTrail delivered them.
  • CloudTrail Lake helps run fine-grained SQL-based queries on the events.

CloudTrail with AWS Organizations

  • With AWS Organizations, an Organization trail can be created that will log all events for all AWS accounts in that organization.
  • Organization trails can apply to all AWS Regions or one Region.
  • Organization trails must be created in the management account, and when specified as applying to an organization, are automatically applied to all member accounts in the organization.
  • Member accounts will be able to see the organization trail, but cannot modify or delete it.
  • By default, member accounts will not have access to the log files for the organization trail in the S3 bucket.
  • A delegated administrator account can be designated to manage CloudTrail on behalf of the organization, without needing direct access to the management account.

CloudTrail Events

  • An event in CloudTrail is the record of activity in an AWS account.
  • CloudTrail events provide a history of both API and non-API account activity made through the AWS Management Console, AWS SDKs, command line tools, and other AWS services.
  • CloudTrail has the following event types:
    • Management Events
      • Management events provide information about management or control plane operations that are performed on resources.
      • Includes resource creation, modification, and deletion events.
      • By default, trails log all management events for the AWS account.
      • The first copy of management events in each region is delivered free of charge.
    • Data Events
      • Data events provide information about the resource or data plane operations performed on or in a resource.
      • Includes data events like reading and writing of objects in S3, items in DynamoDB, Lambda function invocations, and more.
      • By default, trails don’t log data events for the AWS account.
      • Data events can be filtered using advanced event selectors for fine-grained control over which events are logged.
      • Data Event Aggregation (Nov 2025) automatically consolidates data events into 5-minute summaries, showing access frequency, error rates, and most-used actions to simplify monitoring at scale.
    • Network Activity Events (GA Feb 2025)
      • Network activity events capture AWS API calls made through VPC endpoints from a private VPC to an AWS service.
      • Records both control plane and data plane actions passing through a VPC endpoint.
      • Provides visibility into API activity regardless of the AWS account initiating the action.
      • Helps detect when external credentials are used at a VPC endpoint (data exfiltration prevention).
      • Logs actions that were denied due to VPC endpoint policies.
      • Available for services including S3, EC2, KMS, Secrets Manager, and CloudTrail.
      • By default, trails don’t log network activity events.
    • CloudTrail Insights Events
      • CloudTrail Insights events capture unusual API call rate or error rate activity in the AWS account.
      • Insights can now detect anomalies in both management events and data events (Nov 2025).
      • For management events: detects unusual levels of write management API activity, or unusual levels of errors returned on management API activity.
      • For data events: automatically detects anomalies in data access patterns, helping identify potential threats or issues.
      • By default, trails don’t log CloudTrail Insights events.
      • When enabled, CloudTrail detects unusual activity, and Insights events are logged to a different folder or prefix in the destination S3 bucket for the trail.
      • Insights events provide relevant information, such as the associated API, error code, incident time, and statistics, that help understand and act on unusual activity.
      • Unlike other types of events captured in a CloudTrail trail, Insights events are logged only when CloudTrail detects changes in the account’s API usage or error rate logging that differ significantly from the account’s typical usage patterns.
      • After enabling Insights for the first time, it may take up to 36 hours (trails) or 7 days (event data stores) to begin delivering Insights events.

Global Services Option

  • For most services, events are sent to the region where the action happened.
  • For global services such as IAM, AWS STS, and CloudFront, events are delivered to any trail that has the Include global services option enabled.
  • AWS OpsWorks and Route 53 actions are logged in the US East (N. Virginia) region.
  • To avoid receiving duplicate global service events, remember:
    • Global service events are always delivered to trails that have the Apply trail to all regions option enabled.
    • Events are delivered from a single region to the bucket for the trail. This setting cannot be changed.
    • If you have a single region trail, you should enable the Include global services option.
    • If you have multiple single region trails, you should enable the Include global services option in only one of the trails.
  • About global service events:
    • have a trail with the Apply trail to all regions option enabled.
    • have multiple single-region trails.
    • do not need to enable the Include global services option for the single region trails. Global service events are delivered for the first trail.

CloudTrail Lake

⚠️ Important: CloudTrail Lake is no longer open to new customers starting May 31, 2026. Existing customers can continue to use the service as normal. AWS recommends migrating to Amazon CloudWatch for similar capabilities. CloudTrail Trails, Insights, and Aggregated Events are not affected.

  • CloudTrail Lake is a managed data lake for capturing, immutably storing, accessing, and analyzing activity events.
  • Supports SQL-based queries on CloudTrail events for audit, security, and operational purposes.
  • Can aggregate events across multiple AWS accounts and regions into a single event data store.
  • Supports ingesting activity events from non-AWS sources (other cloud providers, in-house applications, SaaS applications).
  • Event data stores can retain data for up to 10 years (One-year extendable retention pricing) or 7 years (Seven-year retention pricing).
  • AI-powered natural language query generation (GA Nov 2024) allows asking questions in plain English without writing SQL queries.
  • AI-powered query result summarization (preview) provides summaries of query results.
  • Enhanced event filtering (Nov 2024) provides greater control over which events are ingested into event data stores.
  • Event enrichment (May 2025) allows appending resource tags and AWS global condition keys to events for easier categorization and analysis.
  • Expanded event size (May 2025) supports events up to 1 MB (increased from 256 KB limit), reducing truncation.
  • Pre-built dashboards – 14+ pre-curated dashboards for security, compliance, and operational monitoring use cases.
  • Cross-account data access (Nov 2024) enables sharing event data stores across accounts.
  • Migration to CloudWatch: AWS provides tools to export CloudTrail Lake event data stores directly to Amazon CloudWatch, including historical data import.

CloudTrail Log File Integrity

  • Validated log files are invaluable in security and forensic investigations.
  • CloudTrail log file integrity validation can be used to check whether a log file was modified, deleted, or unchanged after CloudTrail delivered it.
  • The validation feature is built using industry-standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing which makes it computationally infeasible to modify, delete or forge CloudTrail log files without detection.
  • When log file integrity validation is enabled:
    • CloudTrail creates a hash for every log file that it delivers.
    • Every hour, CloudTrail also creates and delivers a digest file that references the log files for the last hour and contains a hash of each.
    • CloudTrail signs each digest file using the private key of a public and private key pair.
    • After delivery, the public key can be used to validate the digest file.
    • CloudTrail uses different key pairs for each AWS region.
    • Digest files are delivered to the same S3 bucket, but a separate folder, associated with the trail for the log files.
    • The separation of digest files and log files enables the enforcement of granular security policies and permits existing log processing solutions to continue to operate without modification.
    • Each digest file also contains the digital signature of the previous digest file if one exists.
    • Signature for the current digest file is in the metadata properties of the digest file S3 object.
    • Log files and digest files can be stored in S3 or S3 Glacier securely, durably and inexpensively for an indefinite period of time.
    • To enhance the security of the digest files stored in S3, S3 MFA Delete can be enabled.

CloudTrail Integration with Amazon CloudWatch

  • CloudTrail can deliver events to Amazon CloudWatch Logs for centralized monitoring and analysis.
  • Simplified enablement via Service-Linked Channels (SLCs) (Dec 2025):
    • New integration allows receiving CloudTrail events in CloudWatch without requiring trails.
    • Provides additional benefits such as safety-checks and termination protection.
    • Supports organization-wide enablement across accounts.
    • Incurs both CloudTrail event delivery charges and CloudWatch Logs ingestion fees.
  • CloudWatch provides unified management and analytics for operational, security, and compliance data with:
    • Native analytics powered by OpenSearch (Logs QL, SQL, PPL queries).
    • Pre-built connectors for popular third-party sources.
    • Open access through Apache Iceberg APIs.
    • Built-in support for OCSF and OpenTelemetry formats.
  • Traditional trail-based integration with CloudWatch Logs remains supported for metric filters, alarms, and real-time monitoring.

CloudTrail Enabled Use Cases

  • Track changes to AWS resources
    • Can be used to track creation, modification or deletion of AWS resources
  • Compliance Aid
    • Easier to demonstrate compliance with internal policy and regulatory standards
  • Troubleshooting Operational Issues
    • Identify the recent changes or actions to troubleshoot any issues
  • Security Analysis
    • Use log files as inputs to log analysis tools to perform security analysis and to detect user behavior patterns
  • Data Perimeter Monitoring
    • Use network activity events to monitor API activity at VPC endpoints and detect potential data exfiltration attempts
  • Anomaly Detection
    • Use CloudTrail Insights to automatically detect unusual API call rates and error rates for both management and data events

CloudTrail Processing Library (CPL)

  • CloudTrail Processing Library (CPL) is a Java library that helps build applications to take immediate action on events in CloudTrail log files.
  • CPL helps to:
    • read messages delivered to SNS or SQS
    • download and read log files from S3 continuously
    • serialize the events into a POJO
    • allow custom logic implementation for processing
    • fault tolerant and supports multi-threading

AWS CloudTrail vs AWS Config

  • AWS Config reports on WHAT has changed, whereas CloudTrail reports on WHO made the change, WHEN, and from WHICH location.
  • AWS Config focuses on the configuration of the AWS resources and reports with detailed snapshots on HOW the resources have changed, whereas CloudTrail focuses on the events, or API calls, that drive those changes. It focuses on the user, application, and activity performed on the system.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You currently operate a web application in the AWS US-East region. The application runs on an auto-scaled layer of EC2 instances and an RDS Multi-AZ database. Your IT security compliance officer has tasked you to develop a reliable and durable logging solution to track changes made to your EC2, IAM and RDS resources. The solution must ensure the integrity and confidentiality of your log data. Which of these solutions would you recommend?
    1. Create a new CloudTrail trail with one new S3 bucket to store the logs and with the global services option selected. Use IAM roles, S3 bucket policies and Multi-Factor Authentication (MFA) Delete on the S3 bucket that stores your logs. (Single New bucket with global services option for IAM and MFA delete for confidentiality)
    2. Create a new CloudTrail with one new S3 bucket to store the logs. Configure SNS to send log file delivery notifications to your management system. Use IAM roles and S3 bucket policies on the S3 bucket that stores your logs. (Missing Global Services for IAM)
    3. Create a new CloudTrail trail with an existing S3 bucket to store the logs and with the global services option selected Use S3 ACLs and Multi Factor Authentication (MFA) Delete on the S3 bucket that stores your logs. (Existing bucket prevents confidentiality)
    4. Create three new CloudTrail trails with three new S3 buckets to store the logs one for the AWS Management console, one for AWS SDKs and one for command line tools. Use IAM roles and S3 bucket policies on the S3 buckets that store your logs (3 buckets not needed, Missing Global services options)
  2. Which of the following are true regarding AWS CloudTrail? Choose 3 answers
    1. CloudTrail is enabled globally (it can be enabled for all regions and also per-region basis)
    2. CloudTrail is enabled by default (CloudTrail is enabled by default on all AWS accounts and records management events)
    3. CloudTrail is enabled on a per-region basis (it can be enabled for all regions and also per-region basis)
    4. CloudTrail is enabled on a per-service basis (once enabled it is applicable for all the supported services, service can’t be selected)
    5. Logs can be delivered to a single Amazon S3 bucket for aggregation
    6. CloudTrail is enabled for all available services within a region. (is enabled only for CloudTrail supported services)
    7. Logs can only be processed and delivered to the region in which they are generated. (can be logged to bucket in any region)
  3. An organization has configured the custom metric upload with CloudWatch. The organization has given permission to its employees to upload data using CLI as well SDK. How can the user track the calls made to CloudWatch?
    1. The user can enable logging with CloudWatch which logs all the activities
    2. Use CloudTrail to monitor the API calls
    3. Create an IAM user and allow each user to log the data using the S3 bucket
    4. Enable detailed monitoring with CloudWatch
  4. A user is trying to understand the CloudWatch metrics for the AWS services. It is required that the user should first understand the namespace for the AWS services. Which of the below mentioned is not a valid namespace for the AWS services?
    1. AWS/StorageGateway
    2. AWS/CloudTrail (CloudWatch supported namespaces)
    3. AWS/ElastiCache
    4. AWS/SWF
  5. Your CTO thinks your AWS account was hacked. What is the only way to know for certain if there was unauthorized access and what they did, assuming your hackers are very sophisticated AWS engineers and doing everything they can to cover their tracks?
    1. Use CloudTrail Log File Integrity Validation. (Refer link)
    2. Use AWS Config SNS Subscriptions and process events in real time.
    3. Use CloudTrail backed up to AWS S3 and Glacier.
    4. Use AWS Config Timeline forensics.
  6. Your CTO has asked you to make sure that you know what all users of your AWS account are doing to change resources at all times. She wants a report of who is doing what over time, reported to her once per week, for as broad a resource type group as possible. How should you do this?
    1. Create a global AWS CloudTrail Trail. Configure a script to aggregate the log data delivered to S3 once per week and deliver this to the CTO.
    2. Use CloudWatch Events Rules with an SNS topic subscribed to all AWS API calls. Subscribe the CTO to an email type delivery on this SNS Topic.
    3. Use AWS IAM credential reports to deliver a CSV of all uses of IAM User Tokens over time to the CTO.
    4. Use AWS Config with an SNS subscription on a Lambda, and insert these changes over time into a DynamoDB table. Generate reports based on the contents of this table.
  7. A company wants to detect potential data exfiltration from their VPC. They use VPC endpoints for private connectivity to AWS services. What CloudTrail feature should they enable to monitor API activity at their VPC endpoints?
    1. CloudTrail Data Events
    2. CloudTrail Insights Events
    3. CloudTrail Network Activity Events (Network activity events capture API calls made through VPC endpoints and can detect when external credentials access resources)
    4. CloudTrail Management Events
  8. A security team wants to automatically detect anomalous data access patterns in their S3 buckets. Which CloudTrail capability should they use? (Select TWO)
    1. Enable CloudTrail Insights for data events (Insights now supports detecting anomalies in data events since Nov 2025)
    2. Enable CloudTrail Management Events
    3. Configure Data Event Aggregation (Aggregation provides 5-minute summaries showing access frequency and error rates)
    4. Enable CloudTrail Network Activity Events
    5. Use CloudTrail Processing Library
  9. An organization processes thousands of S3 API calls per minute and wants to simplify security monitoring without processing individual events. Which CloudTrail feature best addresses this?
    1. CloudTrail Lake SQL queries
    2. CloudTrail Insights for management events
    3. CloudTrail Data Event Aggregation (Automatically consolidates data events into 5-minute summaries showing key trends like access frequency, error rates, and most-used actions)
    4. CloudTrail Log File Integrity Validation
  10. A company is looking for a managed solution to capture, store, and analyze CloudTrail logs with native analytics capabilities. They are a new AWS customer. Which approach should they use?
    1. Create a CloudTrail Lake event data store (CloudTrail Lake is no longer open to new customers since May 31, 2026)
    2. Use Amazon CloudWatch with CloudTrail integration via service-linked channels (AWS recommends CloudWatch for new customers, which provides unified analytics powered by OpenSearch, OCSF support, and Iceberg APIs)
    3. Deliver CloudTrail logs to S3 and query with Athena
    4. Use AWS Config to analyze API activity

References