AWS Compliance Controls

296 controls across AWS services, each with Terraform implementation examples, framework mappings, and audit guidance.

Amazon API Gateway

API Gateway methods should require an authorizer Checks that every API Gateway REST API method has an authorization type other than NONE. Methods without an authorizer accept requests from any internet caller, bypassing identity checks and exposing backend integrations to unauthorized invocation. high effort API Gateway methods should validate request parameters Checks that API Gateway REST API methods have request parameter validation active via a configured request validator. Any method without a validator, or with one that has validate_request_parameters set to false, is flagged as non-compliant. medium effort API Gateway REST API stages should have AWS X-Ray tracing enabled Checks whether AWS X-Ray active tracing is enabled on each API Gateway REST API stage. X-Ray tracing must be explicitly turned on per stage to collect request-level trace data for latency analysis and dependency mapping. ◆◆ 4 frameworks low effort API Gateway routes should require an authorization type Checks that every AWS API Gateway V2 HTTP API route has an explicit authorization type set to a non-NONE value. Acceptable values are AWS_IAM, CUSTOM, and JWT. Routes that omit this setting default to NONE, leaving the backend open to any caller without credentials. ◆ 1 framework medium effort API Gateway stages should have cache encryption at rest enabled Checks that API Gateway REST API stages with caching enabled have encryption at rest turned on for the cache. The control fails if a stage's method settings do not set cache_data_encrypted to true, leaving cached API responses stored unencrypted. ◆◆◆ 16 frameworks low effort API Gateway stages should have logging enabled Checks that Amazon API Gateway REST API stages have logging enabled. The control validates that execution logging is configured at the stage level with a logging level other than OFF, and optionally that access logging is directed to a destination ARN. ◆◆◆ 20 frameworks low effort API Gateway stages should not use client SSL certificates Checks that Amazon API Gateway REST API stages do not have a client SSL certificate configured. API Gateway client certificates authenticate the gateway to a backend endpoint, not the caller to the API. A stage passes when client_certificate_id is not set. ◆◆◆ 12 frameworks medium effort API Gateway V2 routes should require an authorizer Checks that every API Gateway V2 route has authorization_type set to JWT, AWS_IAM, or CUSTOM. Routes with authorization_type set to NONE or omitted entirely fail the control, leaving backend integrations open to unauthenticated callers. medium effort API Gateway V2 stages should have access logging configured Checks whether AWS API Gateway V2 stages have access logging configured. Applies to both HTTP and WebSocket API stage types. Fails when the stage has no access_log_settings block, or when destination_arn is empty or null, leaving request-level logging disabled. ◆ 2 frameworks low effort compliance.tf module

Amazon CloudFront

CloudFront distributions access logs should be enabled Checks whether each CloudFront distribution has access logging enabled. The check looks for a logging_config block with a non-empty bucket value pointing to an S3 destination. Distributions that omit this block or leave bucket empty fail. ◆◆◆ 7 frameworks low effort compliance.tf module CloudFront distributions should have a default root object configured Validates that each AWS CloudFront distribution has a default root object configured, ensuring requests to the distribution root URL return a specific object rather than exposing the contents of the origin or returning an error. ◆ 1 framework low effort compliance.tf module CloudFront distributions should have AWS WAF enabled Checks that every Amazon CloudFront distribution has an associated AWS WAF or AWS WAFv2 web ACL. The control fails when the distribution's web ACL association is empty, leaving edge traffic unfiltered by any WAF rule set. ◆ 2 frameworks medium effort compliance.tf module CloudFront distributions should have field level encryption enabled Checks whether AWS CloudFront distributions have field-level encryption enabled. The control fails if no field-level encryption configuration ID is associated with the distribution's default cache behavior or ordered cache behaviors. high effort compliance.tf module CloudFront distributions should have geo restriction enabled Checks that each Amazon CloudFront distribution has geographic restriction configured with a whitelist or blacklist rather than set to none. Geo restriction controls which countries can access content served through the distribution. low effort compliance.tf module CloudFront distributions should have latest TLS version Checks that CloudFront distributions set minimum_protocol_version to TLSv1.2_2021 in the viewer certificate block. Older values like TLSv1.1_2016 or TLSv1.2_2019 expose client connections to deprecated cipher suites and leave the door open for downgrade attacks. low effort compliance.tf module CloudFront distributions should require encryption in transit Validates that every AWS CloudFront distribution's default and ordered cache behaviors set ViewerProtocolPolicy to https-only or redirect-to-https, preventing any viewer from connecting to the distribution over unencrypted HTTP. ◆◆◆ 7 frameworks low effort compliance.tf module CloudFront distributions should use custom SSL/TLS certificates Checks whether Amazon CloudFront distributions use a custom SSL/TLS certificate (from ACM or IAM) instead of the default CloudFront certificate. Distributions relying on the default *.cloudfront.net certificate fail this control. ◆◆ 3 frameworks low effort compliance.tf module CloudFront distributions should use SNI to serve HTTPS requests Validates that CloudFront distributions using a custom SSL/TLS certificate are configured with SNI (Server Name Indication) as the SSL support method, not dedicated IP, ensuring HTTPS is served without unnecessary cost or legacy IP allocation overhead. ◆ 2 frameworks low effort compliance.tf module CloudFront distributions should use the recommended TLS security policy Checks each CloudFront distribution's viewer certificate block for a minimum TLS security policy of TLSv1.2_2021 or higher, rejecting configurations that allow older protocol versions or weak cipher suites to be negotiated with connecting clients. low effort compliance.tf module

Amazon CloudWatch

CloudWatch alarms should have action enabled Verifies that AWS CloudWatch metric alarms have their actions enabled so that configured notifications, Auto Scaling policies, or EC2 actions actually fire when alarm state transitions occur. Alarms with disabled actions silently swallow threshold breaches. ◆◆◆ 5 frameworks low effort compliance.tf module CloudWatch alarms should have an action configured Validates that each CloudWatch alarm has at least one action configured for the ALARM, INSUFFICIENT_DATA, or OK state, and that the actions_enabled flag is set to true. Alarms without actions generate no notifications and cannot trigger automated responses. ◆◆◆ 19 frameworks medium effort compliance.tf module

Amazon CloudWatch Logs

CloudWatch log groups should have retention period of at least 365 days Checks that every CloudWatch Logs log group has an explicit retention policy set to at least 365 days. Log groups with no retention setting, which defaults to indefinite, or any period shorter than 365 days fail this control. ◆◆◆ 18 frameworks medium effort compliance.tf module Log groups should have encryption at rest enabled Checks that each AWS CloudWatch Log Group has a KMS customer-managed key (CMK) associated for encryption at rest. CloudWatch Logs encrypts data with service-managed keys by default, but this control requires an explicit kms_key_id on the log group. ◆◆◆ 19 frameworks medium effort compliance.tf module

Amazon DynamoDB

DynamoDB tables should have AWS KMS encryption enabled Checks that each AWS DynamoDB table uses a customer-visible AWS KMS key (AWS-managed aws/dynamodb or a customer-managed key) rather than relying on AWS-owned key encryption. Tables using only AWS-owned key encryption fail this control. ◆◆◆ 14 frameworks medium effort compliance.tf module DynamoDB tables should have deletion protection enabled Checks that every DynamoDB table has deletion_protection_enabled set to true, blocking table deletion via the Console, CLI, or API until protection is explicitly disabled. Any DeleteTable call is rejected until that precondition is met. low effort compliance.tf module DynamoDB tables should have encryption enabled Validates that each AWS DynamoDB table has server-side encryption at rest enabled. DynamoDB supports AWS-owned keys (default since 2018), AWS managed KMS keys, or customer managed KMS keys. This control checks that an explicit encryption configuration is present. ◆◆◆ 7 frameworks low effort compliance.tf module DynamoDB tables should have point-in-time recovery enabled Validates that all AWS DynamoDB tables have point-in-time recovery (PITR) enabled, providing continuous backups with a 35-day rolling window. PITR allows restoration of table data to any second within that window, protecting against accidental writes or deletes. ◆◆◆ 21 frameworks low effort compliance.tf module

Amazon EBS

Attached EBS volumes should have encryption enabled Checks that all EBS volumes currently attached to EC2 instances have encryption enabled. Unattached volumes are out of scope. The control evaluates the encrypted attribute on each aws_ebs_volume resource and fails any attached volume where encryption is not active. ◆◆◆ 22 frameworks high effort compliance.tf module EBS snapshots should be encrypted Checks that every EBS snapshot has encryption enabled. Snapshots inherit encryption from the source EBS volume, so unencrypted volumes produce unencrypted snapshots. The control flags any snapshot where the encrypted attribute is false. ◆ 1 framework high effort EBS volumes should have encryption at rest enabled Checks that every AWS EBS volume has encryption at rest enabled. Volumes may be encrypted using AWS-managed keys or customer-managed KMS keys. Unencrypted volumes fail this control regardless of the data they contain or their attachment state. ◆◆◆ 5 frameworks medium effort compliance.tf module

Amazon EC2

EC2 instances should be in a VPC Validates that every EC2 instance runs inside a VPC by checking for a non-empty vpc_id attribute. EC2-Classic, retired by AWS in August 2022, lacked subnet isolation, private IP address space, and network ACLs, making it unsuitable for any regulated workload. ◆◆◆ 18 frameworks low effort compliance.tf module EC2 instances should have attached EBS volumes marked for deletion on termination Checks that every EBS volume attached to an EC2 instance has DeleteOnTermination set to true in the block device mapping. Volumes missing this flag persist after instance termination, accruing storage charges and retaining data without the original access controls. medium effort compliance.tf module EC2 instances should have detailed monitoring enabled Checks that each EC2 instance has detailed monitoring enabled via monitoring = true on aws_instance, or monitoring { enabled = true } inside aws_launch_template. Without it, instances report CloudWatch metrics at 5-minute intervals instead of 1-minute. ◆◆◆ 12 frameworks low effort compliance.tf module EC2 instances should have EBS optimization enabled Checks that EC2 instances have EBS optimization enabled, providing dedicated throughput between the instance and its EBS volumes. Without it, EBS I/O and general network traffic compete for the same bandwidth, causing unpredictable latency under load. ◆◆◆ 16 frameworks low effort compliance.tf module EC2 instances should have IAM profile attached Checks that every running AWS EC2 instance has an IAM instance profile attached. Instances without a profile cannot assume an IAM role, leaving developers to choose between hardcoded access keys or no AWS API access at all. ◆◆◆ 10 frameworks medium effort compliance.tf module EC2 instances should have termination protection enabled Checks that each EC2 instance has API termination protection enabled via the DisableApiTermination attribute. The control fails when an instance can be terminated directly via the API or Console without needing to disable a protection gate first. low effort compliance.tf module EC2 instances should not have a public IP address Checks that EC2 instances do not have a public IP address assigned, whether through direct association at launch, subnet default settings, or Elastic IP attachment. Instances should remain in private subnets behind load balancers or NAT gateways. ◆◆◆ 18 frameworks high effort compliance.tf module EC2 instances should not use key pairs in running state Checks that running EC2 instances do not have an associated key pair. Instances with a key pair configured expose an SSH-based access path that may bypass centralized access controls. The control fails if a running instance has a non-null key pair name. ◆ 2 frameworks high effort compliance.tf module EC2 instances should not use multiple ENIs Checks that each EC2 instance has exactly one Elastic Network Interface (ENI) or Elastic Fabric Adapter (EFA) attached. The control passes when a single network interface is present and fails when two or more are detected. ◆ 1 framework medium effort compliance.tf module EC2 instances should not use paravirtual instance types Checks that EC2 instances use HVM virtualization rather than paravirtual. The control fails when an instance's virtualizationType attribute is set to paravirtual, indicating use of a legacy virtualization method that lacks modern security and performance features. ◆ 1 framework medium effort compliance.tf module EC2 instances should use IAM instance roles for AWS resource access Checks that every EC2 instance has an IAM instance profile attached, ensuring AWS API access from instances uses temporary role credentials rather than long-lived access keys embedded in application code or configuration files. ◆ 2 frameworks medium effort compliance.tf module EC2 instances should use IMDSv2 Validates that EC2 instances enforce IMDSv2 by requiring session-based token authentication for all instance metadata requests, blocking unauthenticated IMDSv1 HTTP GET calls that expose IAM role credentials to SSRF-based theft. ◆◆◆ 12 frameworks medium effort compliance.tf module EC2 launch templates should not assign public IPs to network interfaces Checks that EC2 launch templates do not enable public IP assignment on any network interface. Fails when associate_public_ip_address is set to true in any network_interfaces block within an aws_launch_template resource. ◆ 1 framework medium effort compliance.tf module EC2 launch templates should use Instance Metadata Service Version 2 (IMDSv2) Checks that EC2 launch templates set HttpTokens to required in the metadata_options block, enforcing IMDSv2 session-token authentication for all metadata requests. Without it, instances accept unauthenticated IMDSv1 GET requests to 169.254.169.254. medium effort compliance.tf module EC2 network interfaces should have source/destination checking enabled Verifies that source/destination checking remains enabled on user-managed EC2 elastic network interfaces (ENIs). The control fails when source_dest_check is disabled on ENIs of types: interface, efa, lambda, quicksight, branch, and aws_codestar_connections_managed. low effort

Amazon ECR

ECR private repositories should have tag immutability configured Checks that private ECR repositories have tag immutability enabled. The policy confirms image_tag_mutability is set to "IMMUTABLE" on every aws_ecr_repository resource. Repositories with the default "MUTABLE" setting or no explicit argument fail. ◆◆ 3 frameworks low effort compliance.tf module ECR repositories should have image scan on push enabled Checks that each AWS ECR repository has scan_on_push enabled in its image_scanning_configuration block. Repositories that omit the block or explicitly set the flag to false default to no automatic scanning and are flagged non-compliant. ◆◆ 4 frameworks low effort compliance.tf module

Amazon ECS

ECS clusters should have container insights enabled Validates that Amazon ECS clusters have Container Insights enabled. Container Insights collects cluster-level and service-level metrics and logs into CloudWatch. The control fails if the containerInsights setting is absent or not explicitly set to enabled. ◆ 2 frameworks low effort compliance.tf module ECS fargate services should run on the latest fargate platform version Checks that ECS Fargate services have platform_version set to the latest Fargate platform version. Services that specify an older explicit version string fail this control. Applies to both Linux and Windows Fargate platform version tracks. ◆◆ 3 frameworks low effort compliance.tf module ECS services should not have public IP addresses assigned automatically Validates that AWS ECS services using awsvpc network mode do not have automatic public IP assignment enabled. The control fails when AssignPublicIp is set to ENABLED, which exposes container tasks directly to the internet. medium effort compliance.tf module ECS task definitions should not share the host's process namespace Validates that AWS ECS task definitions do not set pid_mode to host, which gives containers full visibility into every process running on the underlying EC2 host, including other tasks and the ECS agent itself, collapsing the task-level process isolation boundary. ◆◆ 3 frameworks low effort compliance.tf module

Amazon EFS

EFS access points should enforce a root directory Validates that AWS EFS access points specify a root_directory path other than /. When Path is /, the access point grants access to the entire file system instead of scoping users to a specific subdirectory, defeating the purpose of access point isolation. ◆◆ 4 frameworks medium effort EFS access points should enforce a user identity Validates that every AWS EFS access point defines a POSIX user identity (uid and gid), forcing all NFS connections through that access point to run as the specified OS user and preventing clients from overriding file ownership or assuming root. ◆◆◆ 6 frameworks low effort EFS file systems should be encrypted with CMK Validates that every AWS Elastic File System (EFS) file system encrypts data at rest with a customer-managed KMS key (CMK). The AWS-managed aws/elasticfilesystem default key and unencrypted file systems both fail this control. ◆ 2 frameworks high effort compliance.tf module EFS file systems should have encryption at rest enabled Checks that each AWS Elastic File System (EFS) file system has encryption at rest enabled. EFS encryption uses AWS KMS to encrypt data written to the file system, and the setting must be configured at creation time and cannot be changed afterward. ◆◆◆ 19 frameworks high effort compliance.tf module

