S3 Pre-Signed URLs and Access Points

A pre-signed URL is a URL that grants temporary access to a specific S3 object. It is generated by an IAM principal (user or role) that already has permissions to perform the action (GET, PUT, etc.) on the object. The URL contains cryptographic signature that proves the generator's identity and the allowed operation. Pre-signed URLs exist to solve a fundamental problem: how to give a third party (like a website visitor or a mobile app client) access to a private S3 object without embedding long-term AWS credentials in the client. Common use cases include:

The SAA-C03 exam tests your understanding of how pre-signed URLs are generated, their expiration behavior, and the security implications.

When you generate a pre-signed URL using the AWS SDK or CLI, the following happens: 1. The AWS SDK constructs a canonical request string that includes: HTTP method (GET, PUT, etc.), bucket name, object key, query parameters (including expiration timestamp), and a hash of the payload. 2. The SDK signs this request using the AWS Signature Version 4 (SigV4) process. It uses the secret access key of the IAM user or role that generated the URL. 3. The resulting signature is appended as a query parameter (X-Amz-Signature). Other query parameters include:

- X-Amz-Algorithm: Always AWS4-HMAC-SHA256. - X-Amz-Credential: The access key ID and scope (date, region, service). - X-Amz-Date: The date and time the URL was generated (UTC). - X-Amz-Expires: The time in seconds until the URL expires (default 3600, max 604800 for AWS Signature Version 4). - X-Amz-SignedHeaders: Usually 'host'. 4. When a client makes an HTTP request to the pre-signed URL, S3 recomputes the signature using the same algorithm and compares it to the provided signature. If it matches and the expiration time has not passed, S3 evaluates the underlying IAM policy of the URL generator. The URL grants access only if the generator had permission at the time of use. If the generator's permissions are revoked, the pre-signed URL becomes invalid immediately, even if it hasn't expired.

Key details:

Using AWS CLI:

aws s3 presign s3://my-bucket/my-object --expires-in 3600

This outputs a URL valid for 1 hour.

Using Python SDK (boto3):

import boto3
url = boto3.client('s3').generate_presigned_url(
    ClientMethod='get_object',
    Params={'Bucket': 'my-bucket', 'Key': 'my-object'},
    ExpiresIn=3600
)

Important: The IAM user or role generating the URL must have s3:GetObject (for GET) or s3:PutObject (for PUT) permissions on the object. The URL inherits the permissions of the generator at the time of use, not at generation time.

You can generate a pre-signed URL for PUT to allow a client to upload an object directly to S3. The client must use HTTP PUT method with the URL. The content-type and other headers must match those used during generation if they were specified. For example:

url = s3.generate_presigned_url(
    ClientMethod='put_object',
    Params={'Bucket': 'my-bucket', 'Key': 'uploaded-file.txt', 'ContentType': 'text/plain'},
    ExpiresIn=3600
)

If the client sends a different Content-Type, the request will fail with a signature mismatch.

Pre-signed URLs are not a replacement for bucket policies or ACLs. They are a temporary delegation mechanism. The underlying object can still be private. The URL is the only way to access it without permanent credentials.

An S3 Access Point is a network endpoint attached to an S3 bucket that has its own access policy and network controls. Each access point has a unique DNS name (e.g., my-access-point-123456789012.s3-access-point.us-east-1.amazonaws.com). Access points are designed to simplify managing access to shared datasets. For example, a bucket containing analytics data can have multiple access points: one for data scientists with read-only access, one for ingestion jobs with write access, and one for a specific VPC with restricted IP ranges.

Access points are especially useful when you need to enforce:

When you create an access point, S3 creates a new endpoint. The access point's policy is evaluated in addition to the bucket policy and IAM user policy. The effective permissions are the intersection of all applicable policies. This means an access point cannot grant permissions that the bucket policy denies, but it can further restrict.

Access points support:

Using AWS CLI:

aws s3control create-access-point --bucket my-bucket --name my-access-point --account-id 123456789012

To attach a policy:

aws s3control put-access-point-policy --account-id 123456789012 --name my-access-point --policy file://policy.json

Example policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/DataScientist"},
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
    }
  ]
}

Note: The resource ARN uses the access point ARN format: arn:aws:s3:region:account-id:accesspoint/access-point-name/object/*.

You can configure an access point to only accept requests from a specific VPC. This is done by setting the VpcConfiguration parameter during creation:

aws s3control create-access-point --bucket my-bucket --name vpc-only --vpc-configuration VpcId=vpc-12345678

Once set, any request that does not originate from that VPC (based on the source IP or VPC endpoint) will be denied, regardless of IAM permissions. This is enforced at the network level.

The SAA-C03 exam often presents scenarios where you need to isolate S3 access to a specific VPC. The correct answer is to create an S3 Access Point with a VPC origin restriction, combined with a bucket policy that denies all access except through that access point. Another common question involves granting different permissions to different teams using the same bucket – the solution is multiple access points with separate policies.

A healthcare company runs a patient portal that allows patients to download lab results. The results are stored as PDFs in an S3 bucket with server-side encryption. The bucket is private. The web application backend generates pre-signed URLs for each patient's specific file, with a 5-minute expiration. This ensures that only authenticated patients (after logging in) can access their own results. The pre-signed URL is generated using an IAM role that has least-privilege permissions: s3:GetObject on the specific object key pattern. The backend uses AWS Lambda to generate the URLs. The company set the expiration to 300 seconds to balance security and user experience. A common misconfiguration is setting the expiration too long (e.g., 7 days), which increases the risk of URL leakage. In production, they monitor CloudTrail for unauthorized access attempts via pre-signed URLs.

A data analytics company provides a shared S3 bucket for multiple customers. Each customer should only see their own data, which is stored under a prefix (e.g., customer1/, customer2/). The company creates an S3 Access Point for each customer. Each access point has a policy that restricts access to objects under the corresponding prefix. For example, the access point for customer1 has a policy that allows s3:GetObject on arn:aws:s3:us-east-1:123456789012:accesspoint/customer1-ap/object/customer1/*. Additionally, each access point is configured to only accept requests from the customer's specific VPC, using VPC origin. This ensures that even if credentials are compromised, access is limited to the customer's own data and network. The bucket policy denies all access except through the access points, using a condition that checks the s3:DataAccessPointArn. This setup scales to hundreds of customers without having to manage multiple buckets.