Great question—this is such a common headache when dealing with private S3 assets in emails. Let’s walk through the most practical solutions to make sure those avatars load every time someone opens the message, no matter how much time has passed:

1. CloudFront + Origin Access Control (OAC) + 邮件服务商IP白名单（推荐用于敏感头像） #

This approach keeps your S3 bucket locked down while letting email clients access avatars via CloudFront with permanent, non-expiring links. Here’s how to set it up:

• Step 1: Create a CloudFront distribution pointing to your private S3 bucket, and use OAC to block direct access to S3 (only CloudFront can connect to the bucket now).
• Step 2: Update your CloudFront behavior to add an IP allowlist for known email service providers (Gmail, Outlook, Yahoo, etc.) and common email client IP ranges. Most providers publish these ranges publicly, so you can pull them into your CloudFront config.
• Step 3: Swap out your pre-signed S3 URLs for the CloudFront domain URL (e.g., https://d123.cloudfront.net/user-avatars/john-doe.jpg) in your emails. Since email clients are allowed to hit CloudFront, the link will work forever—just be sure to update the IP allowlist if providers change their ranges down the line.

Pros: Keeps assets private, no expired links, works for most major email clients.
Cons: Requires occasional maintenance to refresh IP ranges, a bit more setup upfront.

2. 超长期限的S3预签名URL（快速实现，需权衡安全） #

If your avatars aren’t super sensitive, you can generate pre-signed URLs with an extremely long expiration window. Here’s the catch:

• When generating the URL via AWS SDKs (like boto3 for Python), use permanent IAM user credentials (not temporary roles) to set the ExpiresIn parameter to a huge value—like 315360000 (that’s 10 years in seconds). Temporary credentials only let you set max 7-day expirations, so permanent credentials are key here.
• Drop this long-lived URL into your emails, and it’ll work for the entire expiration period.

Pros: Dead simple to implement, no extra AWS services needed.
Cons: If the URL leaks, anyone can access the avatar for years. Only use this for non-sensitive profile pics where the risk is acceptable.

3. 公开S3桶的特定前缀（最简单，适合非敏感内容） #

If your avatars are totally non-sensitive (think generic team headshots, not private employee photos), you can make a specific bucket prefix publicly accessible with a bucket policy.

• Create a policy that allows anonymous read access only to objects under s3://your-bucket/user-avatars/.
• Use the direct S3 URL (e.g., https://your-bucket.s3.us-east-1.amazonaws.com/user-avatars/john-doe.jpg) in your emails—this link will never expire.

Bucket Policy Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket/user-avatars/*"
    }
  ]
}

Pros: Zero ongoing maintenance, links are permanently valid.
Cons: Avatars are publicly accessible—anyone with the URL can view them.

4. CloudFront Signed Cookies（适合 authenticated 用户，通用性有限） #

If you’re sending emails to logged-in users, signed cookies can work, but keep in mind email client cookie support is hit-or-miss:

• Set up CloudFront with OAC connected to your S3 bucket.
• Generate signed cookies that grant access to your avatar prefix, and embed them in the email. When users click the CloudFront URL, the cookie authenticates their request.

Pros: Avoids per-object pre-signed URLs for bulk assets.
Cons: Many email clients block third-party cookies, so this isn’t reliable for general email distribution.

内容的提问来源于stack exchange，提问作者Ashish Rai