Using CloudFormation Intrinsic Functions
If you use AWS CloudFormation at any level, you need to know what intrinsic functions are and how you can use them. Why? Because without them, you will be limited to very basic templates.
More complex infrastructures require dynamically generated values, and intrinsic functions give you the ability to use these dynamic values.
Fn::GetAtt
For example, if an AWS resource in your stack depends on another resource’s attribute, and this resource is also built at runtime by the stack, you oftentimes won’t know that attribute’s value until CloudFormation creates it, and so you can’t hardcode it. To solve this problem, we can use the Fn::GetAtt intrinsic function to grab that value and inject it at runtime. Here’s what this might look like:
In this example, we are creating an EC2::Instance, and then we are outputting that instance’s public and private IP addresses in the “Outputs” section. Because these values will be dynamically generated, we use…
“Fn::GetAtt”: [“PublicInstance”, “PublicIp”]
“Fn::GetAtt”: [“PublicInstance”, “PrivateIp”]
…to inject the correct values once CloudFormation receives them. The first parameter is the logical name of our resource (“PublicInstance”), and the second parameter is the attribute name we’d like to retrieve (ie: “PublicIp”). I know this from the documentation for that specific function. That page tells me the correct syntax, parameters, return values, available attributes depending on the resource type (in this case: “PublicIp” and “PrivateIp”), and more information.
There is also a page which lists all intrinsic functions available for AWS CloudFormation stacks.
Fn::GetAZs
Another very useful function is the “Get Availability Zones” intrinsic function.
As you may know, AZs (availability zones) can be different depending on the AWS account. One major reason for this is because if every AWS account had the same AZs, and 80% of customers launched resources in the same AZ, there would be a huge imbalance on AWS’ resources.
So, we can’t expect AZs to remain the same between accounts. The problem this causes is one of portability. If you are trying to build a template which could be re-used across multiple accounts (think about developers and Ops, and different production accounts), your hardcoded AZs would sometimes have to be changed in order for your stack to launch. Instead, we can use the Fn::GetAZs intrinsic function to return an array of available AZs in that account, and in the region in which you are launching the CloudFormation stack.
In the pictured example, we are creating an Amazon VPC subnet, and in this subnet’s properties, we are defining the AvailabilityZone in which to launch the resource. We do this with Fn::GetAZs.
Notice that we are actually using another intrinsic function, Fn::Select. This function is very simple, and all it does here is return the value in the availability zones array which is located at the 0th (zero) index. So we might have an array like this:
[ ‘us-east-1a’, ‘us-east-1b’, ‘us-east-1c’, ‘us-east-1d’ ]
Where our example would select ‘us-east-1a’ since that is located at the index of zero. If, instead, we had this:
{ “Fn::Select”: [“2”, {“Fn::GetAZs”: “” } ] }
Then the previous array would have returned ‘us-east-1c’.
We can use this intrinsic function to create more portable templates, and also to create resources across different AZs for higher availability. Going back to our subnet resource, we could use Fn::GetAZs to create 3 subnets in 3 different AZs by specifying different indexes.
Other functions
As you can see from the documentation page which lists all functions, there are many others which we haven’t discussed here. That doesn’t mean they aren’t powerful, and you should definitely research them.
