CloudFront Origin IDs

[DfHlyu4aida]

Hey there, Currently we're migrating a serverless project to use the CDK. What we're experiencing now is that despite setting an ID for an Origin behavior it is always overwritten by origin{indexOfBehavior+1}. I also found that there is no typesafe way in TypeScript to set this property on Behavior, because it doesn't exist on that type. The parent construct CloudFrontWebDistribution is internally using an unexported type for behaviors called BehaviorWithOrigin. The constructor of CloudFrontWebDistribution is overwriting any specified (by sidestepping the typechecker) origin id, see here.

My question now is: is that the expected behavior of the CDK? Like, is this intentional to prevent people to have colliding origin IDs? Or is this a bug/feature?

[eladb]

Indeed the current API doesn't allow specifying origin ID. I am curious, what is your use case for explicitly setting the origin ID?

[SomayaB]

Closing for now since there hasn't been a response in a while. Feel free to reopen.

[dpistole]

doesn't need to reopen but I was lead here by google because I wanted to give my origins friendlier names to help make identifying them easier while troubleshooting, not the most critical use case but a would be nice for me anyway

[vobarian]

This feature exists in the actual service and other tools such as Terraform but not CDK. I can see why it is low priority but I can't see a reason NOT to implement it.

My use case is that we have a CloudFront distribution with a large number of cache behaviors. It acts as a sort of router to dispatch paths to various back end services. When looking at the list of behaviors in the console it would be very helpful if we could give the origins a meaningful name so we do not have to constantly flip back and forth between the behaviors and origins tab to see what "originN" is and try to remember all those.

[iliapolo]

@njlynch Do you know if we can implement this now? Seems like the original issue was a while back

[njlynch]

Thanks for the tag, @iliapolo . Yes, I think this is a reasonable feature request. I'll re-open.

[antonfelich]

Just came across the same limitation. Agree it's a pretty low priority, however, having human-readable names that match the purpose of the origins definitely makes debugging easier.

[benm5678]

We also need it please... helps a lot & can be done via SAM.

[chtpl]

please add it

[SkySails]

Just stumbled upon this issue as well, and while not mission-critical it does feel bad not to be able to replicate some of my old CloudFormation templates completely using CDK despite the fact that I would really like to!

[omriman12]

one more thumbs up

[bradcondo]

I would also like to see this added, I have many origins going to lambda function URL's and there is nothing to identify them in the console. I can do some digging to figure it out, but it would be great if we could put an identifier there.

[etaroid]

one more thumbs up

[vaughan-rich]

+1 on this one - auto-generated 'Origin Name' in the console is very difficult to read

[khromov]

Are there any workarounds for setting the "Origin Name" when defining a HttpOrigin? It is almost impossible to navigate a CF distribution when you have many origins. Also the names become very long since the stack name is prepended..

[adrian-skybaker]

Are there any workarounds for setting the "Origin Name" when defining a HttpOrigin?

You can use an escape hatch to post-process the generated resource, eg (in Java):

Distribution distribution = Distribution.Builder.create(this, "Distribution")
    ...
    build();

// Workaround https://github.com/aws/aws-cdk/issues/2756
CfnDistribution cfnDistribution = (CfnDistribution) distribution.getNode().getDefaultChild();
cfnDistribution.addPropertyOverride("DistributionConfig.Origins.0.Id", "my-origin");
cfnDistribution.addPropertyOverride("DistributionConfig.CacheBehaviors.0.TargetOriginId", "my-origin");

[github-actions[bot]]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.