Security in AWS Part 1: Threat Detection and Incident Response

Introduction

AWS security is a broad landscape. There are countless tools and controls, each solving a small part of the bigger picture: identity management with IAM, SSO and Organizations; network isolation with VPC, Security Groups, ACLS and PrivateLinks; encryption and data protection through KMS and secrets management; continuous visibility with CloudTrail, Config, GuardDuty and Inspector; automated response pipelines using EventBridge, Lambda and Systems Manager. Security becomes even more complex under the shared responsibility model, where AWS handles the platform and customers handle their own workloads, which makes it easy to understand why many find it challenging.

In the previous articles I’ve already covered security in Kubernetes, see Security in Kubernetes – Part 1 and Security in Kubernetes – Part 2. This AWS series is the natural follow-up. As I started preparing for the AWS Certified Security – Specialty, I wanted to create a document, encompassing the core AWS services related to Security Specialty: what they are, which Security Domain they belong to and how they can be applied in real infrastructure. The result is a series of six articles, each focusing on a specific layer of AWS security and representing one of the exam’s Security Domains. In addition, each article includes a section titled “Real Use-Case Scenario”, where I describe a practical example of how the related AWS services are used in real-world situations.

I truly believe that whether someone writes code, manages systems or leads teams, AWS security should not be seen as confusing or abstract. These articles aim to organize it into clear principles and a structured way of thinking that helps make sense of the cloud.

AWS Security Exam Domains Overview

According to the official AWS Certified Security – Specialty exam guide, the exam has the following domains:

• Domain 1: Threat Detection and Incident Response
• Domain 2: Security Logging and Monitoring
• Domain 3: Infrastructure Security
• Domain 4: Identity and Access Management
• Domain 5: Data Protection
• Domain 6: Management and Security Governance

Each of these areas represents a critical part of AWS security. Together they cover the entire lifecycle from preventing threats and controlling access to protecting data and ensuring compliance.

Lets start the journey and explore what is hidden behind the each domain.

Domain 1: Threat Detection and Incident Response

The primary objective of this domain is to ensure continuous visibility, timely detection of anomalies and rapid isolation of threats across all layers of an AWS environment.

AWS provides several integrated services that support these goals, including Amazon GuardDuty, AWS Security Hub, Amazon Detective, Amazon Macie, AWS Config and IAM Access Analyzer.

Together they establish a comprehensive detection and response ecosystem capable of identifying, analyzing and mitigating risks in real time.

In the paragraphs below I will give an overview of each service.

Amazon GuardDuty

Amazon GuardDuty is a managed intelligent threat discovery service which uses ML to continuously monitor, analyze and processes malicious behavior from multiple data sources such as AWS CloudTrail logs (including both data and management events), VPC Flow Logs, DNS query logs and EKS audit logs. It identifies signs of potential compromise or unauthorized activity such as:

• Unusual API activity or access attempts from known malicious IP addresses
• Attempts to disable CloudTrail logging or other monitoring controls
• Unauthorized deployments or privilege escalation inside an account
• Compromised EC2 instances communicating with command-and-control servers
• Port scanning, repeated failed logins

Each detected issue is presented as a finding which includes a clear description, the affected resource, and a severity rating. Findings are grouped by category and type, for example UnauthorizedAccess:SSHBruteforce. This makes it easy to understand both what happened and how serious it is.

GuardDuty operates entirely as a managed service and does not require agents or additional infrastructure. Once enabled, it starts analyzing existing data automatically. Findings can be viewed in the AWS console or sent to Security Hub, EventBridge or an S3 bucket for centralized monitoring and automated response.

Running GuardDuty across all accounts and regions is considered a baseline security measure. Organizations typically designate one administrator account that collects findings from every member account, creating a single view of threats across the environment. The service scales automatically and keeps improving over time as new threat intelligence and anomaly-detection models are added by AWS.

In practice, GuardDuty acts as the continuous security analyst for the cloud. It quietly monitors patterns, learns what normal behavior looks like and alerts when something unusual or dangerous starts to happen.

AWS Security Hub

AWS Security Hub provides centralized visibility and correlation of security findings. It aggregates results from AWS services such as GuardDuty, Inspector, Macie, AWS Config and others, as well as from third-party security tools, converting them into the AWS Security Finding Format (ASFF).