Amazon EKS

EKS clusters endpoint public access should be restricted Checks that Amazon EKS cluster API server endpoints do not have public access enabled. The control fails when endpoint_public_access is true, meaning the Kubernetes API server is reachable from the internet rather than restricted to VPC-internal traffic only. medium effort compliance.tf module EKS clusters endpoint should restrict public access Validates that AWS EKS cluster API server endpoints do not allow unrestricted public access. Checks the cluster's vpc_config to confirm endpoint_public_access is disabled or that public_access_cidrs is scoped to specific IP ranges rather than 0.0.0.0/0. ◆◆◆ 5 frameworks medium effort compliance.tf module EKS clusters should be configured to have kubernetes secrets encrypted using KMS Validates that Amazon EKS clusters have an encryption configuration that uses an AWS KMS key to encrypt Kubernetes secrets. Without this, secrets stored in etcd (such as service account tokens and passwords) remain base64-encoded but not envelope-encrypted at rest. ◆◆◆ 7 frameworks high effort compliance.tf module EKS clusters should have control plane audit logging enabled Validates that Amazon EKS clusters have control plane audit logging enabled by checking that the cluster's logging configuration includes the "audit" log type, ensuring Kubernetes API server audit events are sent to CloudWatch Logs for inspection and retention. ◆ 2 frameworks low effort compliance.tf module

Amazon ElastiCache

ElastiCache clusters should not use the default subnet group Validates that ElastiCache clusters do not use the default subnet group. The control fails when the CacheSubnetGroupName attribute equals "default", indicating the cluster was launched without an explicit subnet group assignment. ◆ 1 framework medium effort ElastiCache for Redis replication groups before version 6.0 should use Redis Auth Validates that ElastiCache for Redis replication groups running engine versions before 6.0 have Redis AUTH enabled by setting an authentication token. Groups without AUTH allow unauthenticated access to cached data over the network. medium effort compliance.tf module ElastiCache for Redis replication groups should be encrypted at rest Checks that every ElastiCache for Redis replication group has encryption at rest enabled. The control fails when at_rest_encryption_enabled is false or absent, meaning cached data written to disk, including snapshots and AOF persistence files, is stored in plaintext. ◆ 1 framework high effort compliance.tf module ElastiCache for Redis replication groups should be encrypted in transit Checks that each ElastiCache for Redis replication group has transit encryption enabled, ensuring data moving between nodes and between clients and the cluster is protected by TLS. Fails when transit_encryption_enabled is false or unset. ◆ 1 framework high effort compliance.tf module ElastiCache for Redis replication groups should be encrypted with CMK Validates that each ElastiCache for Redis replication group has encryption at rest enabled via a customer-managed KMS key (CMK). Both at_rest_encryption_enabled and kms_key_id must be set; using the AWS-managed aws/elasticache key fails the control. high effort compliance.tf module ElastiCache for Redis replication groups should have automatic failover enabled Checks that every ElastiCache for Redis replication group has automatic_failover_enabled set to true, so ElastiCache can automatically promote a healthy replica to primary when the current primary node fails or becomes unreachable. low effort compliance.tf module ElastiCache Redis clusters should have automatic backups enabled with a retention period of 15 days or greater Validates that each ElastiCache Redis replication group or cluster has automatic daily backups enabled with a snapshot retention period of at least 15 days, giving operations teams a recovery window wide enough to catch delayed failures or silent data corruption. ◆◆◆ 21 frameworks low effort compliance.tf module

Amazon EMR

EMR cluster Kerberos should be enabled Checks that AWS EMR clusters have Kerberos authentication enabled by verifying a Kerberos configuration is present. Kerberos provides ticket-based mutual authentication for cluster services and users, underpinning identity-based access control across Hadoop workloads. ◆◆◆ 12 frameworks high effort compliance.tf module EMR clusters should have security configuration enabled Checks that each Amazon EMR cluster has a security configuration attached. A security configuration defines encryption at rest, encryption in transit, and authentication settings. The control fails if the EMR cluster's security_configuration attribute is empty or unset. high effort compliance.tf module

Amazon FSx

FSx for Lustre file systems should be configured to copy tags to backups Checks that Amazon FSx for Lustre file systems have copy_tags_to_backups set to true, ensuring that resource tags (cost allocation, ownership, data classification) automatically propagate to any backups created from the file system. high effort compliance.tf module FSx for NetApp ONTAP file systems should be configured for Multi-AZ deployment Checks that Amazon FSx for NetApp ONTAP file systems use a Multi-AZ deployment type. The control fails when a file system uses a Single-AZ deployment type such as SINGLE_AZ_1 or SINGLE_AZ_2 instead of MULTI_AZ_1 or MULTI_AZ_2. high effort compliance.tf module FSx for OpenZFS file systems should be configured for Multi-AZ deployment Checks that Amazon FSx for OpenZFS file systems are deployed in a Multi-AZ configuration. The control fails if deployment_type is SINGLE_AZ_1 or SINGLE_AZ_2. Both MULTI_AZ_1 and MULTI_AZ_2 satisfy the control; single-AZ variants do not. high effort compliance.tf module FSx for OpenZFS file systems should be configured to copy tags to backups and volumes Checks that Amazon FSx for OpenZFS file systems have copy_tags_to_backups and copy_tags_to_volumes enabled, ensuring that resource tags propagate automatically to all backups and child volumes created from the file system. low effort compliance.tf module FSx for Windows File Server file systems should be configured for Multi-AZ deployment Checks that Amazon FSx for Windows File Server file systems use a Multi-AZ deployment type (MULTI_AZ_1 or MULTI_AZ_2) instead of a single Availability Zone configuration, ensuring automatic failover capability across zones. high effort compliance.tf module

Amazon MSK

MSK clusters should be encrypted in transit among broker nodes Validates that Amazon MSK clusters encrypt inter-broker communication using TLS. The control fails when plaintext communication is permitted between broker nodes within the cluster, leaving Kafka replication traffic unencrypted on the wire. ◆ 1 framework high effort compliance.tf module MSK clusters should disable unauthenticated access Validates that Amazon MSK clusters do not permit unauthenticated client connections. The control fails when the unauthenticated flag within the cluster's client authentication configuration is set to true, allowing clients to connect without any identity verification. medium effort compliance.tf module MSK clusters should have public access disabled Validates that Amazon MSK clusters do not have public access enabled on their broker nodes. The control fails when the cluster's broker connectivity is configured to provide public endpoints via Elastic IP addresses, exposing Apache Kafka brokers to the internet. medium effort compliance.tf module

Amazon OpenSearch Service

