S3 Permissions

AWS S3 Security

~ Last updated on : ~ jayendrapatil

AWS S3 Security

📌 Last Updated: June 2026. This post reflects the latest S3 security features including default SSE-S3 encryption, SSE-C disabled by default (April 2026), S3 Access Grants, ABAC for S3 buckets, Resource Control Policies (RCPs), and DSSE-KMS dual-layer encryption.

  • AWS S3 Security is a shared responsibility between AWS and the Customer
  • S3 is a fully managed service that is protected by the AWS global network security procedures
  • AWS handles basic security tasks like guest operating system (OS) and database patching, firewall configuration, and disaster recovery.
  • Security and compliance of S3 are assessed by third-party auditors as part of multiple AWS compliance programs including SOC, PCI DSS, HIPAA, etc.
  • S3 provides several other features to handle security, which are the customers’ responsibility.
  • S3 Encryption supports both data at rest and data in transit encryption.
    • Data in transit encryption can be provided by enabling communication via SSL/TLS or using client-side encryption
    • Data at rest encryption can be provided using Server Side or Client Side encryption
    • All new objects are automatically encrypted with SSE-S3 by default (since January 2023)
    • SSE-C is disabled by default on all new general purpose buckets (since April 2026)
  • S3 permissions can be handled using
    • IAM User Policies
    • Resource-based policies which include Bucket policies (ACLs are now disabled by default)
    • S3 Access Points
    • S3 Access Grants – scalable access control mapping corporate identities to S3 data
    • Attribute-Based Access Control (ABAC) – tag-based authorization for S3 buckets (Nov 2025)
  • S3 Object Lock helps to store objects using a WORM model and can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
  • S3 Access Points simplify data access for any AWS service or customer application that stores data in S3.
  • S3 Versioning with MFA Delete can be enabled on a bucket to ensure that data in the bucket cannot be accidentally overwritten or deleted.
  • S3 Block Public Access provides controls across an entire AWS Account or at the individual S3 bucket level to ensure that objects never have public access, now and in the future.
  • S3 Access Analyzer monitors the access policies, ensuring that the policies provide only the intended access to your S3 resources.
  • S3 Object Ownership – by default set to Bucket owner enforced, disabling ACLs on all new buckets.
  • Resource Control Policies (RCPs) – centrally restrict external access to S3 resources across an organization (Nov 2024).

S3 Encryption

  • S3 allows the protection of data in transit by enabling communication via SSL/TLS or using client-side encryption
  • All new objects uploaded to S3 are automatically encrypted at rest with SSE-S3 by default (since January 5, 2023). This applies to all buckets at no additional cost.
  • SSE-C (Server-Side Encryption with Customer-Provided Keys) is disabled by default on all new general purpose buckets since April 2026. Applications that need SSE-C must explicitly enable it using the PutBucketEncryption API after bucket creation.
  • S3 provides data-at-rest encryption using
    • Server-Side Encryption: S3 handles the encryption
      • SSE-S3
        • S3 handles the encryption and decryption using S3 managed keys
        • This is now the base level of encryption for every bucket in S3 (default)
      • SSE-KMS
        • S3 handles the encryption and decryption using keys managed through AWS KMS.
        • Provides additional audit trail via AWS CloudTrail for key usage
      • DSSE-KMS (Dual-Layer Server-Side Encryption)
        • Applies two layers of encryption using AWS KMS keys
        • Even if one encryption layer were compromised, data remains protected by the second layer
        • Designed for highly regulated workloads requiring CNSSP 15 compliance
        • Higher cost due to increased processing overhead and additional KMS API calls
      • SSE-C
        • S3 handles the encryption and decryption using keys managed and provided by the Customer.
        • Disabled by default on new buckets since April 2026 — must be explicitly enabled via PutBucketEncryption API
        • Most modern use cases prefer SSE-S3 or SSE-KMS for greater flexibility
    • Client Side Encryption: Customer handles the encryption
      • CSE-KMS
        • Customer handles the encryption and decryption using keys managed through AWS KMS.
      • Client-side Master Key
        • Customer handles the encryption and decryption using keys managed by them.

S3 Permissions

Refer blog post @ S3 Permissions

S3 Object Ownership

  • S3 Object Ownership is a bucket-level setting to control ownership of objects uploaded to a bucket and to disable or enable ACLs.
  • By default, Object Ownership is set to Bucket owner enforced, and all ACLs are disabled.
  • When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access exclusively using access-management policies.
  • A majority of modern use cases in S3 no longer require the use of ACLs.
  • Object Ownership has three settings:
    • Bucket owner enforced (default) – ACLs are disabled. The bucket owner automatically owns and has full control over every object. Policies define access control.
    • Bucket owner preferred – The bucket owner owns new objects written by other accounts if uploaded with the bucket-owner-full-control canned ACL.
    • Object writer – The uploading account owns the object. ACLs are enabled.
  • With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded them.

S3 Object Lock

  • S3 Object Lock helps to store objects using a write-once-read-many (WORM) model.
  • can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
  • can help meet regulatory requirements that require WORM storage or add an extra layer of protection against object changes and deletion.
  • can be enabled only for new buckets and works only in versioned buckets.
  • provides two retention modes that apply different levels of protection to the objects
    • Governance mode
      • Users can’t overwrite or delete an object version or alter its lock settings unless they have special permissions.
      • Objects can be protected from being deleted by most users, but some users can be granted permission to alter the retention settings or delete the object if necessary.
      • Can be used to test retention-period settings before creating a compliance-mode retention period.
    • Compliance mode
      • A protected object version can’t be overwritten or deleted by any user, including the root user in the AWS account.
      • Object retention mode can’t be changed, and its retention period can’t be shortened.
      • Object versions can’t be overwritten or deleted for the duration of the retention period.
  • Legal Hold
    • Provides the same protection as a retention period, but has no expiration date.
    • Remains in place until explicitly removed.
    • Can be applied to any object in an Object Lock-enabled bucket, whether or not that object has a retention period.
    • Requires the s3:PutObjectLegalHold permission to add or remove.

S3 Access Points

  • S3 access points simplify data access for any AWS service or customer application that stores data in S3.
  • Access points are named network endpoints that are attached to buckets and can be used to perform S3 object operations, such as GetObject and PutObject.
  • Each access point has distinct permissions and network controls that S3 applies for any request that is made through that access point.
  • Each access point enforces a customized access point policy that works in conjunction with the bucket policy, attached to the underlying bucket.
  • An access point can be configured to accept requests only from a VPC to restrict S3 data access to a private network.
  • Custom block public access settings can be configured for each access point.
  • S3 Access Points now support tags for ABAC (Aug 2025), enabling tag-based permissions for access points.
  • S3 Multi-Region Access Points provide a global endpoint for applications to fulfill requests from S3 buckets in multiple AWS Regions.
    • Uses AWS Global Accelerator for intelligent routing to the nearest bucket
    • Supports failover controls for active-passive or active-active configurations
    • Does not support anonymous requests

S3 Access Grants

  • S3 Access Grants is a scalable access control solution that maps identities to S3 data permissions.
  • Acts as a credential vendor — users request credentials from S3 Access Grants, which evaluates grants and vends temporary, least-privilege access credentials.
  • Supports mapping identities from corporate directories such as Microsoft Entra ID (formerly Azure AD), Okta, and other IdPs via AWS IAM Identity Center.
  • Supports up to 100,000 grants per Region per account.
  • Ideal for complex access control requirements:
    • Bucket policy size limit (20 KB) exceeded
    • Human identities from external IdPs need S3 access for analytics and big data
    • Cross-account access without frequent IAM policy updates
    • Object-level access control for unstructured data
  • Integrates with AWS machine learning and analytics services including Amazon SageMaker, Amazon Redshift, and AWS Glue.
  • Simplifies authentication when using both IAM and Identity Provider permissions (March 2025).

S3 Attribute-Based Access Control (ABAC)

  • Launched November 2025 – Tag-based authorization for S3 general purpose buckets.
  • Enables automatically managing permissions for users and roles by controlling data access through tags on S3 buckets.
  • Instead of managing permissions individually, use tag-based IAM or bucket policies to grant or deny access based on matching tags between principals and buckets.
  • Makes it easy to grant S3 access based on project, team, cost center, data classification, or other bucket attributes instead of bucket names.
  • ABAC must be explicitly enabled on each S3 bucket using the PutBucketAbac API.
  • Tag-based condition keys work in AWS Organizations policies, IAM policies, and S3 bucket policies.
  • Can enforce tagging requirements at bucket creation using SCPs or IAM policies with aws:TagKeys and aws:RequestTag condition keys.
  • Same tags can serve dual purpose: access control (ABAC) and cost allocation.
  • Available through Console, API, SDKs, CLI, and CloudFormation at no additional cost.
  • Also supported on S3 directory buckets, S3 access points, and S3 tables buckets.

S3 VPC Gateway Endpoint

  • A VPC endpoint enables connections between a VPC and supported services, without requiring that you use an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
  • VPC is not exposed to the public internet.
  • A Gateway Endpoint is a gateway that is a target for a route in your route table used for traffic destined to either S3.

