For the best performance naming many small files in an s3 bucket may not be the best idea unless they user_id is a random string. See how the S3 hashing algorithm works https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/
So replacing it by a random hashed value may not be that bad. Of course you need to store the hash in ...
CloudFront doesn't care where your origin server is hosted or even who you use for DNS. As long as the Origin Domain Name you provide is resolvable from the Internet (and has valid SSL configuration, if enabled), CloudFront will fetch the content from that origin the same as it will fetch it from anywhere inside AWS.
CloudFront does not actually have this feature. You can redirect the root object https://www.example.com/ to https://www.example.com/index.html by setting DefaultRootObject, but there's nothing for subdirectories such as https://www.example.com/posts/.
However, you can run arbitrary code on CloudFront using Lambda@Edge or CloudFront Functions, so it's ...
When you deploy an edge-optimized API, API Gateway sets up an Amazon CloudFront distribution and a DNS record to map the API domain name to the CloudFront distribution domain name. Requests for the API are then routed to API Gateway through the mapped CloudFront distribution.
Source: API Gateway documentation — Edge-optimized custom domain names.
To allow ...
It's a bug; origin_ssl_protocols is defined as a list here, then the code tries to treat it as a dict here (which is the line referenced in your stack trace.)
As a workaround, it looks like the code might accept
Nginx will help you in performing the below items if you need some of them, Then I would say it make sense to add it to the stack
Optimize the caching (you can also cache dynamic content.
Restrict access to the services (based on ips).
Implement basic auth for some services.
Load balancing traffic between different posds or services.
My solution is based on signed cookies (find how to implement it here, https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html); I've created a lambda that handles this for me a bit differently, as I need users to access a location to get their cookie in the easiest way possible and have someone control to whom ...
I needed to whitelist Host, Origin and Referer in the Whitelist Headers section.
I've had more issues with CloudFront, wrote a blog post about it, maybe someone will find it helpful: https://medium.com/@justynazet/placing-a-craft-cms-application-behind-the-cloudfront-1602027ff72b
As the issue is happening only with /admin URL, this might be related with cookies which are being passed to the backend application's /admin URL.
You may need to check with CraftCMS team (or some other forums) and get the list of cookies which are being used by the /admin URL. You can whitelist those cookies in cloudfront specifically for /admin URL.