Athena Encryption Can Be Overridden: Enforce Workgroup Encryption

Athena makes it easy to query data sitting in S3 without standing up any infrastructure. The catch is that every query writes its results back to an S3 location, and those result sets often contain exactly the sensitive data you were trying to analyze. If the workgroup is configured to encrypt results but does not enforce that configuration, any client can quietly opt out and write plaintext output to your bucket.

This check, athena_encryptionoverride in the athena_checks module, flags Athena workgroups where the encryption configuration can be overridden at query time.

---

What this check detects

Every Athena workgroup has a configuration block that controls where results go and how they are encrypted. Two settings work together here:

• ResultConfiguration defines the S3 output location and an optional EncryptionConfiguration (SSE-S3, SSE-KMS, or CSE-KMS).
• EnforceWorkGroupConfiguration determines whether the workgroup settings are mandatory. When set to false, clients can supply their own ResultConfiguration on each StartQueryExecution call and override whatever the workgroup defined, including the encryption settings.

This check fails when a workgroup has EnforceWorkGroupConfiguration set to false. The workgroup might have a perfectly good KMS encryption config defined, but because it is not enforced, that config is effectively a default suggestion rather than a guardrail.

---

Why it matters

The risk is subtle because the workgroup looks secure. An auditor reviewing the console sees an encryption configuration attached to the workgroup and assumes results are encrypted. In reality, the enforcement flag is the only thing that makes that config binding.

Here is how it goes wrong in practice:

• Plaintext results in S3. A developer or an automated job calls StartQueryExecution with its own ResultConfiguration and no encryption. The query results, potentially containing PII, financial records, or access logs, are written to S3 in plaintext.
• Compliance gaps. Frameworks like PCI DSS, HIPAA, and SOC 2 expect data at rest to be encrypted. A single overriding client breaks that guarantee, and you will not know unless you inspect every object's encryption status.
• Key segregation bypass. If you use SSE-KMS to control who can read results through key policies, an override to SSE-S3 or no encryption removes that access boundary. Anyone with bucket read access can now read the data.
• Inconsistent output locations. Because the same flag controls the output location, an override can also redirect results to a bucket with looser access controls or no encryption at all.

---

How to fix it

The fix is to enable enforcement on the workgroup so its encryption configuration becomes mandatory. Make sure the workgroup actually has an encryption configuration defined first, otherwise enforcement will lock clients into unencrypted results.

1. Inspect the current workgroup

aws athena get-work-group \
  --work-group analytics-prod \
  --query 'WorkGroup.Configuration.{Enforce:EnforceWorkGroupConfiguration,Result:ResultConfiguration}'

If Enforce comes back false or the EncryptionConfiguration is missing, you have work to do.

2. Update the workgroup via CLI

Set the encryption configuration and enable enforcement in one call:

aws athena update-work-group \
  --work-group analytics-prod \
  --configuration-updates '{
    "EnforceWorkGroupConfiguration": true,
    "ResultConfigurationUpdates": {
      "OutputLocation": "s3://my-athena-results/analytics-prod/",
      "EncryptionConfiguration": {
        "EncryptionOption": "SSE_KMS",
        "KmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd1234-..."
      }
    }
  }'

3. Confirm the change

aws athena get-work-group \
  --work-group analytics-prod \
  --query 'WorkGroup.Configuration.EnforceWorkGroupConfiguration'

You want true.

Console steps

1. Open the Athena console and go to Administration → Workgroups.
2. Select the workgroup and choose Edit.
3. Set the query result location and choose Encrypt query results, picking SSE-KMS with your CMK.
4. Check Override client-side settings. This is the console label for EnforceWorkGroupConfiguration.
5. Save changes.

Terraform

resource "aws_athena_workgroup" "analytics_prod" {
  name = "analytics-prod"

  configuration {
    enforce_workgroup_configuration    = true
    publish_cloudwatch_metrics_enabled = true

    result_configuration {
      output_location = "s3://my-athena-results/analytics-prod/"

      encryption_configuration {
        encryption_option = "SSE_KMS"
        kms_key_arn       = aws_kms_key.athena.arn
      }
    }
  }
}

The two lines that matter are enforce_workgroup_configuration = true and the encryption_configuration block. Together they make encrypted results mandatory.

{
  "Sid": "DenyUnencryptedResults",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-athena-results/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "aws:kms"
    }
  }
}

---

How to prevent it from happening again

Manual fixes drift. New workgroups get created by data teams, and the default for EnforceWorkGroupConfiguration is false when you create a workgroup through the API without setting it. Bake the control into your pipeline instead.

Policy-as-code in CI/CD

If you manage Athena through Terraform, add a Checkov or OPA gate that blocks any plan where enforcement is off. Checkov ships a built-in rule for this:

checkov -d ./terraform --check CKV_AWS_82

CKV_AWS_82 verifies that Athena workgroups enforce their configuration. Run it in your PR pipeline and fail the build on a violation.

OPA / Conftest example

package athena

deny[msg] {
  resource := input.resource.aws_athena_workgroup[name]
  resource.configuration.enforce_workgroup_configuration != true
  msg := sprintf("Athena workgroup '%s' must enforce its configuration", [name])
}

Detect drift at runtime

For workgroups created outside IaC, an AWS Config custom rule or a scheduled scan catches drift. A quick Config rule expression checks the same property the API exposes. Lensix runs athena_encryptionoverride continuously across your accounts, so a workgroup created by hand or modified out of band shows up without you wiring anything together.

---

Best practices

• Always enforce workgroup configuration. Treat EnforceWorkGroupConfiguration = true as the default for every workgroup, not an opt-in.
• Use SSE-KMS over SSE-S3 for sensitive data. KMS gives you key policies, grants, and CloudTrail visibility into who decrypted results. SSE-S3 encrypts at rest but offers no access control beyond bucket permissions.
• Lock down the results bucket. Apply a deny-unencrypted bucket policy, block public access, and scope read access to the roles that actually need query output.
• Set result expiration. Use the workgroup's result configuration or an S3 lifecycle rule to expire old query results so plaintext exposure windows stay short and storage costs stay down.
• Separate workgroups by sensitivity. Give regulated datasets their own workgroup with its own CMK, so key access maps cleanly to data classification.
• Audit existing results after enabling enforcement. Enforcement only protects new queries, so scan the bucket for objects without KMS encryption and re-encrypt or delete them.

Enforcing encryption on Athena workgroups is a small change with an outsized payoff. One flag turns a hopeful default into a binding control, and combined with a tight bucket policy and a CI gate, it keeps your query results encrypted no matter who is calling the API.