Compliance, Auditing, and Network Governance

Why Compliance and Network Governance Matter for ANS-C01

Compliance and network governance is the operational discipline of proving — continuously, automatically, and at scale — that your AWS network meets policy requirements. Domain 4 task 4.2 of the ANS-C01 exam ("Validate and audit security by using network monitoring and logging services") sits at the intersection of every other domain: routing changes generate CloudTrail events, security group modifications generate Config evaluations, traffic flows generate VPC Flow Log records, and threats surface as GuardDuty findings. The exam expects you to architect this audit fabric across a multi-account AWS Organization, not just within a single account.

This Specialty-depth study guide walks through the compliance and governance toolset that ANS-C01 tests: VPC Flow Logs at the traffic level, CloudTrail at the API level, AWS Config at the resource-state level, Firewall Manager at the policy level, GuardDuty at the threat-detection level, Security Hub at the aggregation level, Trusted Advisor at the snapshot level, and CloudWatch alarms at the alerting level. We cover the specific log fields you must understand, the canonical Config rules for networking, the Firewall Manager prerequisites and policy types, the GuardDuty network-related findings, the centralized logging architecture for a multi-account organization, automated incident response patterns with EventBridge and Lambda, and the differences between continuous (Config) and point-in-time (Trusted Advisor) compliance evaluation.

By the end of this guide you should be able to design a complete network audit architecture for an AWS Organization with hundreds of accounts. We close with FAQ, scenario walkthroughs, and Mandarin trap callouts.

The Three-Layer Audit Strategy

ANS-C01 expects you to think about network audit as a three-layer model:

• API layer (CloudTrail): who did what, when, from where? Records every AWS API call, including network changes (CreateRoute, AuthorizeSecurityGroupIngress, AttachInternetGateway).
• Resource state layer (AWS Config): what does the configuration look like right now, and how has it changed? Records resource configurations and evaluates them against rules.
• Traffic layer (VPC Flow Logs, Traffic Mirroring): what packets actually flowed through the network? Records connection metadata (Flow Logs) or full packet content (Traffic Mirroring).

Each layer answers different questions. CloudTrail tells you "who opened SSH to the world." Config tells you "which security groups currently have 0.0.0.0/0:22 allowed." Flow Logs tell you "did anyone actually connect on SSH from a public IP." All three layers feed into Security Hub for unified findings, and into SIEM tools (Splunk, Datadog, Sumo Logic) for threat correlation.

VPC Flow Logs for Security Analysis

VPC Flow Logs capture metadata about IP traffic flowing through ENIs in your VPC. For security analysis, the extended fields added in versions 3, 4, and 5 are critical: pkt-srcaddr and pkt-dstaddr (showing the original source/destination through NAT), pkt-src-aws-service and pkt-dst-aws-service (identifying AWS services in the traffic), tcp-flags (SYN, ACK, FIN, RST), and flow-direction (ingress vs egress).

Detecting attack patterns with Flow Logs

Several attack patterns surface clearly in Flow Logs:

• Port scanning: many connection attempts (high SYN count, low ACK count) from a single source to many destination ports. Detect with tcp-flags = 2 (SYN only) and group by source IP.
• Lateral movement: unusual east-west traffic between subnets that should not communicate. Detect by comparing flow logs against an expected communication graph.
• Data exfiltration: high outbound byte counts to unfamiliar destinations. Detect with flow-direction = egress and large bytes values to non-corporate IPs.
• C2 beaconing: regular small outbound connections at fixed intervals. Detect with time-series analysis of connection start times.
• Cryptojacking: outbound to mining pool IPs (often resolved DNS first; Flow Logs catch the resulting traffic).

Athena queries for compliance

Flow Logs delivered to S3 in Parquet format support efficient Athena queries:

-- Top 10 sources of REJECT traffic
SELECT srcaddr, COUNT(*) as drops
FROM vpc_flow_logs
WHERE action = 'REJECT'
  AND year = '2026' AND month = '05'
GROUP BY srcaddr
ORDER BY drops DESC
LIMIT 10;

-- Identify port scans (many destination ports from one source)
SELECT srcaddr, COUNT(DISTINCT dstport) as ports_scanned
FROM vpc_flow_logs
WHERE action = 'ACCEPT' AND tcp_flags = 2
GROUP BY srcaddr
HAVING COUNT(DISTINCT dstport) > 100;

-- Detect data exfiltration (large outbound to external IPs)
SELECT pkt_dstaddr, SUM(bytes) as bytes_out
FROM vpc_flow_logs
WHERE flow_direction = 'egress'
  AND pkt_dstaddr NOT LIKE '10.%' AND pkt_dstaddr NOT LIKE '172.%'
GROUP BY pkt_dstaddr
ORDER BY bytes_out DESC;

For ANS-C01, memorize that Flow Logs go to S3 (with Athena), CloudWatch Logs (with Logs Insights), or Kinesis Data Firehose (for streaming to SIEM). Each destination has different cost and query characteristics — S3 is cheapest for retention, CloudWatch is fastest for ad-hoc, Firehose is best for streaming to external SIEM.

Flow Log records: ACCEPT, REJECT, NODATA, SKIPDATA

Flow Log action field values:

• ACCEPT: traffic was allowed by SG and NACL.
• REJECT: traffic was blocked by SG or NACL. Useful for diagnosing connectivity failures and detecting probes.
• NODATA: no traffic during the aggregation interval. Does NOT mean traffic was blocked.
• SKIPDATA: ENI capacity exceeded; some flows were skipped (not all flows were captured). Indicates Flow Logs were truncated.

The exam often tests the difference: NODATA means "nothing happened," SKIPDATA means "stuff happened but we missed some of it." Confusing the two leads to wrong audit conclusions.

CloudTrail for Network API Audit

CloudTrail records every AWS API call in your account. For network audit, the relevant API events include:

• VPC: CreateVpc, DeleteVpc, ModifyVpcAttribute, AssociateVpcCidrBlock
• Subnet: CreateSubnet, DeleteSubnet, ModifySubnetAttribute
• Route table: CreateRoute, DeleteRoute, ReplaceRoute, AssociateRouteTable
• Security Group: AuthorizeSecurityGroupIngress, AuthorizeSecurityGroupEgress, RevokeSecurityGroupIngress, CreateSecurityGroup
• NACL: CreateNetworkAcl, CreateNetworkAclEntry, DeleteNetworkAclEntry
• IGW/NAT GW: AttachInternetGateway, DetachInternetGateway, CreateNatGateway
• VPN/DX: CreateVpnConnection, CreateVpnGateway, CreateDirectConnectGatewayAssociation
• TGW: CreateTransitGateway, CreateTransitGatewayRoute, AssociateTransitGatewayRouteTable

CloudTrail organization trails

For multi-account audit, configure an organization trail in the management account that captures events from all member accounts to a centralized S3 bucket in a dedicated security account. Member accounts cannot disable the org trail — this is the key control for trustworthy audit.

Detecting suspicious changes

CloudTrail metric filters in CloudWatch Logs can alert on suspicious patterns:

• AuthorizeSecurityGroupIngress with cidrIp = "0.0.0.0/0" → potential exposure.
• DeleteFlowLogs → tampering attempt.
• DeleteTrail or StopLogging → audit evasion.
• CreateAccessKey + AuthorizeSecurityGroupIngress in rapid succession → possible compromise.

These metric filters drive SNS alerts or Lambda automated remediation.

AWS Config for Continuous Compliance

AWS Config records the configuration state of AWS resources over time and evaluates them against rules continuously. For network compliance, the canonical managed Config rules include:

