Amazon Athena Security: Workgroups, Query Results and Lake Permissions

Amazon Athena lets anyone with the right permissions run SQL over an entire data lake, and every query leaves a copy of its answer in Amazon S3, so the access model has to cover the data, the catalogue, the results and the query history together. Under the AWS shared responsibility model, AWS runs the query engine; the customer decides who can query which workgroup, where results land and how they are encrypted, which tables Lake Formation governs, and which federated connectors exist. This guide covers those settings in depth: workgroup enforcement, IAM policies scoped to workgroups and catalogues, result encryption, Lake Formation integration and its boundaries, federated query connectors, cost controls and logging. It is for data platform engineers, cloud security engineers and auditors. For the storage layer underneath, read the Amazon S3 Security Guide first.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Workgroups are the security boundary for queries. Scope IAM to specific workgroup ARNs and turn on Override client-side settings so the results location, expected bucket owner and encryption cannot be changed by the client.
• Query results need their own protection. Results locations cannot be registered with Lake Formation, so lock the results bucket down with IAM and bucket policy per workgroup, and encrypt it with SSE-KMS.
• Query history is sensitive. It holds full query strings, so separate workgroups by audience and align membership with Lake Formation permissions.
• Lake Formation governs reads of registered data. Column, row and cell permissions apply to registered tables; writes, unregistered data and results stay under IAM, so design both layers.
• Federated connectors are Lambda functions with credentials. Grant lambda:InvokeFunction only on named connector ARNs, keep source credentials in AWS Secrets Manager, and protect the spill bucket like the results bucket.

How identity and access work in Athena

Athena has no database users. Every query is an API call (StartQueryExecution) by an AWS principal: an IAM role, an IAM Identity Center user through a trusted identity propagation workgroup, or a federated session. Running a query successfully needs several permissions at once:

AWS's example policy for running queries in one workgroup grants account-level list and metadata actions (such as athena:ListWorkGroups, ListDatabases, GetTableMetadata) on *, and query, named query and prepared statement actions on the single workgroup ARN. AWS notes that this example does not by itself stop users from using other workgroups, so pair it with no other workgroup grants, or add an explicit deny on workgroups outside the user's set. Tag-based conditions (aws:ResourceTag) on workgroups make that scalable across teams. For policy design patterns, see the AWS IAM Policies and Roles Guide.

Workgroup enforcement

The workgroup setting Override client-side settings (EnforceWorkGroupConfiguration in the API) makes the workgroup's results location, expected bucket owner, encryption and control of objects written to the results bucket apply to every query, whatever the console, JDBC or ODBC driver, CLI or SDK sends. Without it, client-side settings take precedence. AWS warns that turning it on can break automation that expects results in a particular bucket, and users see a console notice to acknowledge, so announce the change and update tools first.

Admin roles and privileged access

Privileged operations in Athena are workgroup management (create, update, delete, and changing enforcement or encryption), data catalogue registration (including federated catalogues), Lake Formation administration, and deployment of connectors.

• Keep workgroup management separate: athena:CreateWorkGroup, UpdateWorkGroup and DeleteWorkGroup belong in an administrator policy, never in analyst or application roles. An analyst who can update a workgroup can turn off enforcement or change the results location.
• Use AmazonAthenaFullAccess for administrators only: AWS describes it as full access to Athena, with Glue, S3 results, SNS, CloudWatch alarm and Lake Formation data access permissions. For analysts and applications, write workgroup-scoped policies instead. Attach AWSQuicksightAthenaAccess only to principals that use Amazon Quick (QuickSight) with Athena.
• Treat connector deployment as privileged: deploying a connector involves creating Lambda functions and IAM roles (including iam:PassRole) and CloudFormation stacks. Limit it to a platform team and review each connector's execution role.
• Name Lake Formation administrators deliberately: data lake administrators can grant themselves and others access to any registered table. Keep the list short and review it alongside IAM administrators.
• Protect the primary workgroup: every account has a primary workgroup. Apply enforcement and encryption to it too, or deny its use, so it does not become the unmanaged path.

Integrations, API tokens and service accounts

A large share of Athena queries come from non-human identities: BI tools, scheduled ETL, notebooks, applications and AI agents generating SQL. Give each its own IAM role and its own workgroup, so permissions, results, history and cost limits are separate. See the AWS IAM Roles Anywhere Security Guide for workloads outside AWS that would otherwise need long-term access keys.

Federated query connectors

Each Athena data source connector runs as an AWS Lambda function registered as a data catalogue. AWS's federated query permissions example grants query actions on named workgroup and data catalogue ARNs, lambda:InvokeFunction on named connector functions, and S3 actions on the results bucket and the spill bucket, where connectors write data too large to return directly. To run connectors safely:

1. Grant lambda:InvokeFunction only on specific connector ARNs, never on *, and only to roles that should reach that source.
2. Give each connector's execution role read-only database credentials stored in AWS Secrets Manager, with rotation turned on. See the Secrets Management Guide.
3. Place connectors for private sources in your VPC with security groups limited to the database port.
4. Scope s3:GetObject on the spill bucket to the configured spill prefix, encrypt the bucket with SSE-KMS and add a lifecycle rule that expires spilled data.
5. Remember that Lake Formation permissions apply to registered data in S3 and the Glue Data Catalog; access to federated sources is governed by the connector's credentials and by who can invoke it.