Security Hub automatically organizes findings by account, region and resource, giving a unified view of the entire cloud environment. It uses built-in correlation to highlight related issues, helping identify broader incidents that span multiple services or accounts. The service also allows custom insights that filter findings based on conditions such as severity, resource type or compliance status.

In addition to aggregating findings, Security Hub continuously evaluates AWS resources against established security frameworks and best practices. These include standards such as PCI DSS, CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. Each control within a standard receives a pass or fail status, which allows organizations to measure their compliance posture and track progress over time.

Security Hub integrates tightly with automation and response workflows. Findings can be sent to Amazon EventBridge to trigger notifications or remediation actions through Lambda or Systems Manager. This connection makes it possible to automatically quarantine resources, adjust permissions or alert response teams when critical findings appear.

As a result, Security Hub becomes the central point for security operations in AWS. It gathers findings from across services and accounts, prioritizes what matters most and provides the context needed to take timely action. Instead of reviewing separate dashboards or alerts, teams can rely on one consistent system that shows the overall security health of the environment and guides continuous improvement.

Amazon Detective

Amazon Detective supports post-incident analysis and investigation by automatically collecting and organizing data from across AWS services. It ingests time-based events from VPC Flow Logs, CloudTrail events and findings from GuardDuty. Detective then builds a graph-based model of entities such as IAM principals, IP addresses, instances and resources, along with their historical interactions.

This graph structure allows analysts to explore relationships over time instead of reviewing raw logs line by line. For example, an alert from GuardDuty can be opened in Detective to reveal a complete activity chain: which credentials were used, which resources they accessed, when the activity occurred and what other systems were touched during that period.

The visual interface makes it easier to understand complex security events, such as credential compromise, privilege escalation or lateral movement within the environment. Investigators can pivot from one entity to another, moving from a suspicious IP address to the associated EC2 instance or user role, to reconstruct the full scope of the event.

Detective continuously maintains this contextual graph, updating relationships as new data arrives. This eliminates the need for manual log correlation across multiple services and accounts. Historical data is retained for extended periods, allowing teams to review long-term patterns, confirm when a compromise began and validate that remediation actions were effective.

In practice, Amazon Detective acts as the investigation layer of AWS security. It connects signals from detection services into a single interactive timeline, helping analysts move from alerts to understanding and from symptoms to root cause with speed and confidence.

Amazon Macie

Amazon Macie focuses on identifying and protecting sensitive data stored in Amazon S3. It uses machine learning and pattern matching to automatically recognize information such as personal identifiers, credit card numbers, access keys or health-related data. This helps organizations understand what kind of information they store, where it resides and whether it is properly protected.

When Amazon Macie is enabled, it continuously scans S3 buckets to detect potential data exposure, such as publicly accessible objects or unencrypted files. Findings are prioritized by severity, allowing teams to focus on the most critical issues first. Each finding includes details about the data type, the location of the affected object and recommended actions for remediation.

Integration with AWS Security Hub centralizes visibility of data-related risks, while integration with EventBridge allows findings to trigger alerts or automated workflows. Typical use cases include monitoring data repositories that contain customer records or financial information, classifying high-value datasets and ensuring that only authorized users have access to them.

Overall, Amazon Macie plays a vital role in maintaining data privacy and regulatory compliance. It turns data discovery into an automated and measurable process, helping organizations reduce the risk of accidental exposure and build confidence that sensitive information remains properly secured within the AWS environment.

AWS Config

AWS Config provides continuous visibility into how AWS resources are configured and how those configurations change over time. It acts as both a recorder and an evaluator, keeping a complete history of resource states and verifying whether they meet defined security and compliance standards.

When enabled, AWS Config automatically tracks the creation, modification and deletion of supported AWS resources. Every change generates a configuration item that includes detailed metadata such as resource type, relationships, tags and settings. This historical view makes it possible to understand exactly what changed, when it changed and who initiated the change, which is invaluable during investigations or compliance audits.

AWS Config evaluates resources using rules. These rules can be built-in (called managed rules) or custom ones created with AWS Lambda. Managed rules cover many common security and operational controls such as S3_BUCKET_PUBLIC_READ_PROHIBITED, which ensures that S3 buckets are not publicly accessible, or EC2_INSTANCE_NO_PUBLIC_IP, which checks that instances are launched without direct internet exposure. Custom rules can enforce organization-specific policies, for example, requiring encryption on EBS volumes or tagging standards across all resources.

