GetAtt coverage

[rhboyd]

I'm not using the template on this one because it cuts across many services/resources/etc.....

If a resource has an Arn, Fn::GetAtt [myResource, Arn] should return said Arn. If I get a cfn failure one more time because !GetAtt myResource.Arn is undefined and !Ref myResource returns the Arn instead, I will write a VERY sternly worded tweet (maybe a couple).

I recognize that there's a bigger debate about "Arn all the thingz!!!" bu tthat's not what I'm asking for. All I want is GetAtt Arn to work if the Resource has an Arn.

[mbonig]

Whatever the !Ref returns should be available as a straight !GetAtt too.

[rjlohan]

Is there value in enabling the !GetAtt function to retrieve any attribute of a resource, rather than the current subset we offer?

!Ref has special meaning in that it returns the identifier of the physical resource, which is what CloudFormation uses internally to track your things so I don't think there's any concerns in how that function behaves.

[rhboyd]

Is there value in enabling the !GetAtt function to retrieve any attribute of a resource, rather than the current subset we offer?

Is +∞ an appropriate amount of value? That would make working with CloudFormation SO much easier. Personally, I avoid !Ref at all costs because I have to interrupt and go check the docs to see what !Ref returns for a specific resource type. Making the returned value explicit with !GetAtt would be YUGE!!!!

[benkehoe]