Logging and detection

AWS CloudTrail records Athena API calls (event source athena.amazonaws.com) from the console, SDKs and drivers. For StartQueryExecution and CreateNamedQuery the queryString field is recorded as ***OMITTED*** by design; to see the SQL, call GetQueryExecution with the queryExecutionId from the log entry. Create an organisation trail so events are kept beyond the console's event history, and add Lake Formation and S3 data events for the results and spill buckets where you need object-level evidence.

Map detections to MITRE ATT&CK T1530 Data from Cloud Storage and T1078.004 Cloud Accounts. Amazon GuardDuty adds threat detection on CloudTrail and S3 activity; see the Amazon GuardDuty Guide.

Metrics that show it is working

• Share of workgroups with Override client-side settings on and SSE-KMS result encryption (target: all).
• Principals with Athena permissions on * workgroups outside the administrator group (target: zero).
• Sensitive tables governed by Lake Formation rather than S3 IAM alone.
• Connector roles with lambda:InvokeFunction scoped to named ARNs (target: all).
• Workgroups with a data scanned limit and data usage alerts configured.
• Results buckets with lifecycle expiry and bucket owner enforced settings.

Hardening baseline

Apply in this order, piloting each step on one team's workgroup. Keep a copy of each workgroup configuration (aws athena get-work-group) and IAM policy version so you can roll back.

1. Inventory: list workgroups, their enforcement and encryption settings, results locations, data catalogues (including federated and cross-account) and the principals with Athena permissions.
2. Design workgroups by audience: one per team, application or agent, each with its own results prefix or bucket, because results and history are shared within a workgroup.
3. Enforce and encrypt: turn on Override client-side settings, set the expected bucket owner, and choose SSE-KMS with a customer managed key for results (AWS's recommended option). Turn on S3 Bucket Keys if KMS request volume becomes high.
4. Lock the results bucket: S3 Block Public Access, bucket owner enforced object ownership, a bucket policy allowing only the workgroup's roles on its prefix, and a lifecycle rule that expires results and aborts incomplete multipart uploads.
5. Scope IAM: replace broad managed policies on analysts and applications with workgroup-scoped policies, and deny workgroups outside each role's set.
6. Adopt Lake Formation for sensitive data: register the S3 locations, grant database, table and column permissions (with data filters for rows and cells), and remove the direct S3 read grants that Lake Formation now replaces. Grant DESCRIBE on the default database, which Athena requires.
7. Encrypt the catalogue: if Glue Data Catalog metadata is encrypted, give Athena users kms:GenerateDataKey, kms:Decrypt and kms:Encrypt on that key. See the AWS KMS Security Guide.
8. Set cost and volume controls: a per-query Data scanned limit (minimum 10 MB) cancels oversized queries; per-workgroup data usage alerts send SNS notifications and can trigger an action such as disabling the workgroup.
9. Govern connectors: apply the federated query steps above.
10. Log and alert: confirm the organisation trail, add data events for results buckets, and build the alerts above.

Decision guidance

Framework mapping

Common misconfigurations

• Enforcement left off: a client can then send results to a bucket of its choosing without encryption. Turn on Override client-side settings.
• One results bucket readable by all analysts: anyone with S3 read on the bucket can read other people's results without permission on the source tables. Use per-workgroup prefixes and bucket policy.
• Assuming Lake Formation covers results and history: it governs registered source data; results locations and query history are controlled by IAM and workgroups, so align workgroup membership with Lake Formation grants.
• Column metadata in table properties: for Avro or custom SerDe tables with the schema in table properties, column names stay visible to users without column access. Review table properties before registering sensitive tables.
• Direct S3 grants kept after adopting Lake Formation: a role with both can read the full objects directly. Remove direct S3 read on registered locations.
• Wildcard connector invoke: lambda:InvokeFunction on * lets a role query every federated source. Name the connector ARNs.

Practitioner checklist

• Create workgroups per team, application or agent, with Override client-side settings on and SSE-KMS result encryption.
• Scope Athena IAM to named workgroup and data catalogue ARNs and keep workgroup management with administrators.
• Lock results and spill buckets with Block Public Access, bucket owner enforced ownership, per-prefix policies and lifecycle expiry.
• Register sensitive data with Lake Formation, use data filters for rows and cells, and remove direct S3 read grants.
• Keep connector credentials in Secrets Manager and grant invoke on named connector functions only.
• Set per-query data scanned limits and per-workgroup data usage alerts.
• Enforce or deny the primary workgroup.
• Alert on workgroup changes, new data catalogues, Lake Formation grants and unusual result retrieval.

Standards and references

• AWS: Security in Amazon Athena
• AWS: Override client-side settings for workgroups
• AWS: Example workgroup policies
• AWS: Encryption at rest in Athena
• AWS: Considerations for Athena with Lake Formation
• AWS: Permissions for federated queries
• AWS: Log Athena API calls with CloudTrail
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Amazon S3 Security Guide · AWS IAM Policies and Roles Guide · AWS KMS Security Guide · Amazon EMR Security