Why Manual Compliance Fails in the Cloud

Traditional compliance workflows rely on documentation, periodic audits, and manual checks. In on-premises environments, infrastructure changes slowly enough that these processes can keep up. Cloud environments are fundamentally different: new resources can be provisioned in seconds, configurations can drift silently, and teams can scale infrastructure across multiple regions without centralized oversight.

The core disadvantages of manual cloud compliance include:

• Scale: Hundreds or thousands of resources across accounts and regions make manual auditing impractical.
• Speed: By the time a manual audit catches a misconfigured resource, it may already have been exploited or removed.
• Documentation gaps: Manual processes are prone to inconsistent record-keeping, which creates problems during formal audits.
• Human error: Checklists and spreadsheets introduce opportunities for oversight and inconsistency.

Organizations migrating to AWS need to rethink compliance as an automated, continuous process rather than a periodic manual activity.

Replacing Manual Processes with Managed Compliance Services

AWS offers several approaches to automating compliance. Options include AWS Partner Network solutions such as HPE Continuous Compliance and the use of Chef InSpec integrated with AWS Systems Manager. However, the most direct and native starting point is AWS Config with its managed rules, which requires no third-party tooling and integrates tightly with the rest of the AWS ecosystem.

The principle behind managed compliance services is straightforward: define the desired configuration state of your infrastructure, then continuously compare actual resource configurations against that desired state. Any deviation is flagged, logged, and optionally remediated automatically. This gives auditors a continuous, queryable compliance record rather than a point-in-time snapshot.

AWS Config: Core Concepts

AWS Config is a managed service that provides a detailed, continuously updated inventory of the resources in your AWS account — including EC2 instances, S3 buckets, security groups, IAM roles, VPCs, and more. It records how those resources are configured, tracks relationships between them, and maintains a historical timeline of configuration changes.

Key capabilities of AWS Config include:

• Configuration recording: AWS Config captures the state of supported resources whenever a change occurs, creating a detailed audit trail.
• Resource relationships: It maps how resources relate to each other — for example, which EC2 instances are associated with a given security group.
• Change notifications: Config can notify administrators via Amazon Simple Notification Service (SNS) when a resource is created, modified, or deleted.
• Compliance evaluation: Config evaluates resources against defined rules on a continuous or periodic basis and reports compliance status.

In practical terms, AWS Config acts as the monitoring, logging, and reporting backbone for your AWS compliance posture.

How AWS Config Rules Work

A Config rule defines a desired configuration setting for an AWS resource or for your entire account. AWS Config continuously evaluates each in-scope resource against every applicable rule. If a resource violates a rule — either at the moment of a configuration change or during a periodic evaluation — Config marks that resource as non-compliant and triggers an SNS notification to alert the responsible team.

Rules can be scoped to a specific resource type (for example, all EC2 instances) or applied account-wide. Evaluation can be triggered by configuration changes, on a defined schedule, or both.

AWS Config Managed Rules

AWS provides a library of managed rules — predefined compliance checks authored and maintained by AWS. These rules cover common security and operational best practices and can be enabled with minimal configuration. Administrators can also customize the parameters of managed rules to fit organizational requirements, though this is distinct from creating fully custom rules using AWS Lambda.

Managed rules are organized across several categories:

• Compute: EC2 instance types, AMI compliance, EBS encryption
• Storage: S3 bucket public access, versioning, server-side encryption
• Security, Identity, and Compliance: IAM password policies, root account MFA, CloudTrail enablement
• Network and Content Delivery: VPC flow logs, security group rules, unrestricted SSH access
• Management and Governance: Required tags, Config recorder status

As of the original publication date of this article (September 2019), AWS Config offered more than 100 predefined managed rules. The current number is larger; check the AWS documentation for the current list.

Example: Enforcing EC2 Instance Types

A practical example is the desired-instance-type managed rule. This rule checks whether EC2 instances in scope match a list of permitted instance types. If a developer launches an instance using an instance type not on the approved list — perhaps a large, expensive instance type that violates cost governance — Config marks the instance as non-compliant and sends an alert. The operations or security team can then investigate and take corrective action.

Similar rules exist for Amazon RDS, Redshift, S3, and IAM, providing broad coverage out of the box.

Getting Started: Enabling AWS Config Managed Rules

Follow these high-level steps to enable managed rules in the AWS Management Console:

1. Enable AWS Config in your account and region via the AWS Management Console, CLI, or CloudFormation. Configure an S3 bucket to receive configuration snapshots and an SNS topic for notifications.
2. Select a managed rule. In the Config console, navigate to Rules and choose Add rule. Browse or search the managed rule library to find the rule you want to apply.
3. Configure the rule scope. Specify which resource types the rule applies to and set any configurable parameters (for example, the list of permitted instance types for desired-instance-type).
4. Set the trigger type. Choose whether the rule evaluates resources on configuration changes, on a periodic schedule, or both.
5. Review compliance results. After the initial evaluation runs, the Config console displays each resource’s compliance status. Non-compliant resources are listed with the specific rule they violated.
6. Configure remediation (optional). AWS Config supports automatic remediation actions via AWS Systems Manager Automation documents, allowing you to automatically correct certain violations.