The CloudFormation team should enforce that when teams add new resources to CloudFormation, they have both a Name attribute (just "Name", not "FooName" for a Foo resource unless there is a very good reason) and an Arn attribute (case sensitive, I don't care if you choose Arn or ARN, but enforce one of them).

[rjlohan]

The CloudFormation team should enforce that when teams add new resources to CloudFormation, they have both a Name attribute (just "Name", not "FooName" for a Foo resource unless there is a very good reason) and an Arn attribute (case sensitive, I don't care if you choose Arn or ARN, but enforce one of them).

That enforcement is probably more a function of accepting a Name on the underlying service APIs, which plenty do not.

[benkehoe]

The attributes of a CloudFormation resource should not have to match the underlying APIs at the expense of user confusion.

[rjlohan]

The attributes of a CloudFormation resource should not have to match the underlying APIs at the expense of user confusion.

Hmmm... so maybe you could clarify for me where the Name data would reside? If it's not attached at the underlying service would it be metadata only available in CloudFormation? In that case, the existing logical resource ID of a resource is that same information?

[benkehoe]

The CFN resource developed by the service team would be responsible for mapping between the required "Name" attribute and the corresponding "Name" parameter in their APIs. Who knows, maybe it would eventually drive consistency in the APIs!

[mdavis-xyz]

More broadly, I think GetAtt should also work for all Properties.

For example, if I have:

    PublicDomain:
        Type: AWS::Route53::HostedZone
        Properties: 
          Name: !Join [ ".", [ !Ref "stage", "something", "other", "example", "com"] ] 

I would like to be able to use !GetAtt ["PublicDomain", "Name"], and have it return the result of !Join [ ".", [ !Ref "stage", "something", "other", "example", "com"] ] .
I don't want to have to copy and paste that !Join statement throughout my template. Copy-ing and pasting is almost always bad. (e.g. what happens when I modify one instance of that !Join expression and I forget to change the others.)

[rhboyd]

That !Join should be

!Sub "${stage}.something.other.example.com"

Your teammates and future-you will thank you.

[mbonig]

The attributes of a CloudFormation resource should not have to match the underlying APIs at the expense of user confusion.

It would create a disconnect between the CFN definition and the underlying API calls which itself is confusing.

[rhboyd]

CFN shouldn't be seen as "SDK in the cloud". That's what leads people to thinking that concepts like Terraform are a good idea. It's completely normal for the CFN Definition to deviate from the service's API as long as the CFN Definition is well documented. CFN has the capability to create many different layers of abstraction based on what the user needs in that case, while the API is usually constrained to the single lowest layer.

[benkehoe]

CFN shouldn't be seen as "SDK in the cloud"

Seconded. Service resources have lifecycles that are not always well-represented by mapping directly to API calls. CloudFormation needs to internalize this; the lack of this awareness is why we can't deploy two versions of a Lambda function in a single template.

[reidca]

More broadly, I think GetAtt should also work for all Properties.

For example, if I have:

    PublicDomain:
        Type: AWS::Route53::HostedZone
        Properties: 
          Name: !Join [ ".", [ !Ref "stage", "something", "other", "example", "com"] ] 

I would like to be able to use !GetAtt ["PublicDomain", "Name"], and have it return the result of !Join [ ".", [ !Ref "stage", "something", "other", "example", "com"] ] .
I don't want to have to copy and paste that !Join statement throughout my template. Copy-ing and pasting is almost always bad. (e.g. what happens when I modify one instance of that !Join expression and I forget to change the others.)

I agree and furthermore it should allow properties from existing resources to be returned.

I have created a custom resource that takes in some uniquely identifiable characteristic of existing resources and returns anything which could be useful to other resources in the template. I would love this functionality to be built into Cfn without me having to maintain the python code and ecer expand it for new resources.

Without this I was finding it impossible to work with resources created outside of that particular template or created manually in the console. Using exports and imports is problematic because of the dependencies it puts on stacks and because each resource has to have individual properties exposed instead of the resource being treated as an object.

Any improvement in this area would be a major benefit.

[fimbulvetr]

The attributes of a CloudFormation resource should not have to match the underlying APIs at the expense of user confusion.

Disagreed. The fact that CF is extremely similar to the API is exactly what makes it easy to reason about.

[PatMyron]

Not sure how up-to-date this stays, but this should help quickly identify lacking GetAtt ARN coverage:
https://theburningmonk.com/cloudformation-ref-and-getatt-cheatsheet/

up-to-date command for GetAtt attributes:

curl -s --compressed https://d1uauaxba7bl26.cloudfront.net/latest/gzip/CloudFormationResourceSpecification.json | jq '.ResourceTypes' | jq 'with_entries(.value |= .Attributes)' | grep -v ': null' | grep -v 'Type": "'

---

ARNs can also frequently be constructed using other return values, Pseudo Parameters for Partition, Region, and AccountId, and the Sub intrinsic function like this if anyone needs workarounds:
https://stackoverflow.com/a/59362496/4122849

[rjlohan]

One concern we've had with allowing !GetAtt for anything is that it could be inadvertently used on highly volatile properties leading to unexpected changes in stack updates. At this time, !GetAtt is mostly reserved to properties which are createOnly and so do not change on update (and then lead to a propagation of unexpected changes).

How do folks feel about this risk/concern?

[r-heimann]

All of my opened issues are in regards to

Whatever the !Ref returns should be available as a straight !GetAtt too.

These are, according to the CFN Docs, not available as a !GetAtt and only usable through !Ref.
Since those already exist as !Ref it should be easy for the CFN Devs to implement those as !GetAtt and update the CFN Docs.
If i find more CFN Resources which have !Ref but are missing its !GetAtt i'll reference them here.
Believe it or not but some of the CFN Resources actually have this properly implemented... Here's hoping that in the future this will be supportes out-of-the-box for new services or this'll be a nerver-ending issue.

[srcndogan]

We should be able to retrieve arns for all resource types that have ARNs. While requesting on all of them wanna identify below resources as well for the FR ASAP please.
AWS::Glue::Database AWS::Glue::Table AWS::Logs::LogStream

[tb3088]

The previous is mine. It is unconscionable that 4 years in and the team has yet to squash ALL of their published object types. You (AWS) hire summer interns by the bushel-load. No more perfect opportunity to do the grunt work of validating EVERY object for essential attribute support and updating the documentation. What is so hard about REFUSING acceptance from a service team that tries to deliver an incomplete implementation? A thousand eyes in Seattle might as well be struck with blindness how utter crap API consistency and coverage is. You're supposed to write tooling to force compliance.

The various official blog and 'help' pages with their example templates intended for customer consumption are shockingly badly written, and Arn being unavailable is no little part of that.

Any competent API team also knows you HIDE implementation-specific quirks from the user. So yes, a "Name" attribute absolutely should be supported and transparently mapped to whatever private XXXName the Service team chose to use. You can support the private one too, but having to open the Service API in order to decipher CF is nuts!

ex-AWS employee