• restricted-ssh: detects SGs with TCP 22 open to 0.0.0.0/0.
• restricted-common-ports: detects SGs with common ports (3389, 1433, 5432, etc.) open to the world.
• vpc-sg-open-only-to-authorized-ports: SGs may only have allow rules for explicitly approved ports.
• vpc-flow-logs-enabled: every VPC must have Flow Logs enabled.
• vpc-default-security-group-closed: the default SG must have no rules.
• internet-gateway-authorized-vpc-only: IGWs may only attach to specifically tagged VPCs.
• subnet-auto-assign-public-ip-disabled: subnets must not auto-assign public IPs.
• elb-acm-certificate-required: ELBs must use ACM certificates (not self-signed).
• acm-certificate-expiration-check: alerts on certificates approaching expiry.
• alb-waf-enabled: ALBs must have a WAF Web ACL associated.

Custom Config rules

For requirements not covered by managed rules, write custom Config rules backed by Lambda. The Lambda receives the resource configuration and returns COMPLIANT or NON_COMPLIANT. Use cases: "all NLBs must have specific tags," "Transit Gateway route tables must include blackhole routes for unauthorized CIDRs," "Network Firewall must have specific rule groups attached."

Config aggregator for multi-account

A Config aggregator collects Config data from member accounts across an AWS Organization into a single management account or delegated administrator. The aggregator provides a unified view of compliance across the entire org without duplicating Config data per account.

For ANS-C01, the canonical answer for "centralize compliance evaluation across 100 accounts" is Config aggregator + organization-wide Config conformance pack.

Continuous vs point-in-time evaluation

AWS Config provides continuous evaluation — every change to a resource triggers re-evaluation. Trusted Advisor provides point-in-time snapshots — daily or weekly summaries of configuration. For active security monitoring, Config is the right tool. Trusted Advisor is an executive-level summary, not a real-time control.

AWS Firewall Manager for Organization-Wide Policy

AWS Firewall Manager is the multi-account orchestration layer for security network policies. It supports several policy types relevant to ANS-C01:

• WAF policy: deploys a Web ACL across CloudFront distributions, ALBs, and API Gateways in scope.
• Shield Advanced policy: ensures Shield Advanced is enabled on resource types in scope.
• Network Firewall policy: deploys AWS Network Firewall + firewall policy across VPCs in scope.
• Security Group audit policy: continuously evaluates that SG rules match an allowed pattern.
• Security Group content audit policy: enforces a primary SG attached to all ENIs in scope.
• Security Group usage audit policy: detects unused or redundant SGs.
• DNS Firewall policy: deploys Route 53 Resolver DNS Firewall rule groups across VPCs in scope.
• Third-party firewall policy: integrates with partner firewalls (Palo Alto, Fortinet, Check Point).

Firewall Manager prerequisites

Firewall Manager requires:

• AWS Organizations with all features enabled (not just consolidated billing).
• AWS Config enabled in every member account that will be in scope.
• A delegated administrator account designated for Firewall Manager.
• Service-linked roles created in member accounts.

Auto-remediation in Firewall Manager

When a non-compliant resource is detected (e.g., an ALB without the required Web ACL), Firewall Manager can either flag the resource as non-compliant or automatically remediate. Auto-remediation creates the missing association. For SG policies, Firewall Manager can attach the required SG or remove unauthorized rules from existing SGs.

The exam tests "auto-detect new accounts and apply baseline." Firewall Manager + Organizations is the answer: when a new account joins the org, Firewall Manager auto-deploys policies to in-scope resources.

Amazon GuardDuty for Network Threat Detection

GuardDuty is the managed threat detection service that analyzes VPC Flow Logs, CloudTrail, DNS query logs, EKS audit logs, S3 data events, and several other sources for indicators of compromise. Network-related GuardDuty findings include:

