How Do AWS Managed Security Services Use Monitoring, GuardDuty and Security Hub Together?
GuardDuty addresses one half of the AWS security challenge, while Security Hub addresses the other half. Amazon GuardDuty alerts you to suspicious activity. AWS Security Hub CSPM indicates your security posture level and the location of each finding. Each service provides valuable data on its own. They are linked via continuous monitoring and an accountable operations team, providing an organization with a security function that is more like a working tool than two additional consoles to check. Most AWS environments have no shortage of security data.
If you’re like a typical organisation, you have many AWS accounts, workloads running on Amazon EC2, Amazon EKS, AWS Lambda, and Amazon S3, and a constant influx of API activity from your people and automation. The challenge is turning that information into prioritised, well-owned decisions. This guide describes how each service works, how the managed security teams connect them, what happens to a finding from detection through remediation, and how to determine whether the complete system lowers risk.
AWS managed security services that connect continuous monitoring, Amazon GuardDuty threat detection and AWS Security Hub CSPM posture management give security teams one accountable path from signal to response.
How Do GuardDuty and Security Hub Work Together?
GuardDuty continually monitors AWS logs and telemetry for potential unauthorized or malicious activity. Security Hub CSPM analyses resources for security standards and compiles results from GuardDuty and other services in a standard format. Managed security teams leverage GuardDuty as the detection layer, Security Hub as the context and prioritization layer and human analysts for investigation and response.
In practice, the three components form a pipeline. Monitoring establishes what is happening across accounts and Regions. GuardDuty evaluates that activity for threat behavior. Security Hub CSPM places each GuardDuty finding next to control failures and findings from other integrated services, so an analyst can judge severity in context. According to AWS documentation, when both services are enabled in the same account and Region, GuardDuty automatically sends its findings to Security Hub CSPM. There, they are represented in the AWS Security Finding Format (ASFF).
| Security capability | Primary role | Question it answers | Example outcome |
|---|---|---|---|
| AWS environment monitoring | Visibility and operational awareness | What is happening in the environment? | A configuration change or unusual API call becomes visible |
| Amazon GuardDuty | Threat detection | Does this behavior look malicious or unauthorized? | Potential credential compromise or malicious communication is flagged |
| AWS Security Hub CSPM | Posture management and finding aggregation | How serious is this issue given everything else we know? | The finding is correlated with control status and related findings |
| Security operations team | Investigation and response | What should happen next, and who owns it? | An analyst validates, contains or escalates the issue |
| Automation | Response acceleration | Can a defined action run without manual effort? | A ticket, notification or approved remediation workflow is triggered |
GuardDuty does not replace Security Hub, and Security Hub does not replace continuous threat detection. The value comes from running them as connected stages of one workflow.
Security Hub or Security Hub CSPM: Which Service Is Which?
AWS uses a pair of related names today. The original Security Hub service, AWS Security Hub CSPM, performs security control checks against standards and gathers results. The AWS Security Hub experience, the newer version, aggregates GuardDuty, Amazon Inspector, and Security Hub CSPM signals into exposure findings that show the combinations of risks most likely to impact.
This matters because many older guides refer to the control-checking service as “Security Hub”. In this article, posture management, control evaluation and finding aggregation is referred to as Security Hub CSPM. The Exposure Analysis is part of the overall unified experience, known as “Security Hub”.
This difference has real-world implications. A team that only has Security Hub CSPM enabled receives control scores and aggregated findings. If a team also performs exposure analysis, it produces correlated views. For instance, one view could indicate that a resource is internet accessible, has an identified vulnerability on Amazon Inspector, and has also been identified as having suspicious activity on GuardDuty. Real attack paths tend to develop in those combinations.
What Is Amazon GuardDuty and What Does It Monitor?
AWS GuardDuty is a threat detection service that continuously scans CloudTrail management events, VPC Flow Logs and DNS query logs and raises alerts when it detects suspicious activity based on threat intelligence and machine learning. Additional protection options include: S3 events, EKS audit logs, runtime activity, RDS logins, Lambda network activity, and malware scanning. GuardDuty is based on behavior, not events.
One API call doesn’t necessarily amount to anything. The situation changes when a series of unusual calls comes from an unknown Region, a network connection goes to an address on a threat intelligence list, and logging configuration changes. GuardDuty’s designed to detect those patterns. With Extended Threat Detection, it can also combine signals into multistage attack sequences, rather than just unrelated alerts.
The foundational data sources do not need agents, and do not need to make any changes to workloads, and the optional protection plans provide depth where an organization actually operates workloads. S3 Protection analyzes object level API activity, and EKS Protection analyzes audit logs for Kubernetes. Runtime Monitoring is a lightweight security agent that can be deployed on supported EC2, EKS and ECS workloads to monitor process and network activity. Malware Protection scans EC2 volumes, newly uploaded S3 objects, RDS Protection analyzes login activity to supported Aurora and RDS databases and Lambda Protection monitors function network activity.
A GuardDuty finding is not a verdict, it’s the beginning of an investigation process. Before the analyst can determine the meaning of the signal to the business, they look at the impacted identity, resource, Region, timeline and related findings.
What Is AWS Security Hub CSPM and What Does It Evaluate?
AWS Security Hub CSPM is a cloud security posture management service that evaluates AWS resources against security standards and aggregates findings from AWS services and partner products in one normalized format. It supports AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, NIST SP 800-53, NIST SP 800-171 and PCI DSS.
Security Hub CSPM answers a different question from GuardDuty. It does not ask whether an attack is underway. It asks whether the environment is configured the way your chosen standards require, and it collects every relevant finding into one place so nothing is reviewed in isolation. According to the AWS Security Hub documentation, findings from GuardDuty, Amazon Inspector, Amazon Macie, IAM Access Analyzer, AWS Firewall Manager and supported third-party tools can all be consolidated this way.
One point deserves emphasis. AWS states that Security Hub standards and controls help evaluate posture but do not guarantee compliance with any regulatory framework or audit. A security score is a measurable indicator of technical control status. Compliance also involves governance, policy, evidence and processes that sit outside a dashboard. A managed security provider should report Security Hub scores honestly and never present them as proof of compliance.
Threat Detection vs Security Posture: Why You Need Both
Threat detection identifies malicious or unauthorized activity happening now, while security posture management identifies configuration weaknesses that could be exploited later. An environment can be well configured and still suffer a stolen credential, or poorly configured with no active attack. GuardDuty covers the first risk, Security Hub CSPM covers the second, and managed operations connect them.
Consider an EC2 instance that begins communicating with a known malicious destination. GuardDuty raises a finding. On its own, that finding tells the analyst something suspicious is happening. Security Hub CSPM may show that the same instance has a security group open to the internet on an administrative port, and that the account has no alerting configured for root user activity. Together, these signals move the issue from “investigate when possible” to “treat as a probable active incident on an exposed resource.”
| Security dimension | Primary concern | Example question | Typical AWS capability |
|---|---|---|---|
| Security posture | Configuration and control state | Is this environment configured to required controls? | Security Hub CSPM |
| Threat detection | Malicious or unauthorized activity | Is something suspicious happening now? | Amazon GuardDuty |
| Visibility | Operational context | What changed, and who changed it? | AWS CloudTrail, Amazon CloudWatch |
| Vulnerability | Software and exposure weaknesses | Can a known vulnerability be exploited here? | Amazon Inspector |
| Investigation | Understanding an incident | What happened, and which resources are connected? | Security Hub, Amazon Detective |
| Response | Containment and remediation | What action should be taken, and by whom? | Automation rules, EventBridge, ticketing workflows |
This separation also improves reporting. A managed service reporting only alert counts says very little. A report covering posture trends, detection activity, remediation progress and unresolved exposure gives leadership a reliable view of security maturity.
The SENTRY Framework for AWS Managed Security Services
SENTRY is a six-stage operating model for AWS security: See, Evaluate, Normalize, Triage, Respond and Yield. It maps monitoring, GuardDuty and Security Hub CSPM to a closed loop in which every finding either leads to action or improves the controls that produced it.
AWS security monitoring should run as a continuous risk-reduction cycle, not a queue of disconnected alerts to close. That principle separates a security operation from a notification service, and it is the foundation of the SENTRY model.
See establishes visibility across every account, Region and workload that matters, including development accounts and rarely used Regions where attackers often look first.
Evaluate applies GuardDuty detection to that activity so suspicious behavior is surfaced automatically rather than found by manual log review.
Normalize brings GuardDuty findings, control failures and other integrated findings into Security Hub CSPM in one consistent format.
Triage ranks each issue by severity, business criticality, exposure, related findings and the organization’s own response policy.
Respond turns a validated finding into an owned action such as containment, credential rotation, escalation or remediation.
Yield asks what the organization learned. It looks at recurring findings, slow remediation, coverage gaps and control drift, and feeds those lessons back into configuration and policy.
| SENTRY stage | AWS capability involved | Managed security activity | Output |
|---|---|---|---|
| See | CloudTrail, VPC Flow Logs, DNS logs, CloudWatch | Confirm coverage across accounts and Regions | Complete, trusted telemetry |
| Evaluate | Amazon GuardDuty and protection plans | Enable protections that match actual workloads | Threat findings with evidence |
| Normalize | Security Hub CSPM, ASFF | Aggregate and deduplicate findings centrally | One consolidated finding view |
| Triage | Security Hub severity, exposure findings | Apply business context and response policy | Prioritized, owned queue |
| Respond | Automation rules, EventBridge, ticketing | Investigate, contain, escalate, remediate | Closed incidents with records |
| Yield | Security scores, trend data | Analyze root causes and recurring failures | Fewer repeat findings over time |
The Yield stage is where most tool-only deployments fall short. Closing a finding is an activity. Preventing the same finding from appearing next month is an outcome.
How Security Findings Flow From Telemetry to Decision
A finding moves through five steps. AWS services generate activity. GuardDuty analyzes the activity for threats. Findings flow into Security Hub CSPM alongside control results. EventBridge and automation rules route them to tickets or notifications. Analysts then investigate and decide on containment, escalation or remediation.
In a single-account environment this flow is simple. Multi-account environments need more deliberate design. AWS Organizations provides the account structure, and both GuardDuty and Security Hub CSPM support a delegated administrator account. A dedicated security account can therefore manage the services across the organization without using the management account day to day. Security Hub CSPM also supports central configuration, which applies consistent standards and controls to member accounts.
Cross-Region aggregation lets a designated home Region collect findings, resources, and trends from linked Regions, so analysts don’t have to switch Regions to build a picture. AWS notes that aggregation does not enable Security Hub in linked Regions on its own. Each Region still needs the service enabled, which is a common source of blind spots.
A practical structure separates production, development, security tooling, log archive and shared services into distinct accounts. The security account acts as delegated administrator for GuardDuty and Security Hub CSPM, and the home Region aggregates everything. The exact design should follow the organization’s data residency requirements, regulatory obligations and operating model. It should also sit alongside broader AWS cloud management practices so security and operations share one account strategy.
What a Managed Security Team Does With a GuardDuty Finding
A managed security team validates each GuardDuty finding before acting. The analyst confirms the affected account, Region, resource and identity, reviews related CloudTrail activity and Security Hub context, and checks whether the behavior was expected. The analyst then escalates, contains, suppresses with documentation, or uses the finding to tune detection.
Forwarding every GuardDuty finding to a customer’s inbox creates noise, not security. A mature process applies judgment at each step. First, the analyst establishes what the finding represents and whether the identity or resource normally behaves this way. A deployment pipeline that suddenly calls APIs from a new Region may reflect a planned expansion or a stolen access key. CloudTrail history, change records and a quick confirmation with the owning team usually settle the question.
Next, the analyst classifies the finding against the incident response policy. A confirmed incident follows the escalation path. The analyst documents expected activity and, where it will recur, adds a suppression rule or trusted IP list to reduce future noise without hiding real threats.
Automation fits where the response is predictable and safe. GuardDuty and Security Hub CSPM both publish findings to Amazon EventBridge, which can route them to notifications, ticketing or approved remediation. Security Hub automation rules can update severity or workflow status as findings arrive. Integrations with tools such as Jira Service Management and ServiceNow keep findings inside the ticketing environment the internal team already uses. This means escalations follow existing paths instead of creating a parallel process.
Automation should follow documented policy, not severity labels alone. Isolating a production workload because a finding reads “High” can cause an outage larger than the threat. Business criticality, confidence and evidence should all shape the decision, with human approval required for disruptive actions.
Real-World AWS Security Scenarios
The following scenarios are illustrative and based on common AWS threat patterns. They show how monitoring, GuardDuty and Security Hub CSPM combine in practice.
| Scenario | Example GuardDuty finding type | Security Hub CSPM context that raises priority | Typical first response |
|---|---|---|---|
| EC2 communicating with attacker infrastructure | Backdoor:EC2/C&CActivity.B | Instance sits in a security group open to the internet | Isolate instance after approval, capture forensic snapshot |
| Stolen instance credentials used elsewhere | UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS | Role carries broad permissions, access keys not rotated | Revoke sessions, rotate credentials, review CloudTrail |
| Unusual bulk access to sensitive data | Exfiltration:S3/AnomalousBehavior | Bucket lacks access logging or block public access settings | Confirm identity, restrict access, assess data exposure |
| Suspicious activity inside Kubernetes | Execution:Kubernetes/ExecInKubeSystemPod | Cluster endpoint publicly accessible, audit logging incomplete | Review pod activity, restrict access, escalate to platform team |
| Unauthorized cryptocurrency mining | CryptoCurrency:EC2/BitcoinTool.B!DNS | Instance launched in an unused Region | Stop instance, investigate how it was launched |
Suspicious EC2 Activity at 2:15 AM
A software company runs its production application on EC2. Overnight, an instance starts connecting to an IP address listed in threat intelligence as command-and-control infrastructure, and GuardDuty raises a finding.
A single finding does not confirm a compromise, and it matters because production data is on the line. The analyst reviews the instance’s recent CloudTrail activity, network behavior and any related findings. Security Hub CSPM shows the instance’s security group allows SSH from anywhere, which gives a plausible entry path and raises the priority. Following the pre-agreed policy, the analyst requests approval to move the instance into a quarantine security group, takes an EBS snapshot for forensics and escalates to the infrastructure team. The root cause and the open security group are then fixed so the same path cannot be reused.
Compromised AWS Credentials
An attacker obtains temporary credentials from an EC2 instance role and uses them from outside AWS. GuardDuty detects the credentials being used from an unexpected location and raises a credential exfiltration finding.
Credential compromise is one of the fastest paths to broad damage, because the attacker inherits whatever the role can do. The analyst checks what the identity accessed, created or modified since the first anomalous call. Security Hub CSPM context shows the role has permissions well beyond what the application needs. The response revokes active sessions, rotates credentials and reviews every action taken. The follow-up work tightens the role to least privilege and enforces IMDSv2 on the instance fleet.
Unusual S3 Data Access
A bucket holding application exports suddenly shows a spike in object reads from an identity that rarely touches it. GuardDuty S3 Protection flags the pattern as anomalous.
S3 often holds backups, logs and business documents, so unusual access can mean data leaving the organization. The analyst confirms whether the identity is legitimate and whether a scheduled job explains the activity. Security Hub CSPM shows server access logging is disabled on the bucket, which limits the investigation. If the activity is unauthorized, access is restricted and the exposure assessed. Logging is then enabled so the next investigation has full evidence. Recovery planning for data stores is covered in more depth in our guide to AWS backup and disaster recovery.
Kubernetes Activity on Amazon EKS
A platform team runs microservices on EKS. GuardDuty EKS Protection flags a command executed inside a pod in the kube-system namespace, and Runtime Monitoring shows an unexpected process spawning.
Container incidents span two layers, Kubernetes and the AWS account beneath it, so evidence from only one layer is misleading. The analyst correlates Kubernetes audit activity, runtime behavior and the IAM identity that triggered the action. Security Hub CSPM shows the cluster API endpoint is publicly reachable. The platform team restricts endpoint access, investigates the workload and reviews role bindings, while the managed team documents the timeline for the incident record.
The Security Finding Funnel: From Detection to Remediation
A security finding funnel tracks how findings move from detection through triage, validation, escalation, containment and remediation. Measuring the drop-off and elapsed time at each stage shows where a security operation loses speed or accuracy, which is more useful than counting total alerts.
Every stage in the funnel has a distinct owner and a distinct failure mode. Findings that stall between validation and escalation usually point to unclear ownership. Findings that reach remediation but reappear usually point to infrastructure-as-code templates reintroducing the original weakness.
| Funnel stage | What is measured | Common failure mode | Planning objective |
|---|---|---|---|
| Finding generated | Findings produced per account and Region | Coverage gaps in unused Regions or accounts | Confirm detection coverage is complete |
| Finding triaged | Share of findings reviewed within the agreed window | Backlog grows faster than review capacity | Set review windows by severity |
| Finding validated | Share confirmed as true positives | High false-positive volume erodes attention | Tune suppression rules and trusted lists |
| Incident escalated | Validated findings routed to an owner | No clear owner for the affected resource | Map every resource to an accountable team |
| Threat contained | Time from confirmation to containment | Approvals delayed during off hours | Pre-agree containment actions by category |
| Root cause remediated | Findings closed without recurrence | Templates reintroduce the same weakness | Fix issues at the pipeline or template level |
Organizations should set their own baselines for each stage rather than adopting generic targets. A payment platform and an internal analytics environment carry different risks and deserve different thresholds.
Finding Priority Comparison: How to Rank What Matters
Finding priority should combine severity, resource criticality, exposure and supporting evidence rather than relying on the severity label alone. A medium-severity finding on an internet-facing production system can outrank a high-severity finding on an isolated development instance with no sensitive data.
Security Hub CSPM assigns severity using a normalized scale. A managed security operation adds business context that AWS cannot infer on its own, such as which systems handle payments, which accounts hold regulated data and which workloads can tolerate a brief isolation.
| Priority tier | Typical characteristics | Example | Recommended treatment |
|---|---|---|---|
| Critical | Active threat on an exposed or business-critical resource | Credential exfiltration on a production admin role | Immediate investigation and pre-approved containment |
| High | Strong threat signal or serious exposure on production | C&C traffic from an instance with open inbound access | Investigation within the defined response window |
| Medium | Plausible threat with limited exposure or confirmed misconfiguration | Unusual API calls from a known identity in a new Region | Validate with the owning team, then decide |
| Low | Configuration drift with no active threat | Missing tags or noncritical logging gaps | Batch into the remediation backlog |
| Informational | Expected or documented behavior | Scheduled scans from an approved security tool | Suppress with documentation and review periodically |
| Recurring | Same finding reappearing after closure | Security group rule restored by a template | Root-cause fix in the deployment pipeline |
The recurring tier is the one most teams overlook. A finding closed every month is a process failure, and fixing it at the template or pipeline level removes it permanently.
Measuring AWS Security Operations Performance
Measure AWS security operations with time-based metrics such as mean time to detect, acknowledge, investigate, contain, and remediate. Alongside these, track outcome metrics such as the reduction in recurring high-risk findings and unresolved exposure. Security scores are useful indicators but should never be read as proof that an environment is secure.
Response speed has a direct financial dimension. IBM’s Cost of a Data Breach Report 2025 placed the global average cost of a breach at USD 4.44 million, and the report consistently links faster identification and containment with lower breach costs. For AWS environments, much of that speed comes from connecting detection, context, and ownership before an incident begins.
| Metric | What it measures | Why it matters |
|---|---|---|
| Mean time to detect | Time between malicious activity and a finding | Indicates detection coverage and depth |
| Mean time to acknowledge | Time between finding creation and analyst review | Indicates operational responsiveness |
| Mean time to investigate | Time needed to establish incident context | Indicates quality of telemetry and correlation |
| Mean time to contain | Time from confirmed incident to containment | Indicates response readiness and approvals |
| Mean time to remediate | Time to correct the underlying weakness | Indicates long-term risk reduction |
Activity metrics, such as findings investigated or controls evaluated, show that work is happening. Outcome metrics show whether that work reduces risk. A useful monthly report covers both and explains significant findings, unresolved risks and recurring issues in language leadership can act on. Console screenshots are not a report.
Scores need careful interpretation. AWS explains that Security Hub CSPM security scores reflect control status, and that suppressed or archived findings affect the calculation. A high score does not mean an environment cannot be compromised, and a lower score does not mean a breach is underway. Treat the score as one input alongside actual findings and exposure.
Operating Model Comparison: Cost Structure, Coverage and Return
Organizations can run GuardDuty and Security Hub through an in-house team, a managed security provider, a co-managed arrangement, or by enabling the services without dedicated operations. Each model trades cost structure against coverage hours, investigation depth and accountability. The right choice depends on internal capacity and risk profile.
The most common gap is the first model in the table below: services enabled, findings generated and nobody reviewing them consistently. That arrangement produces detection capability without a security operation, and it can create false confidence. The table compares the models qualitatively because actual costs vary widely with environment size, Regions and coverage requirements.
| Operating model | Cost structure | Coverage and depth | Return indicator |
|---|---|---|---|
| Services enabled, no dedicated operations | AWS usage charges only | Findings generated but reviewed inconsistently | Low, since detection rarely leads to action |
| In-house security team | Salaries, tooling, training, retention | Deep business context, limited by team size and hours | Strong where the team has capacity and cloud skills |
| Fully managed security provider | Recurring service fee plus AWS usage | Continuous monitoring with defined response windows | Measured by response times and reduced recurring risk |
| Co-managed model | Shared service fee and internal effort | Provider handles monitoring and triage, internal team owns remediation | Strong when escalation paths and ownership are clear |
Both AWS services are priced on usage. GuardDuty charges by the volume of events and data analyzed, and Security Hub CSPM charges by security checks and finding ingestion. Each offers a 30-day free trial that estimates ongoing cost for your specific environment. The broader business case for outsourcing security operations is covered in our guide to the benefits of managed cloud security services.
Common Mistakes When Running GuardDuty and Security Hub
The most common mistakes are enabling both services without a review and response process, treating every finding as equally urgent, assuming a Security Hub score proves compliance, leaving Regions or accounts uncovered, and assuming the base GuardDuty service protects every workload type without the relevant protection plans.
Enabling services without an operating process is the most expensive of these, because it looks like security on paper while findings accumulate unread. The fix is simple to state and takes discipline to maintain: every finding category needs an owner, a review window and a defined next step.
Treating all findings equally causes alert fatigue. Analysts who face hundreds of undifferentiated alerts start skimming, and the one finding that matters gets lost. Priority tiers based on business context address this directly.
Region coverage is a quiet risk. Attackers who obtain credentials often launch resources in Regions the organization never uses, precisely because nobody is watching there. GuardDuty and Security Hub CSPM should be enabled in every Region, even unused ones. Where Regions are truly never needed, a service control policy should restrict them.
Protection coverage also needs deliberate choices. Security Hub CSPM includes controls that check whether specific GuardDuty protection plans are enabled, such as S3 Protection, EKS Audit Log Monitoring, Runtime Monitoring and Lambda Protection. Reviewing those controls against the workloads actually running shows where detection depth is missing. Under the AWS Shared Responsibility Model, configuring these services and acting on their findings is the customer’s responsibility, not AWS’s.
How the Model Scales From a Few Accounts to a Full AWS Organization
For a small environment with a few accounts, the model can stay lightweight: enable GuardDuty and Security Hub CSPM everywhere, route findings to one queue, and have a managed team handle review and escalation. Large organizations need delegated administration, central configuration, cross-Region aggregation and formal governance.
A smaller company still carries real exposure. A handful of accounts can hold customer data, production applications and highly privileged identities. Continuous GuardDuty monitoring combined with Security Hub CSPM gives structured detection and posture visibility without a large internal security team. The managed provider handles monitoring, investigation and reporting while engineers focus on the product. Organizations at that stage can pair this with the foundational controls in our cloud security checklist for SMBs.
Enterprises with dozens or hundreds of accounts face a consistency problem. Nobody can check each account manually every day, so centralization and automation become operational necessities. Governance matters as much as tooling: standard definitions for severity, ownership, exceptions, suppression, remediation windows and escalation. Without those definitions, different business units handle the same finding differently, and reports stop being comparable.
The underlying model stays the same at every size, and only the governance layer grows. That continuity lets an organization start with a simple setup and expand without rebuilding its security operation.
Where AI-Assisted Analysis Fits in AWS Security Operations
AI assistance can summarize findings, correlate related signals and draft incident timelines for analyst review, which reduces repetitive investigation work. It complements GuardDuty, Security Hub and documented response processes rather than replacing them, and its output is only as reliable as the telemetry and permissions behind it.
A practical use is an assistant that reads a GuardDuty finding, pulls related Security Hub CSPM findings and CloudTrail events, and prepares a plain-language timeline for the analyst on shift. The analyst still decides whether to contain, escalate or close. Keeping humans in control of high-impact actions is essential, because a model summarizing incomplete data will produce a confident but incomplete answer.
The quality boundary is clear. A poorly configured monitoring environment does not become a mature security operation because an AI interface sits on top of it. Coverage, correct protection plans and clear ownership come first, and AI assistance adds speed only after those foundations are in place.
Frequently Asked Questions About GuardDuty and Security Hub
What is the difference between GuardDuty and Security Hub?
GuardDuty is a threat detection service that identifies suspicious or malicious activity by analyzing AWS logs and telemetry. Security Hub CSPM is a posture management service that checks configurations against security standards and aggregates findings from GuardDuty and other services. GuardDuty asks whether something bad is happening, and Security Hub asks how exposed the environment is.
Do GuardDuty findings appear in Security Hub automatically?
Yes. When GuardDuty and Security Hub CSPM are enabled in the same account and Region, GuardDuty automatically sends its findings to Security Hub CSPM in the AWS Security Finding Format. Analysts can then review threat findings alongside control failures and findings from services such as Amazon Inspector and Amazon Macie in one place.
Do I need to enable GuardDuty and Security Hub in every AWS Region?
Enabling both services in every Region is widely recommended, including Regions you do not use, because attackers often launch resources where nobody is watching. Security Hub cross-Region aggregation centralizes findings in a home Region but does not enable the service in linked Regions, so each Region must be configured.
Does GuardDuty require agents?
GuardDuty’s foundational detection needs no agents because it analyzes CloudTrail management events, VPC Flow Logs and DNS logs directly. Runtime Monitoring is the exception. It uses a lightweight security agent on supported EC2, EKS and ECS workloads, which GuardDuty can deploy and manage automatically for supported environments.
Does Security Hub guarantee compliance with CIS, NIST or PCI DSS?
No. Security Hub CSPM evaluates technical controls against standards such as CIS AWS Foundations Benchmark, NIST SP 800-53 and PCI DSS. AWS states that this does not guarantee compliance or a successful audit. Compliance also requires governance, policies, evidence and processes beyond automated configuration checks.
Does Security Hub fix security problems automatically?
Security Hub CSPM identifies and centralizes findings but does not remediate them by default. Organizations can build automated responses using Security Hub automation rules and Amazon EventBridge. Disruptive actions such as isolating production workloads should follow documented policies and usually require human approval.
How is GuardDuty and Security Hub usage priced?
Both services are priced on usage. GuardDuty charges based on the volume of events and data it analyzes across enabled protection plans. Security Hub CSPM charges based on security checks performed and findings ingested. Each service offers a 30-day free trial and can estimate ongoing costs for your specific environment.
How does a managed security provider add value if AWS already runs the detection?
AWS generates findings, while a managed provider operates them. That covers continuous review, validation against business context, investigation, escalation through your existing workflows, coordinated remediation and root-cause analysis of recurring issues. The difference is between having detection capability and having an accountable security operation.
Moving From Security Dashboards to a Working Security Operation
AWS managed security works best when monitoring, Amazon GuardDuty and AWS Security Hub CSPM run as connected layers of one process. Monitoring supplies evidence. GuardDuty identifies potentially malicious activity. Security Hub CSPM adds posture context and one consolidated view. An accountable operations team turns findings into decisions and owned actions.
The practical objective for any organization running AWS workloads is to know what is happening across every account and Region, detect threats continuously, understand how each finding relates to the wider security posture, prioritize the risks that matter to the business and keep a documented path from detection to remediation. When you fix recurring findings at the source instead of closing them each month, the security operation starts reducing risk rather than recording it.
Cloud Secure Group operates AWS security inside your existing workflows, ticketing environment and escalation paths, so findings reach the right owners with the context they need. If you want to see how GuardDuty and Security Hub would run as part of your current operations, talk to our team.
Share on socials:
