GuardDuty, Inspector, Security Hub and Config
These services form the backbone of AWS's threat detection and security posture management.
When I first enabled them across the Lab, I ticked nearly every control and option available to see what they all did. That quickly became a lesson in cost awareness: the more you turn on, the more you pay.
The setup itself is straightforward:
- Guard Duty: handles threat detection using logs from CloudTrail, VPC Flow Logs, and DNS.
- Inspector: scans EC2 and container workloads for vulnerabilities and unintended network exposure.
- Security Hub: pulls it all together, aggregating findings across services and accounts into a unified view.
- Config: provides a detailed view of your AWS resources, their configurations, and relationships, and how they change over time.
In my Lab, the goal is secure learning, not blanket compliance. I turn on specific rules I want to experiment with, observe the impact, and switch them off when I’m done. This keeps the signal-to-noise ratio manageable while still building familiarity with real-world security tooling. Over time, this helps build muscle memory for what matters in production, without being buried in alerts.
Config
Config works by continuously recording changes to your AWS resources, tracking configuration history, and evaluating compliance against rules. It’s a powerful tool, but it comes at a cost. The more resources and changes you track, the more you pay. That can add up quickly in a lab environment, especially if you’ve turned on broad or unnecessary rules.
But the cost is more than dollars. Enabling more controls increases the volume of alerts you need to review, triage, and remediate. These tools are not “set and forget” as they need regular attention to remain valuable and cost-effective.
Understanding that AWS Config is the source of truth for Security Hub, suppose a control is enabled, but AWS Config isn’t recording the associated data. In that case, Security Hub will flag its status as “WARNING”, guiding you to adjust your config rules appropriately:
To support this approach, I’ve added two stack sets to the public repository, which you could deploy to your management account:
- Baseline Config: This overrides the default configuration recorder deployed by Control Tower, reducing the frequency and scope of logging to significantly reduce cost.
- Config Light: A minimal footprint recorder used in development accounts.
Inspector
Inspector can become a large proportion of your costs in a lab environment because of how often it scans resources within your accounts. Luckily, AWS provide some extra features to help manage this - check out the Inspector Suppressor Service for one way of minimising costs while retaining functionality for Lambda scanning.
Enabling Inspector for your accounts is simple, just navigate to Account Management in the Inspector service page and click Activate on the accounts you want managed. Inspector then performs the setup for you, and you will see an updated view in the Organisation list at the bottom of the page:
