S3 - consider blocking public access for the S3 access points

This FinOps policy requires every Amazon S3 access point to be created with all four S3 Block Public Access settings enabled. Amazon S3 does not support changing an access point's block public access configuration after it has been created, so an access point created with any setting disabled stays exposed for its entire lifecycle unless it is deleted and recreated. Apply this policy to every aws_s3_access_point resource in Terraform, independent of whether the underlying bucket is expected to hold sensitive data.

Why This Policy Matters

How It Helps Reduce Cloud Costs

This policy is primarily a security control, not a direct billing lever. Its cost impact comes from what it prevents, not what it saves on a monthly invoice.

An S3 access point with any block public access setting disabled can expose objects in the underlying bucket to the public internet, subject to the access point and bucket policies. When that happens, the real cost shows up later: incident response time, forensic review, unplanned data-transfer charges from unauthorized retrieval, and the engineering hours spent auditing every other access point in the account to confirm the exposure was isolated.

Treating access point creation as a security gate is cheaper than treating a public-access finding as an incident. This is a prevention-first policy, and its savings are avoided costs rather than a recurring line-item reduction.

Potential Savings

Because Amazon S3 access points cannot have their block public access settings changed after creation, the only way to correct a non-compliant access point is to recreate it, which means the cost of getting this wrong compounds the longer it goes unnoticed.

Teams that catch a missing block public access setting at the pull request stage avoid the larger cost of an after-the-fact remediation: identifying every object potentially exposed, rotating any credentials that touched the access point, and documenting the incident for compliance. Order-of-magnitude, a single exposure review across a large bucket can consume many engineer-hours that a five-minute Terraform review would have avoided entirely.

Teams that enforce this policy at PR time typically spend zero incremental engineering hours on this class of issue after rollout, since the check runs automatically on every change to an aws_s3_access_point resource.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an access point created with one block public access setting disabled, and the corrected configuration with all four enabled.

Non-compliant configuration: block public access partially disabled

resource "aws_s3_bucket" "reports" {
  bucket = "topco-quarterly-reports"
}

resource "aws_s3_access_point" "reports" {
  bucket = aws_s3_bucket.reports.id
  name   = "reports-access-point"

  public_access_block_configuration {
    block_public_acls       = true
    block_public_policy     = false
    ignore_public_acls      = true
    restrict_public_buckets = false
  }
}

resource "aws_s3_bucket" "reports" {
  bucket = "topco-quarterly-reports"
}

resource "aws_s3_access_point" "reports" {
  bucket = aws_s3_bucket.reports.id
  name   = "reports-access-point"

  public_access_block_configuration {
    block_public_acls       = true
    block_public_policy     = false
    ignore_public_acls      = true
    restrict_public_buckets = false
  }
}

resource "aws_s3_bucket" "reports" {
  bucket = "topco-quarterly-reports"
}

resource "aws_s3_access_point" "reports" {
  bucket = aws_s3_bucket.reports.id
  name   = "reports-access-point"

  public_access_block_configuration {
    block_public_acls       = true
    block_public_policy     = false
    ignore_public_acls      = true
    restrict_public_buckets = false
  }
}

Setting block_public_policy and restrict_public_buckets to false allows a bucket or access point policy that grants public access to actually take effect through this access point. This is a common source of accidental public exposure, especially when a policy is copied from another access point without review. Because this configuration cannot be edited later, the exposure persists until someone notices and recreates the resource.

Compliant configuration: all four settings enabled

resource "aws_s3_bucket" "reports" {
  bucket = "topco-quarterly-reports"
}

resource "aws_s3_access_point" "reports" {
  bucket = aws_s3_bucket.reports.id
  name   = "reports-access-point"

  public_access_block_configuration {
    block_public_acls       = true
    block_public_policy     = true
    ignore_public_acls      = true
    restrict_public_buckets = true
  }
}

resource "aws_s3_bucket" "reports" {
  bucket = "topco-quarterly-reports"
}

resource "aws_s3_access_point" "reports" {
  bucket = aws_s3_bucket.reports.id
  name   = "reports-access-point"

  public_access_block_configuration {
    block_public_acls       = true
    block_public_policy     = true
    ignore_public_acls      = true
    restrict_public_buckets = true
  }
}

resource "aws_s3_bucket" "reports" {
  bucket = "topco-quarterly-reports"
}

resource "aws_s3_access_point" "reports" {
  bucket = aws_s3_bucket.reports.id
  name   = "reports-access-point"

  public_access_block_configuration {
    block_public_acls       = true
    block_public_policy     = true
    ignore_public_acls      = true
    restrict_public_buckets = true
  }
}

This configuration blocks any public ACL or bucket/access point policy from granting public access through this access point, regardless of what the underlying bucket policy allows. Infracost flags any aws_s3_access_point resource where one or more of these four attributes is set to false, so this gets caught in the pull request rather than after the access point is live.

Step-by-Step Fix Instructions

1. List every aws_s3_access_point resource in Terraform state and inspect its public_access_block_configuration block.

2. Flag any access point where block_public_acls, block_public_policy, ignore_public_acls, or restrict_public_buckets is false, or where the block is missing attributes entirely.

3. Because these settings cannot be updated in place, plan a replacement access point with all four settings set to true.