S3 Block Public Access

  • S3 Block Public Access provides controls across an entire AWS Account or at the individual S3 bucket level to ensure that objects never have public access, now and in the future.
  • S3 Block Public Access provides settings for access points, buckets, and accounts to help manage public access to S3 resources.
  • By default, new buckets, access points, and objects don’t allow public access. However, users can modify bucket policies, access point policies, or object permissions to allow public access.
  • S3 Block Public Access settings override these policies and permissions so that public access to these resources can be limited.
  • S3 Block Public Access allows account administrators and bucket owners to easily set up centralized controls to limit public access to their S3 resources that are enforced regardless of how the resources are created.
  • S3 doesn’t support block public access settings on a per-object basis.
  • S3 Block Public Access settings when applied to an account apply to all AWS Regions globally.

Resource Control Policies (RCPs)

  • Launched November 2024 – A new type of authorization policy in AWS Organizations for centrally restricting access to AWS resources.
  • RCPs work alongside Service Control Policies (SCPs) to establish permissions guardrails across multiple accounts in an organization.
  • Can enforce that S3 buckets in your accounts are only accessible by principals belonging to your organization.
  • Resource-based — they restrict what actions can be taken on resources regardless of the identity-based permissions granted.
  • Do not grant access — they only set the maximum available permissions on resources.
  • Key S3 use case: Restrict access to S3 buckets so no principal outside the organization can access them, regardless of individual S3 bucket policies.
  • Available in AWS GovCloud (US) Regions since May 2025.
  • Supported by AWS Control Tower with configurable managed controls.

S3 Access Analyzer

  • S3 Access Analyzer (part of IAM Access Analyzer) monitors the access policies, ensuring that the policies provide only the intended access to your S3 resources.
  • Evaluates bucket access policies and enables you to discover and swiftly remediate buckets with potentially unintended access.
  • External Access Findings — identifies resources accessible by principals outside your account or organization.
  • Internal Access Findings (June 2025) — identifies who within your AWS organization has access to critical resources including S3 buckets.
    • Monitors selected resources daily and surfaces findings in a unified dashboard
    • Combines internal and external access findings for a 360-degree view
  • Unused Access Analysis — identifies unused roles, access keys, and permissions to help achieve least privilege.
  • Custom Policy Checks — validate policies before deployment, including:
    • Check No Public Access (Jul 2024)
    • Check Access Not Granted
    • Guided revocation for unused access (Jun 2024)
  • Can be integrated into CI/CD pipelines for automated policy reviews.

S3 Security Best Practices

S3 Preventative Security Best Practices

  • Ensure S3 buckets use the correct policies and are not publicly accessible
    • Use S3 block public access
    • Keep ACLs disabled (Bucket owner enforced) unless specifically needed
    • Use AWS Trusted Advisor to inspect the S3 implementation.
    • Use Resource Control Policies (RCPs) to restrict access to organization principals only
  • Implement least privilege access
    • Use S3 Access Grants for complex identity-based access at scale
    • Use ABAC for tag-based authorization to simplify policy management
    • Use IAM Access Analyzer to identify and remediate overly permissive policies
  • Use IAM roles for applications and AWS services that require S3 access
  • Enable Multi-factor authentication (MFA) Delete to help prevent accidental bucket deletions
  • Consider Data at Rest Encryption
    • SSE-S3 is now applied by default to all new objects
    • Use SSE-KMS for additional audit trails and key management
    • Use DSSE-KMS for compliance requiring two independent layers of encryption
  • Enforce Data in Transit Encryption
  • Consider S3 Object Lock to store objects using a “Write Once Read Many” (WORM) model.
  • Enable versioning to easily recover from both unintended user actions and application failures.
  • Consider S3 Cross-Region replication
  • Consider VPC endpoints for S3 access to provide private S3 connectivity and help prevent traffic from potentially traversing the open internet.
  • Secure presigned URLs with short expiration times, IP restrictions, and scoped IAM permissions.

S3 Monitoring and Auditing Best Practices

  • Identify and Audit all S3 buckets to have visibility of all the S3 resources to assess their security posture and take action on potential areas of weakness.
  • Implement monitoring using AWS monitoring tools
  • Enable S3 server access logging, which provides detailed records of the requests that are made to a bucket useful for security and access audits
  • Use AWS CloudTrail, which provides a record of actions taken by a user, a role, or an AWS service in S3.
  • Enable AWS Config, which enables you to assess, audit, and evaluate the configurations of the AWS resources
  • Use Amazon Macie with S3 to automatically discover, classify, and protect sensitive data in AWS.
    • Automated sensitive data discovery continuously samples and analyzes objects
    • Provides sensitivity scores for each bucket
    • Builds interactive data maps showing sensitive data distribution across accounts
  • Use IAM Access Analyzer to monitor both external and internal access to S3 resources
  • Monitor AWS security advisories to regularly check security advisories posted in Trusted Advisor for the AWS account.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company needs to ensure all objects stored in their S3 buckets are encrypted with a dual-layer encryption mechanism for CNSSP 15 compliance. Which encryption option should they use?
    1. SSE-S3
    2. SSE-KMS
    3. DSSE-KMS
    4. SSE-C
    Show Answer

    Answer: c. DSSE-KMS – Dual-Layer Server-Side Encryption with AWS KMS keys provides two independent layers of encryption for compliance requirements like CNSSP 15.

  2. An organization wants to grant access to S3 buckets based on team membership from their Microsoft Entra ID directory, supporting up to 50,000 data scientists. Which S3 feature is most appropriate?
    1. S3 Bucket Policies
    2. S3 Access Points
    3. S3 Access Grants
    4. S3 ACLs
    Show Answer

    Answer: c. S3 Access Grants – Maps corporate directory identities to S3 data permissions at scale (up to 100,000 grants per Region), ideal for large organizations with external IdPs.

  3. A security engineer needs to ensure that no S3 buckets in any account of the organization can be accessed by principals outside the organization, regardless of individual bucket policies. Which feature should they implement?
    1. S3 Block Public Access
    2. Service Control Policies (SCPs)
    3. Resource Control Policies (RCPs)
    4. S3 Bucket Policies with Deny statements
    Show Answer

    Answer: c. Resource Control Policies (RCPs) – RCPs centrally restrict external access to AWS resources across an organization, enforcing that S3 buckets are accessible only by principals belonging to the organization.

  4. An administrator wants to simplify S3 bucket access management by automatically granting access based on environment tags (dev, staging, prod) rather than maintaining individual bucket ARNs in policies. What feature should they use?
    1. S3 Access Grants
    2. S3 ABAC (Attribute-Based Access Control)
    3. S3 Access Points
    4. AWS Organizations SCPs
    Show Answer

    Answer: b. S3 ABAC – Enables tag-based authorization for S3 buckets, allowing access decisions based on matching tags between principals and buckets rather than individual bucket names.

  5. A company creates a new S3 bucket and attempts to upload objects using SSE-C encryption but receives an AccessDenied error. What is the most likely cause? (Choose the best answer)
    1. The IAM user lacks encryption permissions
    2. SSE-C is disabled by default on new buckets since April 2026
    3. The bucket policy blocks encryption operations
    4. KMS key permissions are missing
    Show Answer

    Answer: b – Since April 2026, SSE-C is disabled by default on all new general purpose buckets. Applications must explicitly enable SSE-C via the PutBucketEncryption API.

  6. Which IAM Access Analyzer feature, launched in June 2025, helps security teams identify who within their AWS organization has access to critical resources like S3 buckets?
    1. External Access Findings
    2. Internal Access Findings
    3. Unused Access Analysis
    4. Custom Policy Checks
    Show Answer

    Answer: b. Internal Access Findings – Monitors resources daily and provides a unified dashboard combining internal and external access findings for a 360-degree view.

References

AWS S3 Permissions

~ Last updated on : ~ jayendrapatil ~ 20 Comments

AWS S3 Permissions

  • By default, all S3 buckets, objects, and related subresources are private.
  • Only the Resource owner, the AWS account (not the user) that creates the resource, can access the resource.
  • Resource owner can be
    • AWS account that creates the bucket or object owns those resources
    • If an IAM user creates the bucket or object, the AWS account of the IAM user owns the resource
    • If the bucket owner grants cross-account permissions to other AWS account users to upload objects to the buckets, the objects are owned by the AWS account of the user who uploaded the object and not the bucket owner except for the following conditions
      • Bucket owner can deny access to the object, as it is still the bucket owner who pays for the object
      • Bucket owner can delete or apply archival rules to the object and perform restoration
  • User is the AWS Account or the IAM user who access the resource
  • Bucket owner is the AWS account that created a bucket
  • Object owner is the AWS account that uploads the object to a bucket, not owned by the account
  • S3 permissions are classified into
    • Resource based policies and
    • User policies

S3 Object Ownership

  • S3 Object Ownership is a bucket-level setting that controls ownership of objects uploaded to the bucket and allows disabling or enabling ACLs.
  • By default (since April 2023), Object Ownership is set to Bucket owner enforced and all ACLs are disabled for all new buckets.
  • A majority of modern use cases in S3 no longer require ACLs, and AWS recommends keeping ACLs disabled.
  • With ACLs disabled, the bucket owner owns all objects and manages access exclusively using policies (IAM policies, bucket policies, access point policies).
  • Object Ownership has three settings:
    • Bucket owner enforced (default) – ACLs are disabled. The bucket owner automatically owns and has full control over every object. ACLs no longer affect permissions. The bucket uses policies exclusively for access control.
    • Bucket owner preferred – ACLs are enabled. The bucket owner owns new objects written with the bucket-owner-full-control canned ACL. Objects uploaded with other ACLs are owned by the writing account.
    • Object writer – ACLs are enabled. The AWS account that uploads an object owns it and can grant access via ACLs.
  • When ACLs are disabled (Bucket owner enforced):
    • All bucket and object ACLs are disabled, giving full access only to the bucket owner
    • The bucket owner automatically owns and has full control over every object
    • ACLs no longer affect access permissions; access control is based on IAM policies, bucket policies, VPC endpoint policies, and Organizations SCPs/RCPs
    • Requests to set or update ACLs fail, but requests to read ACLs are still supported
    • Only PUT requests that don’t specify an ACL or specify bucket-owner-full-control are accepted
  • ACLs can be re-enabled at any time by changing to another Object Ownership setting, and preexisting ACLs are restored.
  • For S3 Replication across accounts, the Bucket owner enforced setting automatically changes replica ownership to the destination bucket owner without needing the s3:ObjectOwnerOverrideToBucketOwner permission.
  • Permissions required: s3:PutBucketOwnershipControls to set, s3:GetBucketOwnershipControls to view.

S3 Block Public Access

  • S3 Block Public Access provides controls to ensure that S3 resources never have public access.
  • Since April 2023, Block Public Access is enabled by default for all newly created buckets in all AWS Regions.
  • Block Public Access can be applied at three levels:
    • Bucket level – applies to a specific bucket and its objects
    • Account level – applies to all buckets in the AWS account (current and future)
    • Organization level – centrally managed via AWS Organizations policies across all member accounts
  • Block Public Access settings override S3 permissions that allow public access, regardless of how an object is added or bucket is created.
  • Four settings are available:
    • BlockPublicAcls – blocks PUT requests that include public ACLs for buckets and objects
    • IgnorePublicAcls – ignores all public ACLs on a bucket and its objects
    • BlockPublicPolicy – rejects bucket policy changes that grant public access
    • RestrictPublicBuckets – restricts access to buckets with public policies to only AWS service principals and authorized users
  • S3 takes the most restrictive combination of bucket-level, account-level, and organization-level settings.
  • AWS recommends turning on “Block all public access” unless public access is explicitly required for specific use cases.

User Policies

  • User policies use IAM with S3 to control the type of access a user or group of users has to specific parts of an S3 bucket the AWS account owns
  • User policy is always attached to a User, Group, or a Role
  • Anonymous permissions cannot be granted
  • If an AWS account that owns a bucket wants to grant permission to users in its account, it can use either a bucket policy or a user policy

Resource-Based policies

  • Bucket policies and access control lists (ACLs) are resource-based because they are attached to the S3 resources

Screen Shot 2016-03-28 at 5.57.36 PM

Bucket Policies

  • Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
  • Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address)
  • If an AWS account that owns a bucket wants to grant permission to users in its account, it can use either a bucket policy or a user policy
  • Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner
  • Policies can either add or deny permissions across all (or a subset) of objects within a bucket
  • Only the bucket owner is allowed to associate a policy with a bucket
  • Bucket policies can cater to multiple use cases
    • Granting permissions to multiple accounts with added conditions
    • Granting read-only permission to an anonymous user
    • Limiting access to specific IP addresses
    • Restricting access to a specific HTTP referer
    • Restricting access to a specific HTTP header for e.g. to enforce encryption
    • Granting permission to a CloudFront OAI
    • Adding a bucket policy to require MFA
    • Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
    • Granting permissions for S3 inventory and Amazon S3 analytics
    • Granting permissions for S3 Storage Lens

Access Control Lists (ACLs)

  • Note: Since April 2023, ACLs are disabled by default for all newly created S3 buckets (Object Ownership set to “Bucket owner enforced”). AWS recommends keeping ACLs disabled and using bucket policies instead for the majority of use cases.
  • Each bucket and object has an ACL associated with it.
  • An ACL is a list of grants identifying grantee and permission granted
  • ACLs are used to grant basic read/write permissions on resources to other AWS accounts.
  • ACL supports limited permissions set and
    • cannot grant conditional permissions, nor can you explicitly deny permissions
    • cannot be used to grant permissions for bucket subresources
  • Permission can be granted to an AWS account by the email address or the canonical user ID (is just an obfuscated Account Id). If an email address is provided, S3 will still find the canonical user ID for the user and add it to the ACL.
  • It is Recommended to use Canonical user ID as email address would not be supported
  • Bucket ACL
    • Only recommended use case for the bucket ACL is to grant write permission to the S3 Log Delivery group to write access log objects to the bucket
    • Bucket ACL will help grant write permission on the bucket to the Log Delivery group if access log delivery is needed to the bucket
    • Only way you can grant necessary permissions to the Log Delivery group is via a bucket ACL
  • Object ACL
    • Object ACLs control only Object-level Permissions
    • Object ACL is the only way to manage permission to an object in the bucket not owned by the bucket owner i.e. If the bucket owner allows cross-account object uploads and if the object owner is different from the bucket owner, the only way for the object owner to grant permissions on the object is through Object ACL
    • If the Bucket and Object is owned by the same AWS account, Bucket policy can be used to manage the permissions
    • If the Object and User is owned by the same AWS account, User policy can be used to manage the permissions
    • With Bucket owner enforced (default), cross-account object ownership issues are eliminated as the bucket owner automatically owns all objects

S3 Access Points

  • S3 Access Points are named network endpoints attached to buckets that simplify managing data access at scale for shared datasets.
  • Each access point has its own access point policy and can enforce distinct permissions and network controls for any request made through it.
  • Access point policies work in conjunction with the underlying bucket policy.
  • A bucket can have thousands of access points per AWS Region per account, each with a policy up to 20 KB.
  • Access points can only be used to perform object operations (GetObject, PutObject, etc.), not bucket operations like deleting buckets or configuring replication.
  • Network Controls:
    • Access points can be configured to accept requests only from a specific Virtual Private Cloud (VPC), restricting S3 data access to a private network.
    • Custom Block Public Access settings can be configured for each access point independently.
  • Use Cases:
    • Managing access for shared datasets (data lakes, media archives, user-generated content)
    • Creating individualized access points with permissions customized per application, team, or user
    • Simplifying complex bucket policies by distributing access rules across multiple access points
    • Restricting data access to specific VPCs for security compliance
  • S3 Multi-Region Access Points:
    • Provide a single global endpoint to access replicated datasets across multiple AWS Regions
    • Dynamically route requests via AWS Global Accelerator, reducing latency by up to 60%
    • Include failover controls for active-passive or active-active configurations
    • Allow shifting S3 data access request traffic between AWS Regions at any time
  • Access points are referenced using ARNs, access point aliases, or virtual-hosted-style URIs.

