Introduction

Yes, you can restrict S3 access based on source IP address by using a bucket policy condition such as aws:SourceIp. This is a common way to allow object access only from a known office network, VPN range, or other trusted address block.

The important detail is that the IP check applies to the request Amazon S3 actually receives. If traffic is coming through CloudFront, a VPC endpoint, a proxy, or some other intermediary, the source IP seen by S3 may not be the client IP you expected.

Use aws:SourceIp in a Bucket Policy

An S3 bucket policy can allow or deny requests based on IP ranges. A simple allow policy for GetObject from one office range looks like this:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "AllowReadFromOfficeIP",
6      "Effect": "Allow",
7      "Principal": "*",
8      "Action": "s3:GetObject",
9      "Resource": "arn:aws:s3:::example-bucket/*",
10      "Condition": {
11        "IpAddress": {
12          "aws:SourceIp": "203.0.113.0/24"
13        }
14      }
15    }
16  ]
17}

This says that reads are allowed only when the request originates from that CIDR block.

Prefer Explicit Deny for Stronger Guardrails

In security-sensitive setups, many teams prefer an explicit deny rule because an explicit deny overrides allows from other policies:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "DenyOutsideTrustedIP",
6      "Effect": "Deny",
7      "Principal": "*",
8      "Action": "s3:*",
9      "Resource": [
10        "arn:aws:s3:::example-bucket",
11        "arn:aws:s3:::example-bucket/*"
12      ],
13      "Condition": {
14        "NotIpAddress": {
15          "aws:SourceIp": [
16            "203.0.113.0/24",
17            "198.51.100.25/32"
18          ]
19        }
20      }
21    }
22  ]
23}

This blocks all S3 actions unless the request comes from a trusted address range.

Apply the Rule at the Right Scope

For object downloads, include the object ARN pattern such as arn:aws:s3:::example-bucket/*. If you also want to restrict bucket-level actions such as ListBucket, include the bucket ARN itself as well.

That distinction matters because s3:ListBucket applies to the bucket resource, while s3:GetObject applies to object resources.

Understand When IP Conditions Can Surprise You

IP-based policies are simple, but they have limits.

They can be misleading when requests come through:

• CloudFront
• NAT gateways
• corporate proxies
• VPC endpoints
• private AWS service integrations

In those cases, the source IP that S3 evaluates may be the edge service or network egress point, not the end user. If you expect direct browser access from a fixed network, IP conditions are usually fine. If the architecture is more layered, test the real request path carefully.

Combine IP Conditions with Identity Controls

IP checks should usually complement identity-based access rather than replace it. A stronger setup often combines:

• IAM user or role permissions
• bucket policy conditions
• block public access settings
• optional VPC endpoint restrictions

That way, even if someone is on an allowed network, they still need the correct credentials or signed URL depending on the design.

Common Pitfalls

• Forgetting to include both bucket and object ARNs when restricting multiple S3 actions.
• Assuming S3 sees the original client IP when the request actually passes through another service first.
• Using an allow-only rule and forgetting that other policies may still grant access unless an explicit deny exists.
• Treating IP restrictions as a substitute for identity and authentication controls.

Summary

• Use aws:SourceIp in an S3 bucket policy to restrict access by IP address.
• Use explicit deny rules when you want stronger protection against accidental broader access.
• Include the correct resource ARNs for bucket-level and object-level actions.
• Test carefully if requests travel through CloudFront, proxies, or other intermediaries.
• Combine IP conditions with normal IAM and S3 security controls rather than relying on IP checks alone.