SonarQube CE on AWS - Tuned, CloudWatch & SSM Ready

SonarQube is the leading open-source platform for continuous inspection of code quality and security. This AMI delivers a production-shaped SonarQube Community Edition server with system tuning and AWS-native observability already configured - so your server is monitored and manageable from first boot.

With support for over 30 programming languages and more than 6,000 rules including taint analysis for security, SonarQube detects maintainability, reliability, and vulnerability issues across your entire codebase. It integrates with DevOps platforms such as GitHub, Bitbucket, Azure DevOps, and GitLab.

• SonarQube Server (version pinned at build time) installed to /opt/sonarqube, owned by a dedicated no-login sonar user, managed by a systemd unit (sonar.service) and running on Java 21.
• PostgreSQL installed locally with a sonarqube database and sonar role pre-created and granted on the database and public schema; sonar.properties pre-pointed at it.
• Amazon CloudWatch integration: the CloudWatch Agent ships SonarQube logs (sonar.log, web.log, ce.log, es.log, access.log), PostgreSQL server log, and system/authentication logs to CloudWatch Logs (log groups /solvedevops/sonarqube/*, 30-day retention). CPU, memory, disk, TCP connection, and process metrics are published under the SolveDevOps/SonarQube namespace.
• AWS Systems Manager integration: SSM Agent is installed and enabled for Session Manager shell access, Run Command, Patch Manager, and Inventory.
• Security hardening: key-only SSH, no root login, no SSH keys or AWS credentials baked into the image, all passwords generated per instance.

After deploying this AMI, development teams commonly integrate SonarQube into their CI/CD pipeline. When a developer opens a pull request in GitHub or GitLab, the pipeline triggers a SonarQube analysis. SonarQube scans the code for bugs, security vulnerabilities, code smells, and coding standards violations, then reports results back to the pull request. Teams configure quality gates - threshold rules for metrics like code coverage, duplicated lines, and critical issues - so that merges are automatically blocked when code does not meet the defined quality standard. This workflow helps organizations catch and fix issues before code reaches production.

Step 1: On AWS Marketplace, click Subscribe to get started.

Step 2: Launch an Amazon EC2 instance using this AMI. Recommended minimum specifications:

• Instance type: t3.medium or equivalent
• 2 vCPUs
• 4 GB RAM

Attach an IAM instance profile with the CloudWatchAgentServerPolicy and AmazonSSMManagedInstanceCore managed policies to activate log/metric shipping and Session Manager access. No AWS credentials are stored on the image - the Region is detected at boot.

Step 3: Allow a few minutes after first boot for SonarQube to start and the password reset to complete. Then browse to http://:9000 and log in:

Configuration is in /opt/sonarqube/conf/sonar.properties, logs in /opt/sonarqube/logs, the service unit in /etc/systemd/system/sonar.service, and the CloudWatch configuration in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/sonarqube.json. Full root access is provided.

For production use, we recommend the following steps to harden your deployment:

• Place the instance in a private subnet behind a reverse proxy or Application Load Balancer configured with TLS/HTTPS to encrypt traffic in transit.
• Restrict security group inbound rules to allow port 9000 only from your reverse proxy or internal network - do not expose port 9000 to the public internet.
• Change the admin password immediately after first login and enforce strong password policies.
• Use AWS Systems Manager Session Manager instead of SSH for shell access to reduce your network attack surface.

All product and company names are trademarks or registered trademarks of their respective holders.