You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds VPC origin support - lets CloudFront point at a private ALB/NLB/EC2 instance instead of needing a public endpoint.
origin_type can now be "vpc", with a new vpc_origin_config var for the primary origin
same vpc_origin_config shape works per-entry on custom_origins too
added examples/vpc-origin showing the whole thing end to end (internal ALB + aws_cloudfront_vpc_origin + the module)
bumped the aws provider floor to >= 6.28.0 - that's the version owner_account_id actually shipped in, and without it the module errors out as soon as you touch vpc_origin_config
also fixed a few examples/* that were still pinned to old provider constraints (>= 5.0) that didn't match what the root module actually needs
README regenerated
why
There's currently no way to use VPC origins with this module short of forking it.
Kept the aws_cloudfront_vpc_origin resource itself outside the module (you pass in the ID) - same pattern as the mTLS trust store and connection function. It's infra that usually lives elsewhere and has its own lifecycle, so it didn't feel right to own it here.
owner_account_id needs AWS provider >= 6.28.0. That floor makes this release major. If you remove owner_account_id, the floor stays at 6.13.0 and the label becomes minor.
Please revert required_version to the current value. The change does not need >= 1.5.
Add a precondition: origin_type = "vpc" needs vpc_origin_config.
Add the VPC origin to examples/complete and assert it in terratest. Do not use the default VPC.
owner_account_id and the >= 6.28.0 floor: i'd rather keep it. it's the only way to point vpc_origin_config at a VPC origin that lives in another AWS account, and i need that. i'm ok with the major label and the higher provider floor. 🙂
required_version: i took out the >= 1.5 bump. It's >= 1.2 now, not the original >= 1.0, because the precondition you asked for needs Terraform 1.2 and doesn't even parse on older versions. the examples list what they really need:
>= 1.2 for the examples that only use the root module
>= 1.3 for complete and vpc-origin, since they use the cloudposse/alb module
Precondition: if i understood you correctly, you meant a lifecycle { precondition } on the resource, so that's what i added to aws_cloudfront_distribution.default. origin_type = "vpc" without vpc_origin_config now fails at plan time with a clear message. i didn't go with a variable validation, because validating one variable against another needs Terraform 1.9. let me know if you had something else in mind.
examples/complete and terratest: the VPC origin is part of complete now, on its own VPC instead of the default one.
i used cloudposse/vpc, cloudposse/dynamic-subnets and cloudposse/alb, like the other examples.
the ALB only takes traffic from CloudFront's CloudFront-VPCOrigins-Service-SG. i turned off the alb module's own security group, since it always opens HTTP to a CIDR list.
the terratest checks that the VPC origin gets created and that its distribution gets a .cloudfront.net domain.
i kept examples/vpc-origin as a smaller standalone example and moved it off the default VPC too.
I also removed examples/vpc-origin, based on your comment on cloudposse/terraform-aws-cloudfront-s3-cdn#380: terratest doesn't run it, and it creates a VPC and an ALB with no targets. The same VPC origin setup now lives in examples/complete, which terratest does run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
what
Adds VPC origin support - lets CloudFront point at a private ALB/NLB/EC2 instance instead of needing a public endpoint.
origin_typecan now be"vpc", with a newvpc_origin_configvar for the primary originvpc_origin_configshape works per-entry oncustom_originstooexamples/vpc-originshowing the whole thing end to end (internal ALB +aws_cloudfront_vpc_origin+ the module)>= 6.28.0- that's the versionowner_account_idactually shipped in, and without it the module errors out as soon as you touchvpc_origin_configexamples/*that were still pinned to old provider constraints (>= 5.0) that didn't match what the root module actually needswhy
There's currently no way to use VPC origins with this module short of forking it.
Kept the
aws_cloudfront_vpc_originresource itself outside the module (you pass in the ID) - same pattern as the mTLS trust store and connection function. It's infra that usually lives elsewhere and has its own lifecycle, so it didn't feel right to own it here.Nothing breaks - new stuff defaults to null.
references