Elasticsearch domain error logging to CloudWatch Logs should be enabled Checks that Amazon Elasticsearch (OpenSearch) domains publish ES_APPLICATION_LOGS to a CloudWatch Logs log group. Without this, application-level errors, index mapping conflicts, and JVM issues have no durable log destination outside the cluster. ◆ 1 framework low effort compliance.tf module Elasticsearch domain node-to-node encryption should be enabled Checks that AWS Elasticsearch Service domains have node-to-node encryption enabled. This setting enforces TLS 1.2 for all intra-cluster traffic between data nodes within the VPC, protecting index data, search queries, and cluster state from plaintext interception. ◆◆◆ 17 frameworks high effort Elasticsearch domain should send logs to CloudWatch Validates that AWS OpenSearch Service domains have at least one log publishing option enabled, sending index slow logs, search slow logs, application logs, or audit logs to CloudWatch Logs for centralized monitoring and analysis. ◆◆◆ 18 frameworks low effort Elasticsearch domains should be configured with at least three dedicated master nodes Checks that Amazon Elasticsearch (OpenSearch) domains have dedicated master nodes enabled with a count of three or more. Dedicated masters handle cluster state management independently of data nodes, maintaining quorum through a single master failure. medium effort Elasticsearch domains should have at least three data nodes Validates that Elasticsearch/OpenSearch domains have at least three data nodes and zone awareness enabled. Without both, the cluster cannot survive an Availability Zone failure without risking unassigned shards, split-brain, or complete unavailability. medium effort Elasticsearch domains should have audit logging enabled Verifies that Elasticsearch (OpenSearch) domains have audit logging enabled via the AUDIT_LOGS log publishing option, publishing to a CloudWatch Logs group. Fine-grained access control must also be active; domains missing either configuration fail this control. ◆ 2 frameworks medium effort Elasticsearch domains should have cognito authentication enabled Checks that each AWS Elasticsearch (OpenSearch) domain has Amazon Cognito authentication enabled for Kibana or OpenSearch Dashboards. The control fails when the cognito_options block is absent or has enabled set to false. high effort Elasticsearch domains should have internal user database enabled Checks that Amazon OpenSearch (Elasticsearch) domains have the internal user database enabled within fine-grained access control. Domains that rely solely on IAM or SAML without the internal user database are flagged as non-compliant. medium effort Elasticsearch domains should require TLS 1.2 for connections Validates that Amazon Elasticsearch (OpenSearch) domains enforce a minimum TLS security policy of Policy-Min-TLS-1-2-2019-07, ensuring all client connections negotiate TLS 1.2 or higher and reject older protocol versions. ◆ 1 framework low effort ES domain encryption at rest should be enabled Validates that Elasticsearch/OpenSearch domains have encryption at rest enabled. Domain indices, automated snapshots, logs, and swap files must be KMS-encrypted rather than stored in plaintext on the underlying EBS volumes and instance storage. ◆◆◆ 17 frameworks medium effort ES domains should be in a VPC Checks whether AWS Elasticsearch Service domains are deployed inside a VPC by verifying that the vpc_options block is present and includes at least one subnet ID, rather than relying on a public endpoint exposed over the internet. ◆◆◆ 18 frameworks high effort OpenSearch domains internal user database should be disabled Validates that AWS OpenSearch domains have the internal user database disabled within advanced security options, requiring authentication through external identity providers such as IAM or SAML rather than locally stored usernames and passwords. high effort compliance.tf module OpenSearch domains node-to-node encryption should be enabled Checks that AWS OpenSearch Service domains have node-to-node encryption enabled, ensuring all inter-node traffic within the cluster is encrypted using TLS. Domains without this setting transmit data between nodes in plaintext over the internal network. ◆◆◆ 9 frameworks high effort compliance.tf module OpenSearch domains should be in a VPC Validates that AWS OpenSearch domains are deployed inside a VPC by verifying VPC endpoint configuration is present. Domains without VPC placement expose public endpoints that are internet-reachable, constrained only by the domain's access policies. ◆◆◆ 7 frameworks high effort compliance.tf module OpenSearch domains should have at least three data nodes Validates that Amazon OpenSearch Service domains have at least three data nodes with zone awareness enabled. This configuration lets the cluster survive an Availability Zone outage by redistributing shards across the remaining nodes automatically. medium effort compliance.tf module OpenSearch domains should have audit logging enabled Checks that Amazon OpenSearch Service domains have audit logging enabled via log publishing options. Domains must publish audit logs (log_type AUDIT_LOGS) to a CloudWatch log group, which requires fine-grained access control to be active on the domain. ◆◆◆ 8 frameworks medium effort compliance.tf module OpenSearch domains should have Cognito authentication enabled for Kibana Checks that AWS OpenSearch domains have Amazon Cognito authentication enabled for Kibana (OpenSearch Dashboards). When enabled, Cognito handles user sign-up, sign-in, and access control rather than relying on open endpoints or IP-based access restrictions. medium effort compliance.tf module OpenSearch domains should have encryption at rest enabled Checks whether AWS OpenSearch Service domains have encryption at rest enabled via the EncryptionAtRestOptions configuration. Passes when the Enabled flag is true, confirming that data in domain indices and automated snapshots is encrypted with AWS KMS keys. ◆◆◆ 9 frameworks high effort compliance.tf module OpenSearch domains should have fine-grained access control enabled Checks that Amazon OpenSearch Service domains have fine-grained access control enabled via the advanced_security_options configuration. The control fails when advanced_security_options is absent or its enabled flag is false. ◆◆ 4 frameworks high effort compliance.tf module OpenSearch domains should have logging to CloudWatch Logs enabled Checks that AWS OpenSearch Service domains have log publishing configured for at least one log type (index slow logs, search slow logs, ES application logs, or audit logs) to a CloudWatch Logs log group, with at least one publishing option actively enabled. ◆◆◆ 8 frameworks medium effort compliance.tf module OpenSearch domains should use HTTPS Validates that AWS OpenSearch domains enforce HTTPS for all connections and that the TLS security policy meets a minimum version of TLS 1.2. Domains permitting plaintext HTTP connections or configured with a policy that allows TLS 1.0 or 1.1 fail this control. ◆◆◆ 8 frameworks low effort compliance.tf module

Amazon RDS

Aurora MySQL DB clusters should have audit logging enabled Checks whether Amazon Aurora MySQL DB clusters have audit logging enabled via the Advanced Auditing feature. The control fails if the cluster's parameter group does not have server_audit_logging set to 1 with audit events configured. ◆ 2 frameworks medium effort compliance.tf module Aurora PostgreSQL DB clusters should publish logs to CloudWatch Logs Checks that Aurora PostgreSQL DB clusters export postgresql logs to CloudWatch Logs by validating that enabled_cloudwatch_logs_exports includes the postgresql log type. Clusters with the parameter omitted, empty, or missing this log type fail. low effort compliance.tf module RDS Aurora clusters should have backtracking enabled Checks that Amazon Aurora DB clusters have backtracking enabled by verifying a non-zero backtrack_window is configured. Backtracking lets you rewind a cluster to a specific point in time without restoring from a snapshot, reducing recovery time. ◆ 2 frameworks medium effort compliance.tf module RDS clusters should have deletion protection enabled Checks that Amazon RDS DB clusters (including Aurora, Neptune, and DocumentDB) have deletion protection enabled. When deletion_protection is true, the cluster cannot be deleted through the API or console without first disabling the setting. ◆ 2 frameworks low effort compliance.tf module RDS database clusters should use a custom administrator username Validates that AWS RDS database clusters do not use default administrator usernames such as "admin" or "postgres". The control fails when master_username matches a known engine default, meaning credentials were not customized at provisioning time. ◆ 2 frameworks high effort compliance.tf module RDS database instances should use a custom administrator username Checks that AWS RDS database instances do not use default administrator usernames such as "admin", "postgres", or engine-specific defaults. Fails when the master username matches a known default value, indicating credentials were not customized at provisioning. ◆ 2 frameworks medium effort compliance.tf module RDS databases and clusters should not use a database engine default port Validates that Amazon RDS database instances and Aurora clusters are configured with a non-default port. Engine defaults targeted by automated scanners include 3306 for MySQL/MariaDB, 5432 for PostgreSQL, 1433 for SQL Server, and 1521 for Oracle. high effort compliance.tf module RDS DB clusters should be configured for multiple Availability Zones Checks whether RDS DB clusters are configured for high availability across multiple Availability Zones. Uses engine-appropriate signals: instance placement across AZs for Aurora clusters, and the MultiAZ flag for non-Aurora MySQL and PostgreSQL DB clusters. ◆ 2 frameworks medium effort compliance.tf module RDS DB clusters should be configured to copy tags to snapshots Checks that RDS DB clusters have copy_tags_to_snapshot enabled, ensuring resource tags propagate automatically to any snapshots the cluster creates. Snapshots inherit cost allocation, ownership, and compliance metadata without manual tagging. low effort compliance.tf module RDS DB clusters should be encrypted at rest Checks that each RDS DB cluster (Aurora) has encryption at rest enabled via the StorageEncrypted attribute. The control fails when an RDS DB cluster stores data without server-side encryption, leaving database contents readable on the underlying storage media. ◆ 1 framework high effort compliance.tf module RDS DB clusters should be encrypted with CMK Validates that each RDS DB cluster has storage encryption enabled and uses a customer-managed KMS key (CMK) rather than the default AWS-managed RDS key. The control fails if storage_encrypted is false or if kms_key_id is absent or points to an AWS-managed key. high effort compliance.tf module RDS DB clusters should have automatic minor version upgrade enabled Validates that RDS database clusters have automatic minor version upgrade enabled. Fails when auto_minor_version_upgrade is set to false, leaving the cluster on a stale engine version that may carry known vulnerabilities or unpatched bugs. ◆◆ 3 frameworks low effort RDS DB clusters should have IAM authentication configured Validates that iam_database_authentication_enabled is set to true on aws_rds_cluster resources. Without this setting, clusters rely on native database passwords: static secrets with no automatic rotation and no integration with IAM access control. ◆◆ 4 frameworks medium effort compliance.tf module RDS DB instance automatic minor version upgrade should be enabled Checks that each RDS DB instance has auto_minor_version_upgrade set to true, ensuring the engine receives automatic minor version patches during the maintenance window. Instances with this flag disabled are non-compliant. ◆◆◆ 10 frameworks low effort compliance.tf module RDS DB instance backup should be enabled Validates that each Amazon RDS DB instance has automated backups enabled by confirming the backup retention period is set to at least 1 day. Automated backups capture daily snapshots and retain transaction logs, enabling point-in-time recovery. ◆◆◆ 21 frameworks low effort compliance.tf module RDS DB instance encryption at rest should be enabled Checks that each Amazon RDS DB instance has encryption at rest enabled. The control evaluates whether the storage_encrypted attribute is set to true, confirming that data written to the underlying EBS volumes is encrypted using AES-256. ◆◆◆ 22 frameworks high effort compliance.tf module RDS DB instances and clusters should have enhanced monitoring enabled Checks that RDS DB instances and Aurora cluster instances have enhanced monitoring enabled with a non-zero monitoring interval. Enhanced monitoring collects OS-level metrics (CPU, memory, file system, disk I/O) via an agent running on the instance. ◆◆◆ 12 frameworks low effort compliance.tf module RDS DB instances backup retention period should be greater than or equal to 7 Checks that every RDS DB instance has backup_retention_period set to 7 or more days. Instances with automated backups disabled (retention of 0) or any value from 1 to 6 days fail. Valid passing values range from 7 to 35 days. low effort compliance.tf module RDS DB instances should be configured to copy tags to snapshots Checks that each RDS DB instance has copy_tags_to_snapshot enabled so that every automated or manual snapshot inherits the instance's tags. This preserves cost allocation, ownership, and classification metadata on backup artifacts. low effort compliance.tf module RDS DB instances should be integrated with CloudWatch logs Checks that each RDS DB instance has at least one log type exported to CloudWatch Logs via the enabled_cloudwatch_logs_exports argument. Valid types vary by engine: MySQL and MariaDB support audit, error, general, and slowquery; PostgreSQL uses postgresql and upgrade. medium effort compliance.tf module RDS DB instances should have deletion protection enabled Validates that each AWS RDS DB instance has the deletion_protection attribute set to true, preventing accidental or unauthorized deletion through the AWS Management Console, CLI, or API without first disabling the protection flag. ◆◆◆ 14 frameworks low effort compliance.tf module RDS DB instances should have iam authentication enabled Validates that each AWS RDS DB instance has IAM database authentication enabled. When enabled, connections authenticate via short-lived IAM tokens generated with the rds-db:connect action rather than static passwords stored in application config. ◆◆◆ 9 frameworks medium effort compliance.tf module RDS DB instances should have logging enabled Checks that each Amazon RDS DB instance has at least one log type enabled for export to CloudWatch Logs. The specific log types vary by engine (e.g., audit, error, slowquery for MySQL; postgresql and upgrade for PostgreSQL). ◆◆◆ 20 frameworks low effort compliance.tf module RDS DB instances should have multiple AZ enabled Checks that each Amazon RDS DB instance has Multi-AZ deployment enabled (multi_az = true). Multi-AZ provisions a synchronous standby replica in a separate Availability Zone and fails over automatically during planned maintenance, instance failure, or AZ disruption. ◆◆◆ 18 frameworks medium effort compliance.tf module RDS DB instances should not use public subnet Validates that RDS DB instances are not deployed into public subnets. A public subnet is defined by a route table entry pointing to an internet gateway. Placing a database in such a subnet weakens network segmentation and raises direct internet exposure risk. high effort compliance.tf module RDS DB instances should prohibit public access Checks that every aws_db_instance and aws_rds_cluster_instance has publicly_accessible set to false. When true, AWS assigns a public IP address and a DNS hostname resolving outside the VPC, exposing the database endpoint to the public internet. ◆◆◆ 22 frameworks medium effort compliance.tf module RDS for MariaDB DB instances should publish logs to CloudWatch Logs Checks whether RDS MariaDB instances are configured to publish logs to CloudWatch Logs. Supported log types are audit, error, general, and slowquery. Fails if enabled_cloudwatch_logs_exports is empty or absent on the aws_db_instance resource. low effort compliance.tf module RDS for PostgreSQL DB instances should publish logs to CloudWatch Logs Checks that Amazon RDS for PostgreSQL DB instances have CloudWatch Logs publishing enabled for the expected log types. Fails if the instance does not export the required log types (such as postgresql and upgrade) to CloudWatch Logs. low effort compliance.tf module RDS for SQL Server DB instances should publish logs to CloudWatch Logs Checks that Amazon RDS for Microsoft SQL Server DB instances have CloudWatch Logs publishing enabled. The control fails when no log types (such as error or agent) are configured for export to CloudWatch Logs via the instance's log export settings. low effort compliance.tf module RDS instances should be deployed in a VPC Checks whether each Amazon RDS instance is deployed in a VPC rather than the legacy EC2-Classic platform. Passes when the instance has an associated DB subnet group; fails when that association is absent or the instance has no VPC binding. medium effort compliance.tf module

Amazon Redshift

Redshift cluster encryption in transit should be enabled Validates that Amazon Redshift clusters are configured with a parameter group that sets require_ssl to true, ensuring all SQL client connections use TLS/SSL encryption in transit rather than allowing unencrypted plaintext communication. ◆◆◆ 19 frameworks low effort compliance.tf module Redshift clusters should be encrypted with CMK Validates that Amazon Redshift clusters are encrypted at rest using a customer-managed KMS key (CMK) rather than an AWS-managed default key or no encryption. Checks that both encryption is enabled and a specific CMK ARN is referenced. high effort compliance.tf module Redshift clusters should have audit logging and encryption enabled Validates that each AWS Redshift cluster has encryption at rest enabled and audit logging configured. Encryption protects stored data via KMS or HSM keys. Audit logging records connection attempts, user activity, and SQL queries against the cluster. ◆◆◆ 23 frameworks medium effort compliance.tf module Redshift clusters should have audit logging enabled Checks that Amazon Redshift clusters have audit logging enabled and, when a specific bucket name is provided, that the logging destination matches the expected S3 bucket. Clusters without audit logging or with a mismatched bucket fail the control. ◆◆◆ 8 frameworks low effort compliance.tf module Redshift clusters should have automatic snapshots enabled Checks that AWS Redshift clusters have automated snapshots enabled and that the snapshot retention period is at least seven days. Clusters with automated snapshots disabled or a retention period below seven days fail this control. ◆◆◆ 23 frameworks low effort compliance.tf module Redshift clusters should have automatic upgrades to major versions enabled Validates that AWS Redshift clusters have automatic major version upgrades enabled. When enabled, the cluster applies engine updates automatically during the configured maintenance window, without requiring operator intervention to initiate the upgrade. ◆ 1 framework low effort compliance.tf module Redshift clusters should have enhanced VPC routing enabled Checks that Amazon Redshift clusters have enhanced VPC routing enabled. When enabled, all COPY and UNLOAD traffic between the cluster and data repositories is forced through the VPC, allowing use of VPC security groups, NACLs, VPC endpoints, and VPC flow logs. ◆◆◆ 9 frameworks low effort compliance.tf module Redshift clusters should have KMS encryption enabled Validates that AWS Redshift clusters have encryption enabled using a customer-managed KMS key. The cluster must reference the designated KMS key ARN; using the default aws/redshift service key or no encryption at all fails this control. ◆◆◆ 12 frameworks high effort compliance.tf module Redshift clusters should have Multi-AZ deployments enabled Checks that Amazon Redshift clusters have Multi-AZ deployments enabled. The control fails when a Redshift cluster operates in a single Availability Zone, meaning a zone-level failure causes a full cluster outage and data unavailability until recovery completes. medium effort compliance.tf module Redshift clusters should have required maintenance settings Validates that AWS Redshift clusters have allow_version_upgrade set to true and automated_snapshot_retention_period greater than 7, ensuring clusters receive security patches and retain snapshots for adequate recovery windows. ◆◆◆ 13 frameworks low effort compliance.tf module Redshift clusters should not use the default admin username Validates that AWS Redshift clusters do not use the default admin username "awsuser". The control fails if master_username is set to that default, meaning the cluster was provisioned without customizing the admin credential at cluster creation. ◆ 2 frameworks high effort compliance.tf module Redshift clusters should not use the default database name Checks that Amazon Redshift clusters are not using the default database name "dev". The control fails when database_name is omitted or set to "dev" in the aws_redshift_cluster resource, indicating no custom name was set at deployment time. ◆ 1 framework high effort compliance.tf module Redshift clusters should prohibit public access Validates that Amazon Redshift clusters have the publicly_accessible attribute set to false, preventing the cluster from receiving a public IP and becoming reachable from the internet. Without this, the cluster endpoint is resolvable and reachable outside the VPC. ◆◆◆ 19 frameworks medium effort compliance.tf module

Amazon S3

S3 access points should have block public access settings enabled Validates that every Amazon S3 access point has all four block public access settings enabled: block_public_acls, ignore_public_acls, block_public_policy, and restrict_public_buckets. The control fails if any of these settings is disabled or missing on an access point. ◆◆ 3 frameworks low effort S3 buckets should have cross-region replication enabled Validates that each S3 bucket has cross-region replication (CRR) configured. New object versions are automatically copied to a destination bucket in a different AWS region, supporting data availability and recovery time objectives when a regional disruption occurs. ◆◆◆ 20 frameworks high effort compliance.tf module S3 buckets should have default encryption enabled Verifies that each AWS S3 bucket has a default server-side encryption configuration explicitly enabled, ensuring objects stored without a client-specified encryption method are automatically encrypted using SSE-S3 (AES-256) or SSE-KMS. ◆◆◆ 18 frameworks low effort compliance.tf module S3 buckets should have default encryption enabled using KMS Checks that each S3 bucket has a default server-side encryption configuration using AWS KMS (SSE-KMS or DSSE-KMS) rather than Amazon S3 managed keys (SSE-S3). Buckets encrypted only with AES-256 (SSE-S3) or with no encryption configuration fail this control. ◆◆◆ 18 frameworks medium effort compliance.tf module S3 buckets should have event notifications enabled Checks that S3 buckets have event notifications configured via aws_s3_bucket_notification. Fails when no notification configuration exists, leaving object creates, deletes, and restores undetected by downstream consumers or automated response systems. ◆◆◆ 6 frameworks medium effort compliance.tf module S3 buckets should have lifecycle policies configured Checks that each AWS S3 bucket has at least one lifecycle configuration rule defined. Buckets without any lifecycle policy fail this control. Lifecycle rules govern object transitions between storage classes and permanent deletion after defined retention periods. ◆◆◆ 6 frameworks medium effort compliance.tf module S3 buckets should have logging enabled Checks that each S3 bucket has server access logging enabled, directing access log records to a designated target bucket. This validates that read and write requests to the bucket are recorded for security monitoring and forensic analysis. ◆◆◆ 24 frameworks low effort compliance.tf module S3 buckets should have MFA delete enabled Checks that S3 buckets have MFA Delete enabled in their versioning configuration. MFA Delete requires the bucket owner to provide an MFA token before permanently deleting object versions or changing the bucket's versioning state. ◆◆◆ 6 frameworks high effort compliance.tf module S3 buckets should have object lock enabled Validates that S3 buckets have Object Lock enabled, enforcing a WORM (Write Once Read Many) model that prevents objects from being deleted or overwritten for a defined retention period or indefinitely. Applies to both governance and compliance retention modes. ◆◆◆ 13 frameworks high effort compliance.tf module S3 buckets should have object logging enabled Checks that S3 buckets have object-level logging enabled through CloudTrail data events. Object-level logging records individual API calls, including GetObject, PutObject, and DeleteObject, with caller identity, source IP, and timestamp captured for each access. ◆ 1 framework medium effort S3 buckets should have policies that prohibit public access Validates that S3 bucket policies do not grant unrestricted public access. The control passes if the bucket policy restricts access to specific principals, federated users, service principals, IP addresses, or VPCs. Buckets with no policy attached also pass. ◆◆◆ 16 frameworks medium effort compliance.tf module S3 buckets should have static website hosting disabled Checks that S3 buckets do not have static website hosting enabled. Static website hosting exposes bucket contents via an HTTP endpoint and typically requires disabling block public access settings, creating a direct path to unintended data exposure. medium effort compliance.tf module S3 buckets should have versioning enabled Checks that S3 bucket versioning is enabled, retaining multiple versions of each object in the bucket. When versioning is active, every PUT, POST, COPY, or DELETE generates a new version, allowing recovery from accidental overwrites or deletions. ◆◆◆ 26 frameworks medium effort compliance.tf module S3 buckets should not be accessible to all authenticated users Validates that S3 bucket ACLs do not grant any permissions (READ, WRITE, READ_ACP, WRITE_ACP, FULL_CONTROL) to the AuthenticatedUsers group, which includes every AWS-authenticated principal across all accounts, not just principals in your own organization. medium effort compliance.tf module S3 buckets should not use ACLs for user access control Checks that S3 buckets do not use access control lists (ACLs) to manage user permissions. Buckets should rely on IAM and bucket policies instead, since ACLs are a legacy mechanism that cannot express conditions and offer limited auditability. ◆◆◆ 6 frameworks medium effort compliance.tf module S3 buckets should prohibit public read access Checks whether S3 buckets permit public read access via bucket policies, ACLs, or misconfigured Block Public Access settings. Fails any bucket where anonymous or unauthenticated principals can retrieve objects or list bucket contents. ◆◆◆ 21 frameworks medium effort compliance.tf module S3 buckets should prohibit public write access Validates that S3 buckets do not permit public write access through bucket ACLs, bucket policies, or missing S3 Block Public Access settings. Checks that no configuration path allows unauthenticated or anonymous principals to upload, modify, or delete objects. ◆◆◆ 24 frameworks low effort compliance.tf module S3 buckets should restrict cross-account permissions Validates that each S3 bucket policy contains explicit Deny statements preventing cross-account principals from modifying bucket policies, object ACLs, or other permission-scoped actions. Without these statements, external accounts can weaken or remove access controls. ◆◆ 4 frameworks high effort compliance.tf module S3 buckets with versioning enabled should have lifecycle policies configured Checks that S3 buckets with versioning enabled have at least one lifecycle configuration rule defined. Buckets with versioning but no lifecycle policy retain every object version indefinitely, leading to uncontrolled storage growth and cost. ◆◆◆ 13 frameworks medium effort compliance.tf module S3 Multi-Region Access Points should have block public access settings enabled Validates that Amazon S3 Multi-Region Access Points have all four block public access settings enabled: block_public_acls, block_public_policy, ignore_public_acls, and restrict_public_buckets. The control fails if any of these settings are disabled. low effort S3 public access should be blocked at account level Validates that the AWS S3 account-level Public Access Block is enabled with all four settings (block_public_acls, ignore_public_acls, block_public_policy, restrict_public_buckets) set to true, preventing any bucket in the account from being made publicly accessible. ◆◆◆ 18 frameworks low effort compliance.tf module S3 public access should be blocked at bucket level Checks that every S3 bucket has an aws_s3_bucket_public_access_block resource with all four settings enabled: block_public_acls, ignore_public_acls, block_public_policy, and restrict_public_buckets. Bucket-level only; account blocks are checked separately. ◆◆◆ 16 frameworks low effort compliance.tf module

