-
Notifications
You must be signed in to change notification settings - Fork 4k
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
[CloudFront] Distribution - Origins for other constructs #9207
Labels
@aws-cdk/aws-cloudfront
Related to Amazon CloudFront
effort/medium
Medium work item – several days of effort
feature-request
A feature should be added or improved.
in-progress
This issue is being actively worked on.
Milestone
Comments
njlynch
added a commit
that referenced
this issue
Jul 22, 2020
…for ALB/NLB origins This change creates a new, dedicated aws-cloudfront-origins module to hold convenience methods for constructing origins based on other constructs. The initial set of supported origin types are S3 buckets, app and network load balancers, and fallback support for any other HTTP server. Future work in this space might include using properties of the constructs to automatically configure the origins in optimal ways. For example, gaining access to the load balancers' listeners to determine which port(s) CloudFront should connect to. Notes: - It's worth someone challenging whether this is necessary. Most of the origin implementations are reasonably straightforward and could be included directly in the aws-cloudfront module. - I wanted -- for non-S3 origins -- to expose the full set of configurable options, but didn't want to force users to specify the domain name, so split the *Origin Props into Options/Props, with the latter requiring the domain name. Open to other suggestions on how to achieve this (or arguments that the `S3Origin` should have this support as well). fixes #9207
mergify bot
pushed a commit
that referenced
this issue
Jul 23, 2020
…NLB origins (#9209) This change creates a new, dedicated aws-cloudfront-origins module to hold convenience methods for constructing origins based on other constructs. The initial set of supported origin types are S3 buckets, app and network load balancers, and fallback support for any other HTTP server. Future work in this space might include using properties of the constructs to automatically configure the origins in optimal ways. For example, gaining access to the load balancers' listeners to determine which port(s) CloudFront should connect to. Notes: - It's worth someone challenging whether this is necessary. Most of the origin implementations are reasonably straightforward and could be included directly in the aws-cloudfront module. - I wanted -- for non-S3 origins -- to expose the full set of configurable options, but didn't want to force users to specify the domain name, so split the *Origin Props into Options/Props, with the latter requiring the domain name. Open to other suggestions on how to achieve this (or arguments that the `S3Origin` should have this support as well). fixes #9207 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
curtiseppel
pushed a commit
to curtiseppel/aws-cdk
that referenced
this issue
Aug 11, 2020
…NLB origins (aws#9209) This change creates a new, dedicated aws-cloudfront-origins module to hold convenience methods for constructing origins based on other constructs. The initial set of supported origin types are S3 buckets, app and network load balancers, and fallback support for any other HTTP server. Future work in this space might include using properties of the constructs to automatically configure the origins in optimal ways. For example, gaining access to the load balancers' listeners to determine which port(s) CloudFront should connect to. Notes: - It's worth someone challenging whether this is necessary. Most of the origin implementations are reasonably straightforward and could be included directly in the aws-cloudfront module. - I wanted -- for non-S3 origins -- to expose the full set of configurable options, but didn't want to force users to specify the domain name, so split the *Origin Props into Options/Props, with the latter requiring the domain name. Open to other suggestions on how to achieve this (or arguments that the `S3Origin` should have this support as well). fixes aws#9207 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/aws-cloudfront
Related to Amazon CloudFront
effort/medium
Medium work item – several days of effort
feature-request
A feature should be added or improved.
in-progress
This issue is being actively worked on.
Support for origins created for:
This can be eventually extended to add other source construct types, as well as to automagically set some of the origin properties based on best practices for that origin type.
Proposed Solution
See aws/aws-cdk-rfcs#171.
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: