- Newest
- Most votes
- Most comments
Yes, the new header rewrite ability of the ALB does allow you to overwrite the entire Host header value with anything you want. When you overwrite it with the virtual-hosted DNS name of the bucket, of the form BUCKETNAME.s3.REGIONCODE.amazonaws.com, the VPC interface endpoint should accept it and pass it to the S3 service, which should use it to identify the bucket to which to address the requests coming through the ALB.
If you want to use the same ALB to serve requests for multiple buckets, and using "example.com" as the sample name of your own DNS domain, you could create a wildcard TLS certificate for *.example.com in ACM and attach it to the ALB's HTTPS listener. In the listener rules, only accept requests with a Host header matching the regex pattern "^[^.]+\.example\.com$" and send them to the VPC endpoint's target group after OIDC authentication. In the transform rule, set "^([^.]+)\.example\.com$" as the pattern and "$1.s3.REGIONCODE.amazonaws.com" as the replacement value. Of course, replace "REGIONCODE" with the region in which your ALB and S3 buckets reside.
This way, all requests from the ALB to S3 buckets in the region will go to the bucket with the name matching the hostname prefix preceding ".example.com" in the DNS names with which the ALB is called. For example, requests for mybucket1.example.com would get sent to mybucket1.s3.REGIONCODE.amazonaws.com.
I have always fronted S3 buckets with OAC control as I feel it’s more secure as the S3 bucket doesn’t have to be public. You may find it cheaper this way also.
The bucket name doesn’t matter if using cloudfront.
Relevant content
asked 10 months ago
asked 3 months ago

Thanks Gary. Does S3 origin access control work with ALB? I am using ALB as the entry point for an internal app so not a good fit for CloudFront.
@Darbio As you explained, you're using an ALB as the entry point in order to leverage the ALB's native ability to authenticate users with OIDC or non-OIDC methods via the ALB's integration with Amazon Cognito. CloudFront doesn't support either OIDC or other methods for authenticating clients without custom Lambda@Edge and/or CloudFront Functions implementations, so the ALB approach is a good, completely zero-code implementation of what you need. You can place the ALB behind CloudFront if you'd like, but OAC would only authenticate requests from CloudFront to S3 (or Lambda), not requests from your users that you want to authenticate against an IdP with OIDC or other means. Therefore, you'd still need the ALB for OIDC/Cognito integration, and OAC will neither work nor be needed in that scenario.
Thanks Leo. Great explanation and fits my architecture well.