• Recon:EC2/PortProbeUnprotectedPort: instance is being scanned on an exposed port.
• UnauthorizedAccess:EC2/SSHBruteForce and RDPBruteForce: brute-force authentication attempts.
• UnauthorizedAccess:EC2/MetadataDNSRebind: DNS rebinding to access instance metadata.
• CryptoCurrency:EC2/BitcoinTool.B!DNS: instance is querying known cryptocurrency mining pool DNS.
• Backdoor:EC2/C&CActivity.B: instance is communicating with known C2 server.
• Behavior:EC2/NetworkPortUnusual: traffic to a port that is unusual for this instance.
• Trojan:EC2/DGADomainRequest.B: instance is generating algorithmic domains (DGA) for malware C2.
• PenTest:IAMUser/KaliLinux: API calls from a known Kali Linux IP block.

GuardDuty for organizations

Like Firewall Manager, GuardDuty supports a delegated administrator model with multi-account coverage. Findings from member accounts surface in the delegated administrator account. The delegated administrator can configure threat lists (custom IP allow/deny) and trusted IP lists.

Integration with EventBridge and Security Hub

GuardDuty findings are emitted as EventBridge events with detailed structure (finding type, severity, resource details, affected entities). EventBridge rules trigger Lambda functions for automated remediation:

• High-severity finding on EC2 → isolate ENI by attaching restricted SG.
• IAM finding → disable access keys, rotate passwords.
• S3 finding → block public access on bucket.

GuardDuty findings also flow to Security Hub for unified vulnerability and compliance views.

Amazon Security Hub: Unified Findings

Security Hub aggregates findings from GuardDuty, Macie, Inspector, IAM Access Analyzer, Firewall Manager, third-party security tools, and your own custom integrations. It provides a unified findings format (AWS Security Finding Format, ASFF) and standard compliance frameworks (CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, PCI DSS).

For ANS-C01, Security Hub matters because it is the canonical answer for "single pane of glass for security findings across the organization." Findings are normalized into ASFF, deduplicated, and surfaced in a single dashboard. Insights and custom action targets enable workflow automation.

Centralized Logging Architecture

The reference architecture for compliance logging in a multi-account AWS Organization:

┌─────────────────────────────────┐
│  AWS Organizations Management   │
│  - Org-wide CloudTrail          │
│  - Firewall Manager admin       │
└────────────────┬────────────────┘
                 │
                 ▼
┌─────────────────────────────────┐
│  Security Account (audit)       │
│  - Centralized S3 log bucket    │
│  - Security Hub aggregator      │
│  - Config aggregator            │
│  - GuardDuty admin              │
│  - SIEM ingestion               │
└────────────────┬────────────────┘
                 │
                 ▼
┌──────────────────────────────────────────┐
│  Member accounts                          │
│  - VPC Flow Logs → security S3            │
│  - CloudTrail → org trail S3              │
│  - Config → Config aggregator             │
│  - GuardDuty member → org admin           │
│  - Network Firewall logs → security S3    │
└──────────────────────────────────────────┘

Key controls:

• Centralized log bucket in security account with Object Lock for tamper protection.
• Bucket policy denies delete from any non-security-account principal.
• KMS-encrypted at rest with key policy allowing only the security account.
• Cross-account log delivery via S3 bucket policy granting service principals (vpc-flow-logs, cloudtrail) the PutObject permission.

Automated Incident Response

Automated incident response uses EventBridge rules on security findings to trigger remediation Lambda functions. Common patterns:

Pattern 1: SG opens 0.0.0.0/0:22

Config rule restricted-ssh detects non-compliance
     ↓ (EventBridge event)
Lambda function:
  - Tags the SG as "non-compliant"
  - Removes the offending rule via RevokeSecurityGroupIngress API
  - Notifies SNS topic with details

Pattern 2: GuardDuty high-severity finding on EC2

GuardDuty finding (severity > 7) emitted to EventBridge
     ↓
Lambda function:
  - Snapshots the affected EBS volume for forensics
  - Replaces the instance's SG with quarantine SG
  - Disables IAM access keys associated with instance role
  - Creates incident in PagerDuty

Pattern 3: VPC Flow Log anomaly detected

CloudWatch Logs metric filter on Flow Log REJECT spike
     ↓
CloudWatch Alarm triggers SNS
     ↓