When a resource fails to meet a rule’s condition, AWS Config marks it as non-compliant and records the finding. It can also trigger automatic remediation actions using AWS Systems Manager Automation or Amazon EventBridge. For instance, if a bucket becomes public, AWS Config can immediately invoke a predefined automation document that disables public access and notifies the security team.

By continuously monitoring configurations and enforcing corrective actions, AWS Config transforms compliance from a manual task into an ongoing process. It ensures that resources stay aligned with security policies, reduces the chance of misconfiguration and provides a reliable foundation for auditing and governance in the cloud.

IAM Access Analyzer

IAM Access Analyzer helps identify resources that might be shared more broadly than intended. It uses automated reasoning, a type of formal logic analysis, to examine IAM and resource-based policies and determine whether they allow access from outside the account or organization. This proactive approach helps prevent accidental data exposure before it occurs.

The service continuously analyzes policies attached to resources such as S3 buckets, KMS keys, IAM roles, SQS queues, Secrets Manager secrets and Lambda functions. It evaluates how these policies interact and flags configurations that could permit public access or allow entities from other accounts to perform actions on those resources.

Findings are expressed in clear language, making them easy to interpret. For example, Access Analyzer might report that “an S3 bucket allows public read access” or “a KMS key is shared with an external AWS account.” Each finding includes details about which resource is affected, who has access and what permissions are granted. This allows administrators to review the intent of the policy and decide whether the access is acceptable or needs to be restricted.

The service integrates with AWS Security Hub, where its findings appear alongside alerts from other security services such as GuardDuty, Inspector and Macie. This centralization helps correlate access risks with other types of findings, creating a complete picture of an organization’s security posture.

In practice, IAM Access Analyzer acts as a safety net for policy management. It continuously verifies that access boundaries remain correct, highlights potential exposure points and provides clear guidance on how to fix them. By catching misconfigurations early, it helps organizations maintain the principle of least privilege and keep sensitive resources secure across accounts and regions.

Real Use-Case Scenario

In this section, I’ll describe a real-world use case of the services within the “Threat Detection and Incident Response domain”. Specifically, I’ll explain how Amazon GuardDuty is implemented in one of our current projects at Klika.

As the project grew and matured, we needed to strengthen our security posture and ensure continuous visibility into potential threats, such as unusual API activity, compromised EC2 instances, suspicious S3 actions and other security indicators.

Our goals were to:

• gain clear visibility and simple dashboards with security metrics
• receive automated notifications about findings
• easily onboard or remove AWS accounts for centralized monitoring using AWS Organizations

Given these requirements, Amazon GuardDuty was a natural choice. Following AWS best practices, we created a separate account for a delegated administrator and invited all member accounts. With this setup, all findings generated in any account are automatically aggregated and visible in the central GuardDuty Dashboard, which is part of the GuardDuty console. No additional configuration is required, findings appear there automatically once GuardDuty is enabled through Organizations. We activated the following protection plans: S3 Protection, EKS Protection, Malware Protection for EC2, RDS Protection and Lambda Protection.

To deliver Guard Duty notifications, we built the event flow, illustrated in Figure 2 below:

Lets describe this integration flow.

1. GuardDuty generates a finding, for example, UnauthorizedAccess:SSHBruteforce:

2. GuardDuty publishes its findings to Amazon EventBridge on an hourly schedule.

3. An EventBridge rule captures all GuardDuty findings and forwards them to an Amazon SNS topic.

4. The SNS topic triggers an AWS Lambda function subscribed to it.

5. The Lambda function parses the event, formats a user-friendly message, and posts it to a designated Slack channel.

With this setup, our team can review findings through the central GuardDuty Dashboard, while also receiving regular notifications in Slack, ensuring quick visibility and timely response to potential security incidents.

Threat Detection and Incident Response Recap

Each mentioned service contributes to a specific phase of the detection and response lifecycle:

Phase	AWS Services	Purpose
Detection	GuardDuty, Macie, IAM Access Analyzer	Identify anomalies, misconfigurations and data risks
Aggregation	Security Hub	Centralize and prioritize findings
Investigation	Detective, CloudTrail	Analyze relationships and event history
Compliance	Config	Track configuration drift and policy adherence
Response	EventBridge	Automate containment and remediation

See the next part Security in AWS – Part 2: Security Logging and Monitoring

By Pavel Luksha, Senior DevOps Engineer, Klika Tech, Inc.