S3 Access Grants

  • S3 Access Grants (launched November 2023) provides a simplified model for defining access permissions to S3 data by prefix, bucket, or object.
  • Supports up to 100,000 grants per Region per account.
  • Grants access to both IAM principals and directly to users or groups from corporate directories (Microsoft Entra ID, Okta, Ping).
  • Key Capabilities:
    • Define direct access mappings of S3 prefixes to users and roles
    • Grant read-only, write-only, or read-write access on a per-prefix basis
    • Integrate with AWS IAM Identity Center for trusted identity propagation
    • End-user identities propagated to S3, simplifying audit via CloudTrail data events
    • Cross-account access support without frequent IAM policy updates
  • When to Use S3 Access Grants:
    • Bucket policy size limit (20 KB) is being reached
    • Granting corporate directory users/groups (Entra ID, Okta) access to S3 data for analytics
    • Cross-account access is needed without frequent policy updates
    • Data access is unstructured and object-level rather than row/column format
  • Components:
    • Access Grants Instance – container for grants, one per Region per account
    • Locations – registered S3 paths (default s3://, bucket, or prefix) with an IAM role
    • Grants – individual access mappings from a grantee to an S3 location with a permission level
  • Applications request temporary credentials from S3 Access Grants on behalf of the authenticated user.
  • Integrates with AWS services including Amazon SageMaker, Amazon Redshift, and AWS Glue.

S3 Request Authorization

When S3 receives a request, it must evaluate all the user policies, bucket policies, and ACLs to determine whether to authorize or deny the request.

S3 evaluates the policies in 3 context

  • User context is basically the context in which S3 evaluates the User policy that the parent AWS account (context authority) attaches to the user
  • Bucket context is the context in which S3 evaluates the access policies owned by the bucket owner (context authority) to check if the bucket owner has not explicitly denied access to the resource
  • Object context is the context where S3 evaluates policies owned by the Object owner (context authority)

Analogy

  • Consider 3 Parents (AWS Account) A, B and C with Child (IAM User) AA, BA and CA respectively
  • Parent A owns a Toy box (Bucket) with Toy AAA and also allows toys (Objects) to be dropped and picked up
  • Parent A can grant permission (User Policy OR Bucket policy OR both) to his Child AA to access the Toy box and the toys
  • Parent A can grant permissions (Bucket policy) to Parent B (different AWS account) to drop toys into the toys box. Parent B can grant permissions (User policy) to his Child BA to drop Toy BAA
  • Parent B can grant permissions (Object ACL) to Parent A to access Toy BAA
  • Parent A can grant permissions (Bucket Policy) to Parent C to pick up the Toy AAA who in turn can grant permission (User Policy) to his Child CA to access the toy
  • Parent A can grant permission (through IAM Role) to Parent C to pick up the Toy BAA who in turn can grant permission (User Policy) to his Child CA to access the toy

Bucket Operation Authorization

Screen Shot 2016-03-28 at 6.35.36 AM

  1. If the requester is an IAM user, the user must have permission (User Policy) from the parent AWS account to which it belongs
  2. Amazon S3 evaluates a subset of policies owned by the parent account. This subset of policies includes the user policy that the parent account attaches to the user.
  3. If the parent also owns the resource in the request (in this case, the bucket), Amazon S3 also evaluates the corresponding resource policies (bucket policy and bucket ACL) at the same time.
  4. Requester must also have permissions (Bucket Policy or ACL) from the bucket owner to perform a specific bucket operation.
  5. Amazon S3 evaluates a subset of policies owned by the AWS account that owns the bucket. The bucket owner can grant permission by using a bucket policy or bucket ACL.
  6. Note that, if the AWS account that owns the bucket is also the parent account of an IAM user, then it can configure bucket permissions in a user policy or bucket policy or both

Object Operation Authorization

Screen Shot 2016-03-28 at 6.39.54 AM

  1. If the requester is an IAM user, the user must have permission (User Policy) from the parent AWS account to which it belongs.
  2. Amazon S3 evaluates a subset of policies owned by the parent account. This subset of policies includes the user policy that the parent attaches to the user.
  3. If the parent also owns the resource in the request (bucket, object), Amazon S3 evaluates the corresponding resource policies (bucket policy, bucket ACL, and object ACL) at the same time.
  4. If the parent AWS account owns the resource (bucket or object), it can grant resource permissions to its IAM user by using either the user policy or the resource policy.
  5. S3 evaluates policies owned by the AWS account that owns the bucket.
  6. If the AWS account that owns the object in the request is not the same as the bucket owner, in the bucket context Amazon S3 checks the policies if the bucket owner has explicitly denied access to the object.
  7. If there is an explicit deny set on the object, Amazon S3 does not authorize the request.
  8. Requester must have permissions from the object owner (Object ACL) to perform a specific object operation.
  9. Amazon S3 evaluates the object ACL.
  10. If bucket and object owners are the same, access to the object can be granted in the bucket policy, which is evaluated in the bucket context.
  11. If the owners are different, the object owners must use an object ACL to grant permissions.
  12. If the AWS account that owns the object is also the parent account to which the IAM user belongs, it can configure object permissions in a user policy, which is evaluated in the user context.

Permission Delegation

  • If an AWS account owns a resource, it can grant those permissions to another AWS account.
  • That account can then delegate those permissions, or a subset of them, to users in the account. This is referred to as permission delegation.
  • But an account that receives permissions from another account cannot delegate permission cross-account to another AWS account.
  • If the Bucket owner wants to grant permission to the Object which does not belong to it to another AWS account it cannot do it through cross-account permissions and need to define an IAM role which can be assumed by the AWS account to gain access

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which features can be used to restrict access to data in S3? Choose 2 answers
    1. Set an S3 ACL on the bucket or the object.
    2. Create a CloudFront distribution for the bucket.
    3. Set an S3 bucket policy.
    4. Enable IAM Identity Federation
    5. Use S3 Virtual Hosting
  2. Which method can be used to prevent an IP address block from accessing public objects in an S3 bucket?
    1. Create a bucket policy and apply it to the bucket
    2. Create a NACL and attach it to the VPC of the bucket
    3. Create an ACL and apply it to all objects in the bucket
    4. Modify the IAM policies of any users that would access the bucket
  3. A user has granted read/write permission of his S3 bucket using ACL. Which of the below mentioned options is a valid ID to grant permission to other AWS accounts (grantee) using ACL?
    1. IAM User ID
    2. S3 Secure ID
    3. Access ID
    4. Canonical user ID
  4. A root account owner has given full access of his S3 bucket to one of the IAM users using the bucket ACL. When the IAM user logs in to the S3 console, which actions can he perform?
    1. He can just view the content of the bucket
    2. He can do all the operations on the bucket
    3. It is not possible to give access to an IAM user using ACL
    4. The IAM user can perform all operations on the bucket using only API/SDK
  5. A root AWS account owner is trying to understand various options to set the permission to AWS S3. Which of the below mentioned options is not the right option to grant permission for S3?
    1. User Access Policy
    2. S3 Object Policy
    3. S3 Bucket Policy
    4. S3 ACL
  6. A system admin is managing buckets, objects and folders with AWS S3. Which of the below mentioned statements is true and should be taken in consideration by the sysadmin?
    1. Folders support only ACL
    2. Both the object and bucket can have an Access Policy but folder cannot have policy
    3. Folders can have a policy
    4. Both the object and bucket can have ACL but folders cannot have ACL
  7. A user has created an S3 bucket which is not publicly accessible. The bucket is having thirty objects which are also private. If the user wants to make the objects public, how can he configure this with minimal efforts?
    1. User should select all objects from the console and apply a single policy to mark them public
    2. User can write a program which programmatically makes all objects public using S3 SDK
    3. Set the AWS bucket policy which marks all objects as public
    4. Make the bucket ACL as public so it will also mark all objects as public
  8. You need to configure an Amazon S3 bucket to serve static assets for your public-facing web application. Which methods ensure that all objects uploaded to the bucket are set to public read? Choose 2 answers
    1. Set permissions on the object to public read during upload.
    2. Configure the bucket ACL to set all objects to public read.
    3. Configure the bucket policy to set all objects to public read.
    4. Use AWS Identity and Access Management roles to set the bucket to public read.
    5. Amazon S3 objects default to public read, so no action is needed.
  9. Amazon S3 doesn’t automatically give a user who creates _____ permission to perform other actions on that bucket or object.
    1. a file
    2. a bucket or object
    3. a bucket or file
    4. a object or file
  10. A root account owner is trying to understand the S3 bucket ACL. Which of the below mentioned options cannot be used to grant ACL on the object using the authorized predefined group?
    1. Authenticated user group
    2. All users group
    3. Log Delivery Group
    4. Canonical user group
  11. A user is enabling logging on a particular bucket. Which of the below mentioned options may be best suitable to allow access to the log bucket?
    1. Create an IAM policy and allow log access
    2. It is not possible to enable logging on the S3 bucket
    3. Create an IAM Role, which has access to the log bucket
    4. Provide ACL for the logging group
  12. A user is trying to configure access with S3. Which of the following options is not possible to provide access to the S3 bucket / object?
    1. Define the policy for the IAM user
    2. Define the ACL for the object
    3. Define the policy for the object
    4. Define the policy for the bucket
  13. A user is having access to objects of an S3 bucket, which is not owned by him. If he is trying to set the objects of that bucket public, which of the below mentioned options may be a right fit for this action?
    1. Make the bucket public with full access
    2. Define the policy for the bucket
    3. Provide ACL on the object
    4. Create an IAM user with permission
  14. A bucket owner has allowed another account’s IAM users to upload or access objects in his bucket. The IAM user of Account A is trying to access an object created by the IAM user of account B. What will happen in this scenario?
    1. The bucket policy may not be created as S3 will give error due to conflict of Access Rights
    2. It is not possible to give permission to multiple IAM users
    3. AWS S3 will verify proper rights given by the owner of Account A, the bucket owner as well as by the IAM user B to the object
    4. It is not possible that the IAM user of one account accesses objects of the other IAM user
  15. A company creates a new S3 bucket using default settings. What security features are automatically enabled? [Choose 2 answers]
    1. S3 Block Public Access is enabled
    2. Server-side encryption with customer-managed KMS keys
    3. ACLs are disabled (Object Ownership set to Bucket owner enforced)
    4. S3 Object Lock is enabled
    5. Cross-Region Replication is enabled
  16. A company has a shared data lake in S3 accessed by multiple teams. They want to simplify access management without complex bucket policies. Which approach is most appropriate?
    1. Create separate buckets for each team
    2. Create S3 Access Points with individualized policies per team
    3. Use S3 ACLs for each team’s objects
    4. Create one large bucket policy with all team permissions
  17. A company needs to grant corporate directory users (Microsoft Entra ID) access to specific S3 prefixes for analytics workloads without mapping each user to an IAM principal. Which S3 feature should they use?
    1. S3 Bucket Policies with IAM federation
    2. S3 Access Points
    3. S3 Access Grants
    4. S3 ACLs with canonical user IDs
  18. An organization wants to restrict S3 data access to requests originating only from within their VPC. Which feature allows creating an S3 endpoint that enforces VPC-only access?
    1. S3 Bucket Policy with VPC condition key
    2. S3 Access Point configured with VPC network origin
    3. S3 Block Public Access at account level
    4. S3 Object Ownership with Bucket owner enforced
  19. With S3 Object Ownership set to “Bucket owner enforced”, what happens when another AWS account uploads an object to the bucket?
    1. The upload fails unless the uploader specifies an ACL
    2. The uploading account retains ownership of the object
    3. The bucket owner automatically owns the object and ACLs have no effect
    4. The object is placed in a pending state until the bucket owner approves it

References