Amazon SQS

SQS queues should be encrypted with KMS CMK Checks that each SQS queue has server-side encryption configured with a KMS Customer Managed Key (CMK), not the default SSE-SQS managed encryption. Queues using AWS-owned keys or without an explicit kms_master_key_id set fail this control. ◆ 1 framework medium effort compliance.tf module SQS queues should have a dead-letter queue configured Validates that each Amazon SQS queue has a redrive policy pointing to a dead-letter queue (DLQ) with a defined maxReceiveCount. Queues without a DLQ keep retrying failed messages until retention expires, making failures harder to isolate and troubleshoot. medium effort compliance.tf module SQS queues should have encryption at rest enabled Validates that each AWS SQS queue has server-side encryption enabled at rest, either through SQS-managed encryption (SSE-SQS) or a customer-managed KMS key (SSE-KMS). Queues with no encryption configuration fail the check. ◆ 1 framework low effort compliance.tf module

Amazon VPC

EC2 VPC Block Public Access settings should block internet gateway traffic Validates that Amazon EC2 VPC Block Public Access (BPA) is enabled at the account level with InternetGatewayBlockMode set to block-bidirectional or block-ingress, preventing VPCs from routing traffic through internet gateways without explicit exclusions. high effort EC2 VPN connections should have logging enabled Checks that every AWS Site-to-Site VPN connection has CloudWatch Logs enabled on both tunnels. The control fails when either tunnel1 or tunnel2 lacks CloudWatch log delivery, leaving VPN activity unmonitored across the connection. low effort compliance.tf module VPC endpoint services should have acceptance required enabled Checks that VPC endpoint services set acceptance_required = true. Any principal with endpoint creation permissions can connect immediately when this is unset. With it enabled, consumer requests enter pendingAcceptance and must be approved before traffic flows. low effort VPC Security groups should only allow unrestricted incoming traffic for authorized ports Validates that VPC security groups only permit unrestricted inbound traffic (0.0.0.0/0 or ::/0) on explicitly authorized ports. By default, only TCP ports 80 and 443 are considered authorized. Any other port open to the entire internet fails the check. ◆◆◆ 9 frameworks medium effort compliance.tf module VPC security groups should restrict ingress from 0.0.0.0/0 or ::/0 to cassandra ports 7199 or 9160 or 8888 Checks that VPC security groups do not allow inbound traffic from 0.0.0.0/0 or ::/0 to Cassandra ports 7199 (JMX), 9160 (Thrift), or 8888 (native OpsCenter). Passes when no rule permits unrestricted internet access to these ports. medium effort compliance.tf module VPC subnet auto assign public IP should be disabled Checks that VPC subnets do not have the auto-assign public IP address setting enabled. A subnet passes when map_public_ip_on_launch is false (the default). A subnet fails when instances launched into it automatically receive a public IPv4 address. ◆◆◆ 13 frameworks medium effort compliance.tf module

AWS AppSync

AppSync API caches should have encryption at rest enabled Checks that AWS AppSync GraphQL API caches have encryption at rest enabled. The control fails if an aws_appsync_api_cache resource exists without at-rest encryption, leaving cached query results exposed to unauthorized disk-level access. low effort compliance.tf module AppSync API caches should have encryption in transit enabled Checks that an AWS AppSync GraphQL API cache has encryption in transit enabled. The control fails if the API cache resource exists but does not enforce TLS for data moving between the AppSync resolver and the cache node. medium effort compliance.tf module AppSync GraphQL APIs should have field-level logging enabled Checks that each AWS AppSync GraphQL API has field-level logging enabled. The control evaluates the field_log_level setting in the log_config block. A value of ERROR or ALL passes; NONE or a missing log_config block fails. ◆◆ 3 frameworks low effort compliance.tf module AppSync GraphQL APIs should not use API key authentication Checks that AWS AppSync GraphQL APIs do not use API_KEY as an authentication type. The control fails if any AppSync GraphQL API has its primary or additional authentication provider configured with API key authentication. medium effort compliance.tf module

AWS Certificate Manager

ACM certificates should have transparency logging enabled Validates that ACM certificates have Certificate Transparency (CT) logging enabled. All issued certificates are published to public CT logs, where misissued or fraudulently obtained certificates can be detected by domain owners and security researchers. ◆ 1 framework low effort compliance.tf module ACM certificates should not use wildcard certificates Checks that AWS Certificate Manager certificates do not use wildcard domain names (e.g., *.example.com) in the primary domain or subject alternative names, requiring individual certificates per domain or subdomain instead. high effort compliance.tf module ACM RSA certificates should use a key length of at least 2,048 bits Checks that RSA certificates managed by AWS Certificate Manager use a key length of at least 2,048 bits. The control fails if an ACM-managed RSA certificate has a key length smaller than 2,048 bits, such as 1,024-bit RSA keys. ◆ 2 frameworks low effort compliance.tf module

AWS Database Migration Service

DMS endpoints should use SSL Checks that AWS DMS endpoints have ssl_mode set to a value other than "none". Fails when ssl_mode is omitted or explicitly "none", leaving replication traffic unencrypted between the DMS replication instance and the source or target database. medium effort Dms Replication Instance Encryption Enabled compliance.tf module

AWS DMS

DMS endpoints for MongoDB should have an authentication mechanism enabled Checks whether AWS DMS MongoDB endpoints have authentication configured. Fails when auth_type is absent, set to "no", or when the mongodb_settings block is omitted, leaving the replication connection open to unauthenticated access. low effort DMS endpoints for Redis OSS should have TLS enabled Checks that AWS DMS endpoints configured with Redis OSS as the target or source engine have TLS enabled for the connection. The control fails if the redis_settings block does not specify ssl_security_protocol as ssl-encryption. low effort DMS replication instances should have automatic minor version upgrade enabled Checks that AWS DMS replication instances have automatic minor version upgrade enabled. The control fails when the auto_minor_version_upgrade setting on a replication instance is disabled, leaving the instance on outdated engine versions. low effort compliance.tf module DMS replication instances should not be publicly accessible Checks that AWS DMS replication instances have publicly_accessible set to false, preventing the assignment of a public IP address and blocking direct internet access to instances that handle database migration traffic. ◆◆◆ 19 frameworks medium effort compliance.tf module

AWS KMS

KMS CMK rotation should be enabled Checks that automatic annual key rotation is enabled for AWS KMS customer managed keys (CMKs). When enabled, AWS generates new cryptographic material for the key every year while preserving the original key ID and ARN for decryption of older ciphertexts. ◆◆◆ 17 frameworks low effort compliance.tf module

AWS Lambda

Lambda functions CORS configuration should not allow all origins Checks that Lambda function URL CORS configurations do not set allow_origins to ["*"]. A wildcard lets any domain issue cross-origin browser requests to the function, bypassing domain-level access controls. The control fails when "*" appears in the origins list. low effort compliance.tf module Lambda functions should be configured with a dead-letter queue Checks that every AWS Lambda function has a dead-letter queue configured, targeting either an SQS queue or SNS topic. Without this, failed asynchronous invocations are silently discarded after retry exhaustion, leaving no record and no recovery path. ◆◆◆ 10 frameworks medium effort compliance.tf module Lambda functions should be in a VPC Checks that every AWS Lambda function is associated with at least one VPC subnet and security group via the vpc_config block, ensuring the function runs inside a Virtual Private Cloud rather than the default Lambda networking environment. ◆◆◆ 18 frameworks high effort compliance.tf module Lambda functions should have concurrent execution limit configured Validates that each AWS Lambda function has a function-level concurrent execution limit configured via reserved_concurrent_executions. Functions without this setting can consume the entire account-level concurrency pool, starving other functions of capacity. ◆◆◆ 9 frameworks medium effort compliance.tf module Lambda functions should have encryption in transit enabled for environment variables Checks that every aws_lambda_function specifies a customer-managed KMS key via kms_key_arn to encrypt environment variables at rest. Without it, Lambda falls back to the AWS-managed default, leaving key rotation and access policies outside your control. medium effort compliance.tf module Lambda functions should have logging config enabled Checks that every aws_lambda_function resource includes a logging_config block with an explicit log_format, directing invocation logs to a CloudWatch Log Group with configurable format and optional per-severity filtering for application and system logs. low effort compliance.tf module Lambda functions should restrict public URL Checks that AWS Lambda functions do not have a publicly accessible function URL. A Lambda function URL with authorization_type set to NONE allows unauthenticated invocation from the internet, potentially exposing application logic and sensitive data. low effort compliance.tf module Lambda functions should use latest runtimes Validates that AWS Lambda functions are configured with a supported runtime version from an approved list, including nodejs20.x, python3.12, ruby3.3, java21, dotnet8, and other current releases. Functions using deprecated or end-of-life runtimes fail this control. ◆◆ 3 frameworks medium effort compliance.tf module Lambda functions tracing should be enabled Validates that each AWS Lambda function has X-Ray tracing enabled. Functions must set tracing mode to Active so invocation traces are captured and forwarded to X-Ray, giving you visibility into request paths, downstream call latency, and error rates. low effort compliance.tf module