Lambda function:
  - Queries Athena for top sources of REJECT
  - Adds top sources to AWS Network Firewall stateless rule group (block)
  - Posts to Slack

EventBridge + Lambda + Step Functions is the canonical "automated incident response" answer for ANS-C01.

Trusted Advisor for Snapshot Compliance

Trusted Advisor provides snapshot-level compliance checks across cost, performance, security, fault tolerance, and service limits. The relevant security checks for networking include:

• Security Group rules: open ports
• Exposed access keys
• ELB security policy: weak ciphers
• VPN tunnel state
• Direct Connect connection redundancy

Trusted Advisor checks are evaluated periodically (typically daily). For real-time compliance, prefer AWS Config. Trusted Advisor is best for executive dashboards and quarterly reviews.

類比三：公司的合規組織架構

把 AWS Organization 想成跨國公司：

• Management account = 總部董事會。設定全公司政策（org trail、Firewall Manager admin）。
• Security account / Log Archive = 中央保全與審計部門。所有分公司的監視錄影都送到這個部門儲存（centralized S3 bucket with Object Lock）。
• Member accounts = 分公司。各做各的業務，但要把日誌送回總部。
• Delegated administrator = 授權代行的安全長。可以代總部執行 Firewall Manager / GuardDuty / Security Hub 的管理。

中央保全部門的儲存室上鎖（S3 Object Lock），連分公司經理也不能刪日誌，這就是「tamper-resistant audit」的概念。

Common Scenarios

Scenario A: PCI DSS compliance for an AWS Organization

Requirement: a fintech company has 30 AWS accounts. They need to prove PCI DSS compliance with continuous evaluation, centralized log retention for 7 years, and automated remediation of common misconfigurations.

Architecture:

• AWS Control Tower deploys Log Archive + Audit accounts.
• Org-wide CloudTrail to Log Archive S3 bucket with Object Lock (Compliance mode, 7-year retention).
• AWS Config in every account, deploying the PCI DSS conformance pack via StackSets.
• Config aggregator in the Audit account.
• Firewall Manager (delegated admin in Audit account) with WAF policy enforcing managed rule groups on all ALBs.
• GuardDuty enabled organization-wide with Audit as delegated admin.
• Security Hub with PCI DSS standard enabled, aggregating findings to Audit account.
• VPC Flow Logs to Log Archive S3 with Athena.
• EventBridge rules trigger Lambda for auto-remediation of restricted-ssh and restricted-common-ports findings.

This stacks every layer of the audit fabric.

Scenario B: Detecting and responding to a SG misconfiguration

Requirement: a developer accidentally opens TCP 22 to 0.0.0.0/0 on a production SG. The security team needs detection within minutes and automatic remediation.

Solution:

• AWS Config rule restricted-ssh evaluates the change.
• Config emits Configuration Change event.
• EventBridge rule matches the event, triggers Lambda.
• Lambda calls RevokeSecurityGroupIngress to remove the rule, posts to SNS.
• CloudTrail logs the original change with the developer's IAM identity.
• Security Hub aggregates the finding for the SOC dashboard.

Within ~3 minutes the misconfiguration is detected, reverted, and reported. This is the canonical ANS-C01 "automated remediation" pattern.

Common Exam Traps

Other anti-patterns:

• Sending Flow Logs to CloudWatch Logs alone without S3 retention — CloudWatch Logs storage is expensive at scale.
• Using individual account CloudTrail trails instead of an org trail — fragmented audit, bypassable by member accounts.
• Forgetting to deploy Config rules to every account in scope — Firewall Manager and many compliance evaluations need Config in member accounts.
• Believing Security Hub creates findings — Security Hub aggregates findings from other services; it does not generate its own (except CIS/PCI/etc. compliance findings via Config rules).
• Assuming Reachability Analyzer replaces Flow Logs — Reachability Analyzer simulates connectivity from configuration; Flow Logs show actual traffic.
• Putting log buckets in the management account — buckets should be in a dedicated security/audit account for separation of duties.
• Forgetting that GuardDuty must be enabled in every Region you operate in (it is regional).