Beyond Managed Rules: Custom Rules and Automation

Managed rules cover a wide range of common compliance requirements, but every organization has unique policies that no predefined rule can anticipate. AWS Config also supports custom rules backed by AWS Lambda functions, giving you full programmatic control over compliance logic. You can also use AWS CloudFormation to deploy Config rules as infrastructure-as-code, ensuring your compliance posture is version-controlled and reproducible across accounts and regions.

Integrating AWS Config with AWS Security Hub, AWS CloudTrail, and Amazon EventBridge further strengthens your compliance posture by correlating configuration compliance data with security findings and enabling event-driven remediation workflows.

Summary

AWS Config managed rules provide a practical, low-friction entry point into continuous compliance on AWS. By replacing manual audits with automated, rules-based evaluation, teams can maintain a verifiable compliance record at the speed and scale the cloud demands. Start by enabling AWS Config in your account, selecting managed rules relevant to your compliance framework, and reviewing the initial compliance report — then expand coverage with custom rules and automated remediation as your program matures.

Original tutorial credit: TheServerSide.com. Screenshots and example project by Cameron McKenzie.

Prerequisites

• SonarQube server installed and running (default: http://localhost:9000)
• Apache Maven installed and available on your system PATH
• A Maven-based Java project with a pom.xml file at its root
• Git installed (if cloning the example project)

The SonarQube Maven Plugin Command

When you first configure SonarQube, the setup wizard asks which build tool you use — Gradle or Maven. If you select Maven, SonarQube provides a ready-made command for triggering analysis during your build. For a default local SonarQube installation, the invocation command is:

mvn sonar:sonar -Dsonar.host.url=http://localhost:9000

This command must be entered as a single line with no line breaks. Run it from the root directory of your Maven project — the directory that contains pom.xml.

Setting Up a Sample Maven Project

If you do not have an existing Maven project to hand, you can clone the following open-source rock-paper-scissors Java project to follow along with this example:

git clone https://github.com/cameronmcnz/rock-paper-scissors.git
cd rock-paper-scissors
dir pom.*

These commands do the following:

1. Clone the remote GitHub repository to your local machine.
2. Change the working directory into the project root.
3. List files matching pom.* to confirm that a pom.xml file exists.

The output of the dir pom.* command should show a single pom.xml file — the Maven project descriptor that the SonarQube plugin requires to run.

Invoking the SonarQube Maven Plugin

From the project root (where pom.xml resides), run the SonarQube Maven Plugin:

mvn sonar:sonar -Dsonar.host.url=http://localhost:9000

Maven will resolve the sonar plugin, compile and analyse the source code, and submit the results to your local SonarQube server. The process typically takes a few minutes depending on project size.

When the scan completes successfully, Maven prints a BUILD SUCCESS message. You can then open the SonarQube dashboard in your browser at http://localhost:9000 to review the results.

Interpreting SonarQube Metrics

After the scan, the SonarQube dashboard displays a quality gate result and a breakdown of issues found. In the rock-paper-scissors example project, SonarQube awarded a passing grade overall, but flagged 14 code smells.

Drilling down into the issues view reveals the severity breakdown of those 14 code smells:

• Blocker: 0
• Critical: 3
• Major: 5
• Minor / Info: remaining issues

SonarQube evaluates code against multiple quality axes — including reliability, security, maintainability, coverage, duplications, and complexity. Each issue is linked to a specific rule so developers can understand what the problem is and how to fix it.

Key Takeaways

• The SonarQube Maven Plugin requires only a single mvn sonar:sonar command to trigger a full code quality scan.
• The command must be run from the directory containing pom.xml.
• Results are immediately available in the SonarQube web dashboard after a successful build.
• Issue severity levels — Blocker, Critical, Major, Minor, Info — help teams prioritise remediation effort.
• Integrating this command into your CI pipeline (Jenkins, GitLab CI, GitHub Actions, etc.) enables automatic quality checks on every commit or pull request.

Next Steps

Once you are comfortable running on-demand scans, consider the following improvements:

1. Add authentication: Secure your SonarQube instance and pass a token using -Dsonar.login=<token>.
2. Configure Quality Gates: Define pass/fail thresholds in the SonarQube UI so that a CI build fails automatically when quality drops below your standards.
3. Embed in CI: Add the mvn sonar:sonar step to your pipeline definition file so every push is analysed without manual intervention.
4. Tune rules: Customise the active Quality Profile in SonarQube to match your team’s coding standards.