AWS Network Firewall

Network Firewall firewalls should have deletion protection enabled Checks that each AWS Network Firewall firewall has deletion protection enabled. The control fails when the deletion protection flag is disabled, meaning the firewall can be deleted in a single API call with no prerequisite step to disable protection first. low effort compliance.tf module Network Firewall firewalls should have subnet change protection enabled Checks whether Network Firewall firewalls have subnet change protection enabled, blocking unauthorized modifications to subnet associations. The control fails when subnet_change_protection is not explicitly set to true on the aws_networkfirewall_firewall resource. low effort compliance.tf module Network Firewall policies should have default stateless action set to drop or forward for fragmented packets Checks that the default stateless action for fragmented packets in an AWS Network Firewall policy is set to drop or forward to stateful rule groups, not pass. Policies that pass fragmented packets by default fail this control. ◆◆ 3 frameworks low effort compliance.tf module Network Firewall policies should have default stateless action set to drop or forward for full packets Validates that AWS Network Firewall policy default stateless actions for full packets are set to drop or forward to the stateful rule engine, not pass. This prevents unfiltered traffic from bypassing inspection when no stateless rule explicitly matches a packet. ◆◆ 3 frameworks low effort compliance.tf module

AWS Secrets Manager

Secrets Manager secrets should be encrypted using CMK Validates that each AWS Secrets Manager secret is encrypted with a customer-managed KMS key (CMK) rather than the default AWS-managed aws/secretsmanager key. With a CMK, you control key rotation schedules, key policies, and the audit trail for every decrypt operation. ◆◆◆ 9 frameworks medium effort compliance.tf module

AWS SNS

SNS topics should be encrypted at rest Checks that each AWS SNS topic has server-side encryption enabled using a KMS key. Topics without the kms_master_key_id attribute configured transmit and store messages in plaintext within the SNS infrastructure, failing this control. ◆◆◆ 21 frameworks low effort compliance.tf module

AWS Step Functions

Step Functions state machines should have logging enabled Checks whether AWS Step Functions state machines have logging enabled. The control fails if a state machine has no logging configuration or if the logging level is set to OFF. A custom log level parameter can require a specific minimum level, such as ALL or ERROR. ◆◆ 4 frameworks low effort compliance.tf module

AWS Systems Manager

SSM parameters encryption should be enabled Checks that AWS Systems Manager Parameter Store parameters use the SecureString type, which encrypts values at rest using a KMS key. Parameters stored as String or StringList expose raw values in API responses and fail this control. ◆ 1 framework medium effort compliance.tf module

Elastic Load Balancing

Classic Load Balancers should have connection draining enabled Checks that Classic Load Balancers (CLBs) have connection draining enabled. When draining is off, in-flight requests to deregistered or unhealthy instances are dropped immediately. This control verifies connection_draining = true on every aws_elb resource. low effort compliance.tf module ELB application and classic load balancer logging should be enabled Checks that Application Load Balancers and Classic Load Balancers have access logging enabled, sending request-level log data to an S3 bucket. Each log entry includes client IP, latencies, request paths, and server responses. ◆◆◆ 22 frameworks low effort compliance.tf module ELB application and network load balancer listeners should use secure protocols Validates that Application Load Balancer listeners are configured for HTTPS and Network Load Balancer listeners are configured for TLS, ensuring all traffic passing through the load balancer is encrypted in transit using a valid SSL/TLS certificate. medium effort compliance.tf module ELB application and network load balancers should only use SSL or HTTPS listeners Validates that all Application Load Balancer and Network Load Balancer listeners are configured with HTTPS or TLS protocols and reference an ACM-provisioned certificate ARN, ensuring no listener accepts unencrypted client traffic at the load balancer boundary. ◆◆◆ 15 frameworks medium effort compliance.tf module ELB application and network load balancers should use recommended security policies Checks that HTTPS listeners on Application Load Balancers and TLS listeners on Network Load Balancers use a recommended security policy, ensuring strong cipher suites and modern TLS protocol versions protect data in transit. low effort compliance.tf module ELB application load balancer deletion protection should be enabled Checks that each AWS Application Load Balancer has deletion protection enabled. When enabled, the ALB cannot be deleted through the console, CLI, or API without first disabling this flag, preventing accidental removal of production traffic routing. ◆◆◆ 14 frameworks low effort compliance.tf module ELB application load balancers should be configured to drop HTTP headers Validates that AWS Application Load Balancers have the drop_invalid_header_fields attribute enabled, causing the ALB to silently drop HTTP headers that do not conform to valid header field formatting rather than forwarding them to backend targets. ◆◆◆ 12 frameworks low effort compliance.tf module ELB application load balancers should be configured with defensive or strictest desync mitigation mode Validates that each Application Load Balancer has desync mitigation mode set to "defensive" or "strictest". The weaker "monitor" mode logs ambiguous HTTP requests but still forwards them, leaving back-end targets exposed to request smuggling. ◆ 2 frameworks low effort compliance.tf module ELB application load balancers should drop invalid HTTP headers Checks that each Application Load Balancer has drop_invalid_header_fields set to true, causing the ALB to silently discard HTTP requests with malformed or non-conforming header fields before routing traffic to any registered target. ◆◆◆ 12 frameworks low effort compliance.tf module ELB classic load balancers should be configured with defensive or strictest desync mitigation mode Validates that AWS Classic Load Balancers have their desync mitigation mode set to "defensive" or "strictest" rather than "monitor", protecting against HTTP desync and request smuggling attacks that exploit parsing differences between frontend and backend servers. ◆◆ 3 frameworks low effort compliance.tf module ELB classic load balancers should have cross-zone load balancing enabled Checks that Classic Elastic Load Balancers have cross-zone load balancing enabled, ensuring incoming traffic is distributed across registered instances in all enabled availability zones rather than being confined to the AZ that received the request. ◆◆◆ 13 frameworks low effort compliance.tf module ELB classic load balancers should span multiple availability zones Validates that each Classic Load Balancer is configured to span at least two Availability Zones. The control fails when a CLB is associated with fewer than two AZs, indicating a single-AZ deployment with no fault-domain redundancy at the load balancer layer. ◆ 2 frameworks medium effort compliance.tf module ELB listeners should use approved SSL/TLS protocol versions Validates that ELB HTTPS and TLS listeners are configured with a security policy that enforces TLS 1.2 as the minimum protocol version, preventing clients from negotiating the deprecated TLS 1.0 and 1.1 versions at connection time. ◆ 1 framework low effort compliance.tf module ELB load balancers should prohibit public access Checks that Application, Classic, and Network Load Balancers use an internal scheme rather than internet-facing. Public load balancers expose backend resources to untrusted internet traffic and widen the attack surface beyond what security groups alone can contain. high effort compliance.tf module ELB network load balancers should have TLS listener security policy configured Validates that each TLS listener on an AWS Network Load Balancer has an explicit security policy (ssl_policy) set, ensuring the NLB negotiates connections using approved cipher suites and TLS protocol versions rather than falling back to weak defaults. ◆ 1 framework low effort compliance.tf module