Operational Considerations

Cost optimization for compliance logging

Compliance logging at scale becomes expensive. Mitigations:

• Send Flow Logs to S3 (Parquet, with partitioning) instead of CloudWatch Logs for retention.
• Use S3 Intelligent-Tiering or lifecycle to Glacier for older logs.
• Filter Flow Logs to capture only REJECT records if ACCEPT volume is overwhelming (loses some visibility but reduces cost).
• Aggregate VPC Flow Logs at the VPC level, not subnet level, when possible.
• Use CloudTrail Lake for queryable trail history without loading separate analytics infrastructure.

Log integrity controls

For tamper-resistant logs:

• S3 Object Lock in Compliance mode (cannot be disabled by anyone, including root) for the retention period.
• KMS-encrypted at rest with a key in the security account.
• S3 bucket policy denies s3:DeleteObject for all principals except the AWS Backup service role.
• Versioning enabled with MFA delete on the bucket.

FAQ

Q1: What is the difference between AWS Config and CloudTrail?

CloudTrail records API calls — who did what, when, from where. Config records resource state — what does the resource look like at this moment, how has it changed over time. CloudTrail answers "who deleted the security group rule." Config answers "is the security group still compliant." For complete audit, you need both. CloudTrail is event-driven; Config is state-driven.

Q2: How do I centralize VPC Flow Logs across an AWS Organization?

Configure each VPC's Flow Logs to deliver to a centralized S3 bucket in a dedicated security/audit account. The destination bucket policy must grant the vpc-flow-logs.amazonaws.com service principal s3:PutObject permission, scoped by the source account ID. Use Athena partition projection to query the centralized bucket. For real-time SIEM integration, use Kinesis Data Firehose as the destination with cross-account delivery.

Q3: When should I use Reachability Analyzer instead of Flow Logs for audit?

Reachability Analyzer is a configuration analysis tool — it simulates connectivity from your route tables, security groups, NACLs, and other config without sending real packets. Use it for proactive verification ("can App tier reach DB tier?"). Flow Logs show actual traffic — use them for retrospective analysis ("did App tier actually connect to DB tier on TCP 5432?"). They complement each other: Reachability Analyzer for pre-deployment verification, Flow Logs for post-deployment monitoring.

Q4: How do I ensure Firewall Manager applies policies to new accounts automatically?

Firewall Manager policies have an "include all accounts" or "include specific OUs" scope. When a new account joins the AWS Organization, Firewall Manager evaluates the policy scope and auto-applies if the account matches. The new account must have AWS Config enabled (typically deployed via Control Tower or via StackSets in the org) for Firewall Manager to evaluate compliance. Without Config, Firewall Manager cannot determine policy compliance state.

Q5: What is the GuardDuty data source for network threats?

GuardDuty consumes VPC Flow Logs (it accesses them directly without you exporting) and DNS query logs from Route 53 Resolver. It does NOT consume your S3 Flow Logs — GuardDuty has its own internal access. For EKS-specific threats, GuardDuty also consumes EKS audit logs. For S3-specific threats, it consumes S3 data events from CloudTrail. Each data source is enabled separately and incurs separate costs.

Q6: How do I respond to a CloudTrail event indicating possible AWS account compromise?

Use EventBridge rules on CloudTrail events from CloudWatch Logs metric filters. Trigger Lambda for: (1) disabling the affected IAM access key, (2) rotating the IAM user password, (3) snapshotting affected EC2 volumes for forensics, (4) detaching/replacing the instance role, (5) notifying the incident response team. AWS publishes reference implementations in the AWS Solutions Library for "Automated Security Response."

Q7: What is the difference between AWS Config conformance pack and AWS Security Hub standard?

A conformance pack is a deployable bundle of Config rules + remediation actions you apply to one or more accounts via Config. A Security Hub standard is a curated set of controls (each backed by Config rules or other checks) that Security Hub evaluates and surfaces in the Security Hub dashboard. Security Hub standards are read-only frameworks; Config conformance packs are deployable artifacts. They complement each other: Conformance pack deploys the rules, Security Hub aggregates the findings.

Q8: How do I detect data exfiltration through DNS in AWS?

Three layers: (1) Route 53 Resolver Query Logging captures every DNS query from VPCs; deliver to S3 + Athena. (2) Route 53 Resolver DNS Firewall blocks queries to known-bad domains and emits findings on attempts. (3) GuardDuty consumes DNS query logs and surfaces findings like Trojan:EC2/DGADomainRequest.B for algorithmic domain generation indicative of malware. Combine all three for layered DNS exfiltration detection.

Q9: Can I delete Flow Logs after they are written?

The Flow Logs themselves (the configuration) can be deleted via DeleteFlowLogs. The captured log data depends on the destination — S3 objects can be deleted (but Object Lock prevents this for compliance), CloudWatch Logs streams can be deleted, Firehose delivery streams can be paused. CloudTrail records the DeleteFlowLogs API call — that is the audit trail of someone disabling logging. Always alarm on DeleteFlowLogs events.

Q10: What is the role of AWS Network Manager in compliance audit?

AWS Network Manager (part of Transit Gateway) provides a global network view: TGW topology, route tables, attachments, peering, BGP sessions. For audit purposes, Network Manager surfaces topology changes and route changes via CloudTrail and CloudWatch Events. It complements Config (which records the resource state) and Flow Logs (which records traffic). Network Manager is mostly diagnostic, not enforcement.

Summary: Compliance Audit Answer Patterns

When you read an ANS-C01 question on compliance, audit, or governance, run through this checklist:

• Is the question about who changed what? → CloudTrail.
• Is the question about resource state compliance? → AWS Config.
• Is the question about traffic-level visibility? → VPC Flow Logs.
• Is the question about packet-level forensics? → VPC Traffic Mirroring.
• Is the question about org-wide policy enforcement? → Firewall Manager (requires Organizations + Config).
• Is the question about threat detection? → GuardDuty.
• Is the question about unified findings dashboard? → Security Hub.
• Is the question about continuous vs point-in-time? → Config (continuous), Trusted Advisor (point-in-time).
• Is the question about automated remediation? → EventBridge → Lambda.
• Is the question about tamper-proof logs? → S3 Object Lock + Compliance mode in dedicated security account.

Master the three-layer audit model (CloudTrail / Config / Flow Logs), the Firewall Manager prerequisites, the GuardDuty network findings, and the centralized logging architecture, and ANS-C01 task 4.2 questions on compliance and governance become predictable.

常考陷阱

• Firewall Manager 需要 Organizations all-features + Config + 委派管理員 — 缺一不可。
• Trusted Advisor 是 point-in-time，不是 continuous — 即時合規評估用 Config。
• Flow Logs 不抓 payload — payload 採證用 Traffic Mirroring。
• NODATA ≠ 流量被擋 — NODATA 表示沒流量；SKIPDATA 表示有流量但抓不齊。
• Org trail 不能被 member account 關閉 — 這是審計可信度的核心。
• GuardDuty 是 regional 服務 — 每個你用的 region 都要開。
• Config 在每個 member account 都要開 — Firewall Manager 跟 conformance pack 才能評估。
• S3 Object Lock Compliance mode 連 root 也不能改 — 真正的 tamper-resistant，但要事先評估保留期。
• Security Hub 不產生 finding（除了合規標準） — 它是 aggregator；threat detection 仰賴 GuardDuty。
• Reachability Analyzer 是模擬，不是實測 — 實際流量看 Flow Logs。
• DeleteFlowLogs 一定要 alarm — 這是 audit evasion 的明顯訊號。
• Log 集中放 Log Archive 帳號 — 不要放在 management account 或 member account，要分離權責。