# Security for S3 Files Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: **Security of the cloud** AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Amazon S3 Files, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). **Security in the cloud** Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company's requirements, and applicable laws and regulations. This documentation helps you understand how to apply the shared responsibility model when using Amazon S3 Files. ## Data Protection The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in S3 Files. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*. + Use AWS encryption solutions, along with all default security controls within AWS services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with S3 Files or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server. **Topics** + [ ## Data Protection ](#s3-files-security-data-protection) + [ # Encryption ](s3-files-encryption.md) + [ # How S3 Files works with IAM ](s3-files-security-iam.md) # Encryption S3 Files provides comprehensive encryption capabilities to protect your data both at rest and in transit. ## Encryption at rest Your S3 bucket is encrypted using Amazon S3's encryption mechanisms. For information on encryption of data in S3, see [Protecting data with encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html). S3 Files encrypts data at rest in the S3 file system using server-side encryption. Server-side encryption is the encryption of data at its destination by the application or service that receives it. In S3 file systems, data and metadata are encrypted by default before being written to storage and are automatically decrypted when read. These processes are handled transparently by S3 Files, so you don't need to modify your applications. All data at rest in the file system is encrypted using AWS Key Management Service (KMS) keys using one of the following methods: + (Default) Server-side encryption with AWS owned KMS keys (SSE-KMS) + Server-side encryption with Customer managed KMS keys (SSE-KMS-CMK) There are additional charges for using AWS KMS keys. For more information, see [AWS KMS key concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) in the *AWS Key Management Service Developer Guide* and [AWS KMS pricing](https://aws.amazon.com/kms/pricing/). ### Server-side encryption with AWS owned KMS keys (SSE-KMS) This is the default key for encrypting data at rest in your S3 file system. AWS owned keys are a collection of KMS keys that an AWS service owns and manages. S3 Files owns and manages encryption of your data and metadata at rest in your S3 file system when you use an AWS owned key. For more details on AWS owned keys, visit [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html). ### Server-side encryption with customer managed AWS KMS keys (SSE-KMS-CMK) While creating your file system, you can choose to configure an AWS Key Management Service (AWS KMS) key that you manage. When you use SSE-KMS encryption with an S3 file system the AWS KMS keys must be in the same Region as the file system. ## S3 Files key policies for AWS KMS Key policies are the primary way to control access to customer managed keys. For more information on key policies, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) in the *AWS Key Management Service Developer Guide*. The following list describes all the AWS KMS–related permissions that are supported by S3 Files for encrypting file systems at rest: kms:Encrypt (Optional) Encrypts plaintext into ciphertext. This permission is included in the default key policy. kms:Decrypt (Required) Decrypts ciphertext. Ciphertext is plaintext that has been previously encrypted. This permission is included in the default key policy. kms:ReEncrypt (Optional) Encrypts data on the server side with a new customer managed key, without exposing the plaintext of the data on the client side. The data is first decrypted and then re-encrypted. This permission is included in the default key policy. kms:GenerateDataKeyWithoutPlaintext (Required) Returns a data encryption key encrypted under a customer managed key. This permission is included in the default key policy under kms:GenerateDataKey\$1. kms:CreateGrant (Required) Adds a grant to a key to specify who can use the key and under what conditions. Grants are alternate permission mechanisms to key policies. For more information on grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide*. This permission is included in the default key policy. kms:DescribeKey (Required) Provides detailed information about the specified customer managed key. This permission is included in the default key policy. kms:ListAliases (Optional) Lists all of the key aliases in the account. When you use the console to create an encrypted file system, this permission populates the Select KMS key list. We recommend using this permission to provide the best user experience. This permission is included in the default key policy. ## Key states and their effects The state of your KMS key directly affects access to your encrypted file system: Enabled Normal operation - full read and write access to the file system. Disabled File system becomes inaccessible after some time. Can be re-enabled. Pending deletion File system becomes inaccessible. Deletion can be canceled during the waiting period. Note that after cancelling key deletion, the key needs to be moved to enabled state. Deleted File system permanently inaccessible. This action cannot be reversed. **Warning** If you disable or delete the KMS key used for your file system, or revoke S3 Files access to the key, your file system will become inaccessible. This can result in data loss if you don't have backups. Always ensure you have proper backup procedures in place before making changes to encryption keys. ## Encryption in transit S3 Files requires encryption of data in transit using Transport Layer Security (TLS). When you mount your file system using the mount helper, all data traveling between your client and the file system is encrypted using TLS. The mount helper initializes efs-proxy process to establish a secure TLS connection with your file system. The mount helper also creates a process called amazon-efs-mount-watchdog that monitors the health of mounts, and is started automatically the first time an S3 file system is mounted. It ensures that each mount's efs-proxy process is running, and stops the process when the file system is unmounted. If for some reason the process is terminated unexpectedly, the watchdog process restarts it. The following describes how TLS encryption in transit works: 1. A secure TLS connection is established between your client and the file system 1. All NFS traffic is routed through this encrypted connection 1. Data is encrypted before transmission and decrypted upon receipt Encryption of data in transit changes your NFS client setup. When you inspect your actively mounted file systems, you see one mounted to 127.0.0.1, or localhost, as in the following example. ``` $ mount | column -t 127.0.0.1:/ on /home/ec2-user/s3files type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=20127,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1) ``` You mount your file system using the mount helper, which always encrypts data in transit using TLS. Therefore, while mounting, your NFS client is reconfigured to mount to a local port. # How S3 Files works with IAM This page describes how AWS Identity and Access Management (IAM) works with S3 Files and how you can use IAM policies to control access to your file systems. S3 Files uses IAM for two distinct types of access control: + **API access** — Controls who can create, manage, and delete S3 Files resources such as file systems, mount targets, and access points. You control this access using identity-based policies attached to IAM users, groups, or roles. + **Client access** — Controls what clients (your mounted compute resources) can do with the file system once they connect, such as reading, writing, or accessing files as the root user. You control this access using a combination of resource-based policies, identity-based policies, access points, and POSIX permissions. Using IAM, you can permit clients to perform specific actions on a file system, including read-only, write, and root access. An "allow" permission on an action in either an IAM identity policy or a file system resource policy allows access for that action. The permission does not need to be granted in both an identity and a resource policy. Your S3 bucket policies on your linked S3 bucket also govern access from your compute resource and your file system to your S3 bucket. You must also make sure that the bucket policies of your source bucket don't deny access from your compute resource or file system. For more details, see [Bucket policies for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html). ## Identity-based policies Identity-based policies are JSON policies that you attach to IAM users, groups, or roles. You can provide these permissions by writing custom policies or by attaching an AWS managed policy. For more information about available managed policies for both API access and client access, see [AWS managed policies for Amazon S3 Files](s3-files-security-iam-awsmanpol.md). S3 Files also optimizes read performance by allowing clients to read file data directly from the source S3 bucket. When you mount an S3 file system on your compute resource, you must add an inline policy to the IAM role of your compute resource which grants permissions to read objects from the specified S3 bucket. The mount helper uses these permissions to read the S3 data. For more details on this policy, see [IAM role for attaching your file system to AWS compute resources](s3-files-prereq-policies.md#s3-files-prereq-iam-compute-role). ## Resource-based policies A file system policy is an IAM resource-based policy that you attach directly to a file system to control client access. You can use file system policies to grant or deny permissions for clients to perform operations such as mounting, writing, and root access. A file system either has an empty (default) file system policy or exactly one explicit policy. S3 file system policies have a 20,000 character limit. For information on creating and managing file system policies, see [Creating file system policies](s3-files-file-system-policies-creating.md). ## S3 Files actions for clients You can specify the following actions in a file system policy to control client access: | Action | Description | | --- | --- | | s3files:ClientMount | Provides read-only access to a file system. | | s3files:ClientWrite | Provides write permissions on a file system. | | s3files:ClientRootAccess | Provides use of the root user when accessing a file system. | ## S3 Files condition keys for clients You can use the following condition keys in the `Condition` element of a file system policy to further refine access control: | Condition key | Description | Operator | | --- | --- | --- | | s3files:AccessPointArn | ARN of the S3 Files access point to which the client is connecting. | String | ## File system policy examples ### Example: Grant read-only access The following file system policy grants only `ClientMount` (read-only) permissions to the `ReadOnly` IAM role. Replace *111122223333* with your AWS account ID. ``` { "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ReadOnly" }, "Action": [ "s3files:ClientMount" ] } ] } ``` ### Example: Grant access to an S3 Files access point The following file system policy uses a condition element to grant a specific access point full access to the file system when mounting via the access point specified. Replace the access point ARN and account ID with your values. For more information, see [Creating access points for an S3 file system](s3-files-access-points-creating.md). ``` { "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::555555555555:role/S3FilesAccessPointFullAccess" }, "Action": [ "s3files:Client*" ], "Condition": { "StringEquals": { "s3files:AccessPointArn": "arn:partition:s3files:region:account-id:file-system/fs-1234567890/access-point/fsap-0987654321" } } } ] } ``` ## POSIX permissions After IAM authorization succeeds, S3 Files enforces standard POSIX (Unix-style) permissions at the file and directory level. POSIX permissions control access based on the user ID (UID), group ID (GID), and permission bits (read, write, execute) associated with each file and directory. Access points can enforce a specific POSIX user identity for all requests, simplifying access management for shared datasets. For more information, see [Creating access points for an S3 file system](s3-files-access-points-creating.md). ## Security groups Security groups act as a network-level firewall that controls traffic between your compute resources and the file system's mount targets. For details on configuring security groups to get started on S3 Files, see [Security groups](s3-files-prereq-policies.md#s3-files-prereq-security-groups). # AWS managed policies for Amazon S3 Files An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: AmazonS3FilesFullAccess You can attach the `AmazonS3FilesFullAccess` policy to your IAM identities. This policy grants full access to Amazon S3 Files, including permissions to create and manage file systems, mount targets, and access points. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesFullAccess.html) in the AWS Managed Policy Reference. ## AWS managed policy: AmazonS3FilesReadOnlyAccess You can attach the `AmazonS3FilesReadOnlyAccess` policy to your IAM identities. This policy grants read-only access to Amazon S3 Files, including permissions to view file systems, mount targets, access points, and related configurations. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesReadOnlyAccess.html) in the AWS Managed Policy Reference. ## AWS managed policy: AmazonS3FilesClientFullAccess You can attach the `AmazonS3FilesClientFullAccess` policy to your IAM identities. This policy grants full client access to S3 Files file systems, including the ability to mount, read, write, and access files as the root user. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesClientFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesClientFullAccess.html) in the AWS Managed Policy Reference. ## AWS managed policy: AmazonS3FilesClientReadWriteAccess You can attach the `AmazonS3FilesClientReadWriteAccess` policy to your IAM identities. This policy grants read and write client access to S3 Files file systems, including the ability to mount, read, and write. This policy does not grant root access. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesClientReadWriteAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesClientReadWriteAccess.html) in the AWS Managed Policy Reference. ## AWS managed policy: AmazonS3FilesClientReadOnlyAccess You can attach the `AmazonS3FilesClientReadOnlyAccess` policy to your IAM identities. This policy grants read-only client access to S3 Files file systems, including the ability to mount and read from the file system. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesClientReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesClientReadOnlyAccess.html) in the AWS Managed Policy Reference. ## AWS managed policy: AmazonS3FilesCSIDriverPolicy You can attach the `AmazonS3FilesCSIDriverPolicy` policy to your IAM identities. This policy grants permissions for the Amazon EFS Container Storage Interface (CSI) driver to manage S3 Files access points on behalf of Amazon EKS clusters. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesCSIDriverPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesCSIDriverPolicy.html) in the AWS Managed Policy Reference. ## AWS managed policy: AmazonElasticFileSystemUtils You can attach the `AmazonElasticFileSystemUtils` policy to your IAM identities. This policy grants permissions for the S3 Files client utilities (amazon-efs-utils) to perform operations such as describing mount targets, publishing CloudWatch metrics and logs, and communicating with AWS Systems Manager. For more information about this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonElasticFileSystemUtils.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonElasticFileSystemUtils.html) in the AWS Managed Policy Reference. ## Amazon S3 Files updates to AWS managed policies View details about updates to AWS managed policies for Amazon S3 Files since S3 Files began tracking these changes. | Change | Description | Date | | --- | --- | --- | | `AmazonElasticFileSystemUtils` — Updated | Added Amazon CloudWatch PutMetricData permissions to support publishing client connectivity metrics. | April 7, 2026 | | `AmazonS3FilesCSIDriverPolicy` — Added | New managed policy that grants permissions for the Amazon EFS CSI driver to manage S3 Files access points on behalf of Amazon EKS clusters. | April 7, 2026 | | `AmazonS3FilesClientReadOnlyAccess` — Added | New managed policy that grants read-only client access to S3 Files file systems. | April 7, 2026 | | `AmazonS3FilesClientReadWriteAccess` — Added | New managed policy that grants read and write client access to S3 Files file systems. | April 7, 2026 | | `AmazonS3FilesClientFullAccess` — Added | New managed policy that grants full client access to S3 Files file systems, including root access. | April 7, 2026 | | `AmazonS3FilesReadOnlyAccess` — Added | New managed policy that grants read-only access to S3 Files resources. | April 7, 2026 | | `AmazonS3FilesFullAccess` — Added | New managed policy that grants full access to S3 Files resources. | April 7, 2026 | | S3 Files started tracking changes | Amazon S3 Files started tracking changes for its AWS managed policies. | April 7, 2026 |