-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support certificate from ACM to simplify running behind CloudFront in a multi-region setup #253
Comments
Another alternative I've tried is put API gateways in front of the App Runner instances. API gateways in all regions can be assigned the same custom domain (e.g. But again, like the Lambda@Edge that overrides the origin hostname in CloudFront, this feels like an extra step that is unnecessary (and incurs additional costs). Simply being able to manually assign a certificate from ACM to the App Runner instance would solve this completely. |
Community Note
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
I have been successfully using AppRunner in a single region for more than a year and it's working fine. Now I am trying to distribute the service globally to decrease service latency.
My initial approach was to create identical AppRunner services in multiple regions, and then use Route 53's latency-based routing and use that hostname as the origin for a CloudFront distribution.
The problem appears to be that if the CloudFront distribution is available under
api.example.com
, and the latency-based record for the origin isapi-origin.example.com
, then the setup won't work because of SSL certificate validation. I can not associate an AppRunner service with a certificate forapi-origin.example.com
, I can only do "Link Domain" which fails because in addition to creating a certificate it also wants to create a CNAME – which collides with the latency-based record.Being able to use a certificate from ACM would solve this.
Describe alternatives you've considered
I've considered separate origins for each AppRunner service and having a Lambda@Edge function look up a latency based TXT containing the actual origin hostname, then override the origin request's
Host
header. I have not tried if this actually works, and I would like to avoid the overhead of this approach is it is significantly more complex.Additional context
Attachments
The text was updated successfully, but these errors were encountered: