6. [DVA] CloudFormation Resources
Let’s talk about resources. So resources are the core of your cloud formation templates, and they’re mandatory. Your confirmation template cannot work without the resources block. And the resources, as the name indicates, represent the different apex components. Only a synonym will be created and configured, and the resources will be declared so that they can be referenced. so you can link the resources together. For example, if you link a security group to an EC2 instance, AWS will handle the resource creation, updates, and deletion for us, which is very convenient. You should also be aware that there are over 224 different types of resources.
So I cannot teach you all of them, right? However, any resource must include the AWS, product name, and data type name. So usually, reading this identifier, you’re able to figure out what they were going to create. So, where do I go to find all of this documentation? Well, there is this great link that has all of them. So, while I can’t teach you how to find all of the resources, I can teach you how to find a link to the resources that does. So you just read the document, and for example, we’re going to read the document together for illustration purposes, just to get a feel for it. So the first web page I referenced to you is called the “AWS resource type references,” and this contains all the references that are supported by cloud formation. And the resource name naming convention is here. And if you scroll down, you can see there are a lot of resources. Honestly, you could count too many of them.
So we can see that we can create a resource for pretty much everything. Let’s scroll down and see if there is something we know. Yes, auto scaling is available. We know how to create an auto-scaling group. Using this cloud formation resource, we can create auto-scaling group scaling policies and launch configuration. If we scroll down, we’re able to do good, build code, commit code, and deploy a good pipeline. So all these things we’ve seen before, we’re able to do them. Scrolling down, we can see the easy to instance, the elastic IP, and the security group. So let’s have a look at the EC2 instance because I think that’s the one we’re most familiar with. So the AWS EC2 instance creates an easy instance because that’s pretty obvious. Now, basically, we can scroll down and look at the syntax of how to declare this simple instance. We have a JSON form, which to me is a little bit unreadable, but we scroll down and we get a YAML form, which to me is much clearer. So this is the YAML form for an easy-to-write instance.
It must be of type Albus EC 2 and an instance, and it will have some properties. So when you create a resource, it must have a type and have properties, and the properties are going to be key-value pairs. So, as you can see here, you can customise a lot of things for your EC2 instance. For example, if you wanted to customise the IAMinstance profile, we would click on this and get teleported to the documentation for that, and it would say, “Okay, you need a string, but it’s not required.” And if you update this, there’s no interruption. So that means that your EC2 instance won’t get terminated and recreated; it will just attach your instance profile to it. But if we change the image ID, for example, which is also a string but not required, then if we update it, basically it will do a replacement. That means that it will terminate the old instance and replace it with a new one. So let’s go scroll back up. And so here we understand that there are so many things we can customize, and to know what we should specify, we should just look through the documentation. Now, if we look at what we created before, let’s just take EC 2 as an example as just EC Two.
We have an availability zone, an image ID, and an instance type. And so, basically, I knew how to fill those out because if you click on AZ, then you see that you have to specify the name of the AZ where the instance is located. And so this is quite great, and you can just keep on going with this as much as you want. So now we basically understand how this was created. For fun, you could go into the resources here and see that we have an easy to use instance, but also that we have an EIP. So, if we look at EIP, we’ll go back one page and then search for EIP on this page. Here we go. We have EIP here, and we can see that the syntax is much shorter. We have an instance ID and a domain. And so the instance ID is what I have specified, but the domain is not specified. So here, when we go back to our EIP, we can see that, yeah, it makes sense. I did specify the type to be an AWS EC-2 EIP. And in terms of properties, I have only specified the instance ID. We’ll see what this reference means in a second.
Okay, but so the idea is that we are able to link the documentation to what we want to do. And so obviously, for the security group, we need to provide the security group rules for ingress traffic. And because we can have many rules, there is an array. So let’s go to the security group documentation. Just to prove that point, the security group is right here, and we go to YAML. And if you look at security group ingress, we can see there is a list of Amazon EC2 group rules. And so if we click on “easy to group rule” and we click on it, we go to YAML, and we get all the parameters that are available. So going back to the syntax, we get this little hyphen here that defines it to be an array, and here we get the first rule, and here we get the second rule. And so yeah, what we get out of this is that everything we configure through the UI can be written as code into your cloud formation templates. And this is how you know how to redact your cloud formation templates. So that’s it for resources. That’s honestly all you need to know. Just remember, there’s a type and there are properties, and all of this goes below the block called “resources.” So you need to make sure there is a small indent underneath resources every time you declare a resource.
Now for the frequently asked questions about resources: can I create a dynamic amount of resources? No, you cannot. Because everything must be confirmed, code generation and dynamic code generation are not possible. And is every editing service supported? The answer is almost. There are only a few small ones that are not there yet, and you can work around that using the AWS Lambda custom resources. Just a little bit of trivia here; you just need to know about it. In this course, we will not write to customresources Lambda. So that’s it for resources. I hope you enjoyed it and that everything makes sense now. I will see you at the next lecture.
7. [DVA] CloudFormation Parameters
Now that we’ve seen resources, the second most important one is going to be parameters, and parameters are a way to provide inputs to your elder cloud formation template. They are super important to know about if you want to reuse your templates across the company or other Elus accounts or regions, and some inputs cannot be determined ahead of time. For example, the key point here is that you’re going to link to a simple example. Parameters are extremely powerful; they can be controlled, and thanks to types, they can prevent errors from occurring in your templates later on. So we’ve used parameters before in the first hands-on, in which we basically had to specify the security group description.
So there was a string, and we were asked for the security group description, which was used in the security group itself. So you should use a parameter when, basically, you ask yourself, “Is this confirmation resource configuration likely to change in the future?” If so, you can make it a parameter, and by doing it as a parameter, you don’t have to re-upload a template to change its content. It’s a bit more stable and a bit modularized. If you do programming, and I hope you do, you know the advantages of parameters. Now, parameters can have different settings and be controlled in many different ways. I don’t think the exam requires you to know all of these, but for me, and for your interest, I’m just going to name them. A type can be a string number, a composite restricted list of a type, or an AWS parameter. As far as description, you can have constraints, a constraint description, a minimum and a maximum length for strings, and a minimum and a maximum value for numbers. You can have default allowed values when you want to restrict the number of values. A user can pick an allowed pattern when you want to verify the inputs of a user using a regular expression and echo if you want to pass in the secrets, basically. So there are numerous optimizations and parameters available. For now, the only thing we’ve done is use a simple string parameter in our thing, and that’s all you should know, I think, for the exam. So how do you reference a parameter? In this case, you must employ the ref function. And so this is the first time we encounter references and functions. But basically, interesting functions in your templates allow you to supercharge it and link things up. And so the ref function is one of the most used, so you use it to reference parameters, and this way you can use your parameters anywhere in your templates. So look for any type of input, parameter, or configuration in your resources. So the shorthand for a reference function in YAML is “little exclamation point rest,” and this is why it’s just a way for us to have a much nicer syntax that’s easier to recognize. You can use the FN colon and colon ref as well. It’s whatever you want, but most likely it’s going to be this exclamation point ref for shorthand.
And the function can also be used to reference other elements within the template. So in the template we’ve been using in the parameter section, we defined a parameter named “security group description.” It turns out that if we look all the way down, the security group description was used in this security group description key, so we used the ref function to reference it. So this ref function basically says that whatever the user enters as a parameter value for this parish measure key, you should use it and reference it in the group description. So it’s very simple to think about; it’s just a reference. But this reference function can also be used somewhere else. It was used right here, for example, for security groups. So you can see that this reference function also references the SSH security group that was created under resources. So the ref function can be used both to reference parameters like the one before and to reference resources. So here we reference the two security groups, and within the EIP we reference my instance. As you can see, the name of the reference is the exact same name as the logical value under Resources.
Finally, you have the concept of “pseudo parameters,” which are a list of available parameters that we can use at any time, enabled by default. And we only get a list of values that we might want to retrieve. So we can get an account ID, and you can just give us the value of the account ID notification, which has no value. If we don’t want to return a value, we can also ask for the region in which our flight confirmation template is being run at.So for example, for USD 2, we can also get a pseudo parameter for the stack ID or the stack name. Basically, you don’t need to know too much about these too much.Maybe the first one, account ID, is very important to get the value of the accountID if you try to construct some complicated ARN value in your cloud formation template. But overall, you should just know that there is this concept of pseudo parameters, and again, you can use them at any time. Just use a reference, and you’re all set. I hope that was helpful. I hope you know how they work now in your cloud formation templates, and I will see you in the next.
8. [DVA] CloudFormation Mappings
Now let’s talk about mappings. Mappings are fixed variables within your CloudFormation template. They have to be hard-coded. They’re very handy if you need to hardcode some values based on the different environments you’re in. So development versus production, or regions such as Ilis regions or AMI types, etc. And as I said, all the values must be written out explicitly in your template. As an example, here is a map, and this is how you write it.
So you have a mappings section, and then you have the name of the mapping. Then you have a key, and underneath you have keys called names and values. So it’s quite a low-level type of architecture. And so, to make it more concrete, we may have a region map to map regions to Amis. And so we’re saying, “Okay, within US East 1, UST West 1, or EU West 1, based on whether you choose a 32-bit or 64-bit type of architecture, here is the AMI ID you should be using.” So overall, this is just a hard coded “okay.” Based on where the template is being run, this is the AMI I want to use. So, when we use mapping and parameters, mappings are great when you know all of the values that can be taken ahead of time. So, for example, amid And so you can deduce them from variables such as region (AZ), account environment (et cetera), etc., whatever you can think of. To me, they allow safer control over the templates. However, if you need the values to be truly user-specific, and the user must enter a value that you do not know in advance, you should use parameters. Now to access the mapping values, there is this function called “FN find n map,” which basically returns a value from a specific key. And the shorthand syntax is this one:
We use “find map” with a little exclamation point, and we have to give the map name and the top-level key and the second-level key. So we have three parameters right here. And so that’s something you should know for the exam, just the syntax of it, okay? And so if we look at this little confirmation template, we can see we have a region map that we have already defined from before.And so if we want to create an easy instance and reference the right AMI ID, then we use the Find in Map function for the image ID. And so the first one is the map name. So we’ll use region map because that’s what it’s called here. The second is that we want to refer to the AOS region we’re in. So we’re going to use this pseudo parameter we just talked about and the ref function. So we reference the address region the confirmation template is running in. So, for example, say we’re running in U8, then we are in this block, and then we say 32 as the second level key. So we look at the 32-bit key and get the value from it. We’ll get this. AMI 6411 e 20 D So this is the one that will be selected. So this is all you should know about mapping. Just remember that the syntax will be defined in mapfunction and that mappings have to be written out explicitly in your templates.
9. [DVA] CloudFormation Outputs
So let’s talk about outputs. And that’s actually a very popular exam question, so pay attention. The output section is optional, but we can declare optional outputs. And if we export these outputs, we’ll be able to import their values into other stacks. And by stack, I mean cloud formation templates. So you can start linking your confirmation templates. The outputs can also be viewed in the AIS console or via the AOS CLI. So it allows us to quickly retrieve the value of an output straight from the UI. In terms of example, for example, you can have a network cloud formation template, and then you would export outputs that would be, for example, the VPCID and the subnet IDs, and you would reuse those into other confirmation templates. And so it enables you to do cross-stack collaboration where you let the experts handle their own parts of the VPC and the subnet.
And you, as an app developer, just reference these values out of the box. Something you should know, though, is that if you start using the cloud formation outputs and they start being referenced from another confirmation stack, you cannot delete a stack that still has outputs being referenced somewhere else. So it’s just something to know. Now, if you look at an example of the output in this one, we are creating an SSH Security Group as part of the templates. And so we export that value as an output, okay? And basically, other templates will be able to get the value of that security group ID. So the syntax is pretty easy. We have the output section right here, and we have the name of the security group, and we have the description. So, for our company, SSH Security Group, here’s the value. So we provide a reference to the security group that was created within the resources. And then we have to specify this export block right here. Okay, this is an optional block. If you don’t specify it, then the value does not get exported, and it will not be able to be imported. So when we specify the export value, we can say, “Okay, this value, this SSH Security Group ID, is going to be exported as the name SSH Security Group.” So now, how do we import that value while using a cross-tack reference?
And so we’ll create a second template that leverages the security group. And for this, we’ll use the FN import value function, which is an interesting function, and we won’t be able to delete the previous tag again until we’ve deleted all of this tag. So if we look at this little snippet of code right here, we can see that for the security groups, at the very bottom, there’s a shorthand syntax for the import value. And then we reference the exact same name as before, called SSH Security Group. So just a reminder: before, we exported the value as SSH Security Group, and here we import the value as SSH Security Group. So outputs and exports are a very popular question at the exam, especially if they start asking you how you link CloudFormation templates or reach the value from one to another. So you should know about it, you should know about the syntax, and you should know about the import value function. So I hope that was helpful, and I will see you in the next lecture.
10. [DVA] CloudFormation Conditions
Finally, we’re going to talk about the conditions. And so conditions are used to control the creation of resources or outputs based on some logical statements. And the conditions can be whatever you want them to be. But the common ones are that maybe you want to say if you’re in development, testing, or production, create or don’t create that resource.
Maybe it can be based on the region, maybe on the parameter value. As a result, each condition can refer to a different condition parameter value or mapping, allowing you to combine them. So, to define them, to make it a little more concrete, here’s a condition I made under the block conditions. And so here we say, “Okay, do we want to create the production resources?” And for this, you need to have the environment type, which may be a parameter. We need the reference for this environment type right here, so the value of this parameter is prod prad the string prod. And so here, basically, this whole thing is going to be true only if the environment is equal to production. And so using these productive resources, we’re able to basically define and condition other resources.
So it’s entirely up to you how you want to go about it. As a result, all of the functions you can use in there will be and equals, unless otherwise specified. And so these are logical functions, and you can compose them as much as you want. Now, how do we use a condition? Well, you can apply it as well to resources, outputs, et cetera. So, for example, if we look at a resource on my mountpoint, the type is AOS EC, a two-volume attachment. And this only gets created if the condition that creates production resources from before is true. So that gives you an idea of how conditions are used, basically on the same level as the type right here underneath the name of the resource. So that’s it for conditions. I think they’re pretty advanced. I’m not sure if they ask at the exam, but for you, it’s still good to know that they exist, and you can have a little bit more logic in your confirmation templates. I hope that was helpful, and I will see you in the next lecture.
