Building a Multi-Account AWS Security Architecture: Centralized Monitoring with GuardDuty, Security Hub & More

Building a Multi-Account AWS Security Architecture: Centralized Monitoring with GuardDuty, Security Hub & More

Modern enterprises rarely run workloads in a single AWS account. They adopt multi-account structures for isolation, compliance boundaries, billing clarity, and least-privilege governance.However, once your environment grows beyond a few accounts, centralized security visibility becomes essential — you need one place to view findings from all workloads.

This guide explains how to design and implement a centralized AWS security monitoring architecture using AWS Organizations, GuardDuty, Security Hub, and complementary services such as AWS Config, CloudTrail, and CloudWatch — all aggregated under a dedicated security account.

1. Core Principle — Separate "Security" as a First-Class Account

Create a Security Tooling Account whose sole purpose is to:

• Own and aggregate all security findings.
• Host cross-account roles for analysts, SIEM pipelines, and automation.
• Contain no workloads or customer data.

This account becomes the single pane of glass for your enterprise security team.

2. Organize with AWS Organizations

1. Enable AWS Organizations and designate a Management Account (previously "Master").
2. Structure Organizational Units (OUs) such as:
3. • Security OU – Security account + logging account
   • Infrastructure OU – Shared services
   • Sandbox OU – Dev/Test
   • Production OU – Business workloads
4. Service Control Policies (SCPs): enforce guardrails like "deny disablement of GuardDuty," "deny leaving Organization," or "deny S3 public buckets."
5. Enable Trusted Access for GuardDuty, Security Hub, Config, and Detective so they can integrate across all member accounts.

3. Centralize Threat Detection with GuardDuty

GuardDuty detects anomalies from VPC flow logs, DNS logs, and CloudTrail.

Step-by-step

1. In the Security Account, designate it as the GuardDuty Administrator:

   aws guardduty enable-organization-admin-account --admin-account-id <security-account-id>
   

2. In all member accounts, enable GuardDuty via Organizations or StackSets.
3. Findings from every account automatically appear in the Security Account's console.
4. Automate response with EventBridge rules that forward GuardDuty findings to:
5. • A centralized Security Hub,
   • A Lambda remediation function,
   • Or an external SIEM (e.g., Splunk, QRadar, ELK) through Kinesis Firehose.

Tip: integrate with AWS Detective for visual graph investigation of GuardDuty alerts.

4. Aggregate Findings with Security Hub

Security Hub consolidates GuardDuty, Inspector, Macie, IAM Access Analyzer, and third-party partner findings under one normalized format (ASFF — AWS Security Finding Format).

Setup flow

1. In the Security Account:

   aws securityhub enable-organization-admin-account --admin-account-id <security-account-id>
   

2. Automatically enable Security Hub across the Org:

   aws securityhub enable-import-findings-for-product --product-arn arn:aws:securityhub:::product/aws/guardduty
   

3. Configure standards (e.g., CIS AWS Foundations Benchmark 1.2, NIST 800-53 Rev 5) Org-wide.
4. Findings from all accounts aggregate into the Security Account dashboard and can be exported via EventBridge → S3/SIEM.

Best practice: tag findings with AccountId, Region, and ResourceType so analytics tools can slice by OU or environment.

5. Complementary Services for Depth

6. Logging & Observability Architecture

1. Central Logging Account
2. • Aggregates CloudTrail logs from all accounts.
   • Enforce immutable S3 bucket (Object Lock + SSE-KMS).
   • Enable organization-wide AWS Config delivery channel.
3. Security Account subscribes to CloudWatch metrics, EventBridge events, and GuardDuty/Security Hub findings for correlation.
4. Stream selected logs to your SIEM via Kinesis Firehose or OpenSearch Service.

7. Automating Onboarding of New Accounts

When new accounts join the Organization:

• Auto-enable GuardDuty & Security Hub through delegated admin API or Control Tower Lifecycle Events.
• Enforce baseline SCPs and Config rules.
• Push CloudTrail and Config delivery channels to the Logging Account automatically (StackSets or Control Tower Customizations).

Sample automation Lambda (pseudocode):

def handler(event, context):
    account_id = event['detail']['serviceEventDetails']['createAccountStatus']['accountId']
    enable_guardduty_for(account_id)
    enable_securityhub_for(account_id)
    attach_scp(account_id, 'DenyDisableSecurityServices')

8. Cross-Account Access and Least Privilege

• Use IAM Roles with externalId for analysts:Example — SecurityAuditRole trusted by the Security Account only.
• Disable root user access in member accounts.
• Grant read-only CloudWatch and Security Hub permissions via AWS-managed SecurityAudit policy.

9. Alerting and Automation

• EventBridge Rules trigger on Security Hub findings → route to SNS or Slack via Lambda.
• Automatic remediation examples:
• • Public S3 bucket → auto-remove public ACLs.
  • Exposed EC2 port 22 → apply stricter security group.
  • High-severity GuardDuty alert → isolate instance with SSM automation doc.

10. Reporting & Continuous Improvement

1. Export aggregated findings daily to S3 → Athena for dashboards (query by OU, severity, control ID).
2. Integrate with AWS QuickSight or external BI tool.
3. Run monthly governance reviews: verify all accounts remain enrolled and compliant.
4. Periodically review AWS Security Hub standards (CIS, NIST, PCI-DSS) and enable new controls.

11. Summary — A Layered, Governed Approach

12. Final Thoughts

A centralized monitoring design does more than simplify dashboards—it standardizes your organization's security posture and enables rapid, automated response across dozens or hundreds of AWS accounts.

Think of your Security Account as your mission-control center:GuardDuty detects, Security Hub aggregates, Config audits, and CloudTrail proves what happened.When combined with solid automation and governance, this architecture delivers the holy grail of cloud security: visibility, speed, and control at scale.

Author's note:This approach aligns with AWS best practices described in the AWS Security Reference Architecture (SRA). For production, always enable Organization-wide delegated admin for GuardDuty, Security Hub, Config, Detective, and Macie, and maintain separate Logging and Security accounts under a governed Organization.