Skip to content
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

Closed
njlynch opened this issue Jul 22, 2020 · 0 comments · Fixed by #9209
Closed

[CloudFront] Distribution - Origins for other constructs #9207

njlynch opened this issue Jul 22, 2020 · 0 comments · Fixed by #9209
Assignees
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.

Comments

@njlynch
Copy link
Contributor

njlynch commented Jul 22, 2020

Support for origins created for:

  • S3 buckets
  • ELBv2 load balancers (both ALBs and NLBs)
  • Any other domain

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

@njlynch njlynch added feature-request A feature should be added or improved. @aws-cdk/aws-cloudfront Related to Amazon CloudFront effort/medium Medium work item – several days of effort labels Jul 22, 2020
@njlynch njlynch self-assigned this Jul 22, 2020
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
@njlynch njlynch added the in-progress This issue is being actively worked on. label Jul 22, 2020
@mergify mergify bot closed this as completed in #9209 Jul 23, 2020
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants