- Let's take a look at a demo
of creating resources with AWS Cloud Formation.
From the management console dashboard,
we'll go ahead and go to cloud formation
and you'll see here that we'll go ahead and make sure
that' we're here on the stacks menu item
and we can shrink that and
we don't have any stacks yet.
So, before we create one,
let's take a look at some code.
All right so here in my editor
you can see that we are
going to create as the description said,
we're creating a single VPC
with two public and two private subnets.
You'll remember that we did that manually
at least we created a VPC with one public subnet
and one private subnet in an earlier demo.
We did that manually.
And, here we're going to see how
we can do that through automation.
And so again, all of the demos up until now
we have created things manually.
We created VPC's and subnets,
EC2 instances, RDS instance,
we created Dynamo DB tables,
and all of that stuff we did manually.
In a sandbox environment, that's perfectly fine.
You know if you're wanting to get in
and just learn AWS and experiment,
try something out, prototype,
then doing thing manually in the console
is probably perfectly fine.
But in a real world scenario
when you're working with a team
and you're launching real applications out there
for you know, customers and end users to use,
then I would highly, highly recommend
that you avoid doing things manually.
We only did those things manually here, you know,
in this video course as a way
just to illustrate the principal of those services.
But ultimately, I highly recommend
using some kind of an automation tool like cloud formation.
It doesn't have to be cloud formation,
you can use other third party tools
like Teraform or Ansible or something else.
Right, so let's take a look here
at some of the resources that we're creating.
So we're essentially expressing our infrastructure as code.
And so, I don't have to worry about imperative instructions.
I don't have to, you know explicitly state,
hey build this then do that, and then do this
and if this condition, I don't have to worry
about imperative instructions.
I'm simply defining or declaring
the kinds of resources that I want.
So here I want a VPC and then I give it certain properties.
I want DNS support turned on,
I want DNS host names turned on,
and here I want certain tags,
and then down here I'm creating subnets in the same thing.
And so again, you'll notice that their are no
imperative instructions,
its all just me saying hey,
I want these kinds of resources to be built
and I want them to be related in certain ways
and you'll see here that this particular subnet,
subnet DMZA is related to the VPC,
you'll see here that we're referencing the VPC
that we're creating up here.
So, that's really all cloud formation is.
It's a a way of describing,
these are the resources I want created,
and this is the way that I want them to be
related to one another and the cloud formation engine
will take care of all of the imperative instructions.
It will take care of the order of operations
for the most part.
It knows before it can create the subnet
it first has to create the VPC.
It doesn't really matter what order they come in
in this template, it knows that is has to build one
before the other, right.
So this VPC could technically be listed last
in the template, but it would still be built first.
Now you'll also notice that we are here
if you remember from the earlier demo
when we created the VPC,
we had to specify a range of IP addresses.
And the same thing for the subnet.
And that's called a CidreBlock.
It's just a way of expressing a range of IP addresses.
Well if I were to hard code that,
right, if I were to put in 10 dot triple zero
slash 16, you know, if I hard coded that,
then that's all that this template will ever give me.
It becomes inflexible, it becomes too specific.
But if instead of hard coding it,
if I instead use a variable, or a parameter,
then now here I'm referencing,
you'll notice this Ref means reference,
I'm referencing VPC Subnet Cidrs
which is a parameter up here
that I get to specify at run time.
So when I launch this template
to the cloud formation engine,
then I get to enter in that CidreBlock and then
whatever value I put in here,
whatever value I put in there, will come out here.
And then down here AWS give us a number of different
what we call intrinsic functions.
The cloud formation engine allows to perform,
use these intrinsic functions to
make our stacks much more flexible and programatic.
And so here I'm essentially saying hey,
give me a CidreBlock, or a smaller CidreBlock
from a larger CidreBlock.
That's what this intrinsic function does.
It says give me a smaller block from a larger block.
And then that essentially returns in a ray
and from that I can select the you know,
arrays being zero indexed, I can select
the zero element or the first,
meaning the first element in that array.
And so for all of my subnets you'll notice
that they all look the same except down here
on the next subnet, I'm selecting the second element
in that array and so on and so forth.
So by doing that, I don't need to hard code anything,
and I don't need to specify a separate parameter
for each subnet, all four subnets can be derived
from that one CidreBlock that belongs to the VPC
so it makes life, it makes coding this whole thing
that much easier.
And then of course we can add our tags,
you'll see that we're adding a number of different tags
to these subnets and then down here
we're creating subnets that are meant to hold nodes or
private application servers.
Right.
And you'll also notice that event eh availability zone
is programatic, remember earlier in the VPC demo
when we created subnets,
we had to select the availability zone
that the subnet belonged to.
And here instead of hard coding that,
I can also use again, intrinsic functions
to say well, you know what,
give me the availability zones,
get the current availability zones for the current region.
So I don't even have to specify the region here
if I run this in US West two,
then it will give me you know,
all of the availability zones for that region.
If I run this in US East one,
this particular function will give me
all of the availability zones in that region.
And then of course I can select
the third element from that array.
And then of course I can also,
I might want to know, once this stack is completed,
once all of those resources,
the VPC and the four subnets are fully created,
successfully completed,
then I would want to know certain things
about those resources without having to go and dig for it.
So I might want to know the ID of the VPC, the VPC Cidre,
those things I could find, but
by declaring them as explicit outputs,
it puts a number of different values
that would normally be spread across
a lot of different areas, it puts them into one place.
One central place that I can very easily find them
and then of course by exporting them,
I can then leverage those within other templates, right?
Other templates could then build on top of this template
right, so you don't have to write
all of your moving parts,
all of your things that would go into an application,
you know, auto scaling groups, and load balancers,
security groups, and
Dynamo DB tables, RDS instances and so on.
You don't have to put all of it in
one cloud formation template and you shouldn't.
It just becomes too much and so
by using things like exports,
this is a way of helping us to break up our cloud,
what might otherwise become a very large
and unwield-y template, right?
Okay, so let's go ahead,
now that we've kinda explored what the code looks like,
let's go to the cloud formation console
and watch this in action.
We're gonna say create a stack
and of course we cause use a sample template
if we wanted to, we could upload this to S3
and then reference the S3 URL,
or we could just upload it directly to
the cloud formation engine.
Right, so let's go ahead and do that.
All right so now I have my yamil file
that I'm going to upload
and here we need a stack name.
We need to name this collection of resources.
Remember that a stack is a collection
of all of the resources that we just saw.
The VPC and the four subnets.
And the outputs.
And so this particular stack we could call
fundamentals VPC.
And then remember it asks us,
the template had declared one parameter
and this is where we get to enter that.
The CidreBlock for the VPC and then the subnets
will be derived from that.
And so we, earlier we used 10 dot zero,
and then also used 10 dot one,
so here we could say 10 dot two
dot zero zero slash 16.
We'll go ahead and say next.
And then of course we could tag
if we were to tag here then we would,
these tags would be a part of the stack
and they would also be applied,
any tags that we put here are also applied to each resource.
Right, so I could say environment dev.
And so you'll notice if we go back
to the template real quick,
you'll notice that I do have tags
and I usually use this to,
for tags that are specific to that particular resource,
and then for tags that I want to be common
across all resources I will put here.
So here all resources I might put in environment development
or project or cost center, or whatever.
All right, and we could of course add more tags.
We won't worry about that stuff.
Now we can get notifications if we wanted to.
Remember that as cloud formation builds
these resources out and if it encounters an error,
if it completes successfully,
there are a number of events that go along the way
and we could subscribe to those,
and we may want to do that
in order to see a real time output.
You know, rather than having a team,
you know log in to the management console
and sit there and look at that one screen waiting,
they could have these kind of notifications
through the simple notification service,
piped into something like Slack.
So you know, you can continue working in your IDE
on one screen, have Slack on another
and then you know, just glance over and see.
You know, event, event, event, successfully created.
So we'll go next and we'll review that,
yes single VPC with two public and two private subnets.
There is the Cidre, there are my tags,
right so let's go ahead and create that
and you'll see now create in progress
and we can always refresh there.
We don't have to refresh the whole screen
and you can see it has started the creating of the VPC.
Again because it, cloud formation inherently knows
that the subnets depend on the VPC.
In other cases it might not know that
and in other cases, you know for example,
if you had an EC2 instance and an RDS instance
in the same template,
there's nothing inherent about those two
that says one comes before the other so it
would probably try to create them both at the same time.
But you can control that.
You can explicitly state, hey,
this EC2 instance depends on my RDS instance.
Which means that you would want,
you know you could force cloud formation
to build one thing before another.
All right, so there we go just like that
and very quickly it created all,
there are all of our subnets,
it says create complete and then the stack itself,
fundamental VPC, create complete.
And so then if we go to stack info, create complete.
Let's go to events,
and there are all of that,
let's go to resources, there we go.
And now we can see here is the physical ID,
but if we were to click on that,
this would take us to VPC right,
so let's go ahead and do that and that will take us
to the VPC console dashboard.
And now we can see the details about that VPC.
And so if you recall from the earlier demo,
there was a lot more work involved
to essentially do the same thing, right,
to create a VPC and then create subnets,
it took us click by click, screen by screen,
typing things in and
even in that regard we only created two subnets.
And so here with cloud formation
we created a VPC with four subnets
and a fraction of the time and now
they're all managed underneath this one stack.
And so if I decide at some point,
if this were a temporary environment,
if I decided that I don't need it anymore,
then all I have to do is say delete stack.
Or if I wanted to make a change,
if I decided you know what, I wanna add
two more subnets, one more public and one more private,
then I could make that change in my code,
come back here and update the stack.
You can also see the outputs,
So this is that one place where I said
you know, there may be certain pieces of information
that we want centralized in one place
and so here's all that information,
but you can also see that it's being exported
which means that because it's exported,
we can then use this value,
we can use these values to import into another stack.
It allows us to help organize stacks
so we're not putting like I mention earlier,
we're not putting a whole bunch of resources in one stack.
All right, and then we can also see the template here.
You can see the parameters that were used for this
and then of course because this is
a generalized template I could launch it again
and use 10 dot three, 10 dot four,
and so on and create the same kind of infrastructure
over and over again, but with different values.
If I wanted to duplicate this whole thing
in another region I can do that very easily, right.
So again, the takeaway from this is that
the only way to truly realize all the benefits of AWS,
not just the cost savings, but the agility,
the flexibility, the efficiency,
the only way to realize that is through automation.
Right, so again we did things manually in earlier demos
to prove concepts and try to understand concepts
about those service, but this is where the real power is.
Automation.
And again it doesn't have to be cloud formation right.
So again I would encourage you to really explore the world
not just AWS but automating through tools
like cloud formation or third party tools
like Terraform, Ansible and so on.