4. Update any application or service configuration that references the access point ARN or alias to point to the new access point.

5. Run terraform plan to confirm the change creates a new access point rather than attempting an in-place update, then apply it.

6. Delete the old, non-compliant access point once traffic has fully moved to the replacement.

7. Add Infracost to CI/CD so any future aws_s3_access_point resource with a disabled block public access setting is flagged in the pull request before merge.

Best Practices

• Set public_access_block_configuration explicitly in every shared Terraform module that creates an aws_s3_access_point, rather than leaving individual attributes to be set per environment.

• Require all four settings to be true by default in the module, and treat any request to disable one as an exception that needs a documented reason.

• This policy does not apply to access points attached to a volume on an Amazon FSx file system; AWS does not allow disabling any block public access setting on those access points regardless of configuration.

• Review existing access points on a recurring basis using AWS Security Hub control S3.19 or an equivalent Config rule, since new access points can be created outside of the reviewed Terraform workflow.

Tools and Scripts

This policy check is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it evaluates aws_s3_access_point resources introduced or modified in a pull request and surfaces a finding in the PR comment whenever public_access_block_configuration has one or more attributes set to false, before the code merges.

This gives platform teams a pre-creation signal instead of discovering an exposed access point after a Security Hub finding or an audit. Infracost enables teams to track how many access points are created against this policy over time, which supports burning down existing exceptions and reporting progress to engineering leadership.

To check an existing access point's configuration using the AWS CLI:

aws s3control get-access-point --account-id <account-id> --name

aws s3control get-access-point --account-id <account-id> --name

aws s3control get-access-point --account-id <account-id> --name

The PublicAccessBlockConfiguration block in the response shows the current value of all four settings.

Examples of Impact

Illustrative example: a copied policy re-enables public access. A platform team creates a new access point for a reporting bucket by copying an existing Terraform module, but the module has restrict_public_buckets set to false for an older use case that no longer applies. The new access point inherits that setting. A subsequent bucket policy change intended for a different access point unintentionally grants broader access than expected, and because the setting cannot be changed after creation, the team has to recreate the access point to close the gap.

Illustrative example: catching the issue in review. A developer opens a pull request that adds an aws_s3_access_pointresource with block_public_policy left unset in one environment's overrides. Infracost flags the missing setting in the PR comment. The reviewer requests the change before merge, and the access point is created correctly the first time, avoiding a future recreation.

(These are illustrative, composite scenarios, not specific customer accounts.)

Considerations and Caveats

• Access point settings are additive, not a replacement: Amazon S3 evaluates the access point's block public access settings alongside the underlying bucket's and the account's settings, and applies whichever combination is most restrictive.

• Immutable after creation: Amazon S3 does not support changing an access point's block public access configuration after creation. Any correction requires deleting and recreating the access point.

• FSx-attached access points: Access points attached to a volume on an Amazon FSx file system cannot have any block public access setting disabled, regardless of configuration.

• Multi-Region Access Points are separate: S3 Multi-Region Access Points have their own similarly immutable block public access settings, but they are a distinct resource type from a standard S3 access point and outside the scope of this specific policy.

• Not a substitute for bucket-level review: This policy addresses access point configuration only. It does not replace reviewing the underlying bucket's own block public access settings and bucket policy.

Related Policies and Concepts

• Storage Account - consider disabling public network access: another Object Storage-group FinOps policy in Infracost's library that closes off public network exposure at creation time, this time for Azure Storage Accounts rather than S3 access points.

• EC2 - consider disabling associate public IP address in launch templates: a Compute-group policy that applies the same discipline of removing public exposure by default, at the launch template stage rather than the storage layer.

• EC2 - require Instance Metadata Service Version 2 (IMDSv2): a related Compute-group security hardening policy that, like this one, is enforced at resource-creation time rather than corrected after deployment.

• "How to Enforce Cloud Cost Policies in Your CI/CD Pipeline": a planned Infracost resource article covering the broader workflow of catching policy violations like this one at the pull request stage, before they reach production.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. Infracost evaluates aws_s3_access_point resources in pull requests and surfaces a finding whenever public_access_block_configuration has one or more settings disabled, so the team can confirm it before merge. This check is available in the free trial and all paid plans.

Can this policy be customized?

Yes. Teams can adjust the policy's scope in Infracost, for example limiting the check to specific projects or access point naming patterns, rather than relying on the default configuration.

Does Infracost automatically fix violations?

No. Infracost identifies and reports an aws_s3_access_point resource with a disabled block public access setting in a pull request. Recreating the access point with all four settings enabled is a change the team makes and applies manually.

Is this policy cloud-agnostic?

No. This specific policy targets Amazon S3 access points and the aws Terraform provider. Other cloud providers have their own equivalent public-access controls, such as Azure Storage Account network access settings, but the resource and attribute names differ.

How often should I review S3 access point compliance?

Teams running Infracost in CI/CD get a check on every pull request that touches an aws_s3_access_point resource. For access points already in place, review AWS Security Hub control S3.19 or an equivalent Config rule on a recurring basis, monthly is a reasonable cadence for most teams.

Can an S3 access point's block public access settings be changed after it's created?

No. Amazon S3 does not support modifying an access point's block public access configuration after creation. The only way to change it is to delete the access point and create a new one with the correct settings.