Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

Now let's look at another example.

This looks more complex, but we're going to use the same process to identify the correct answer.

So this is a multi-select question and we're informed that we need to pick two answers, but we're still going to follow the same process.

The first step is to check if we can eliminate any of the answers immediately.

Do any of the answers not make sense without reading the question?

Well, nothing immediately jumps out as wrong, but answer E does look strange to me.

It feels like it's not a viable solution.

I can see the word encryption mentioned and it's rare that I see lambda and encryption mentioned in the same statement.

So at this stage, let's just say that answer E is in doubt.

So it's the least preferred answer at this point.

So keep that in your mind.

It's fine to have answers which you think are not valid.

We don't know enough to immediately exclude it, but we can definitely say that we think there's something wrong with it.

Given that we need to select two answers out of the five, we don't need to worry about E as long as there are two potentially correct answers.

So let's move on.

Now, the real step one is to identify what matters in the question text.

So let's look at that.

Now, the question is actually pretty simple.

It gives you two requirements.

The first is that all data in the cloud needs to be encrypted at rest.

And the second is that any encryption keys are stored on premises.

For any answers to be correct, they need to meet both of these requirements.

So let's follow a similar process on the answer text first looking for any word fluff and then looking for keywords which can help identify either the correct answers or more answers that we can exclude.

So the first three answers, they all state server side encryption, but the remaining two answers don't.

And so the first thing that I'm going to try to do with this question is to analyze whether server side encryption means anything.

Does it exclude the answers or does it point to those answers being correct?

Well, server side encryption means that S3 performs the encryption and decryption operations.

But depending on the type of server side encryption, it means that S3 either handles the keys or the customer handles the keys.

But at this stage, using server side encryption doesn't mean that the answers are right or wrong.

You can use it or you can't use it.

That doesn't immediately point to correct versus incorrect.

What we need to do is to look at the important keywords.

Now, if we assume that we are excluding answer E for now unless we need it, then we have four different possible answers, each of which is using a different type of encryption.

So I've highlighted these.

So we've got S3 managed keys, SSE-S3, KMS managed keys, which is SSE-KMS, customer provided keys, which is SSE-C, and then using client side encryption.

Now, the first requirement of the question states encryption at rest and all of the answers A, B, C and D, they all provide encryption at rest.

But it also states that encryption keys are to be stored on premises.

Answers A and B use server side encryption where AWS handle the encryption process and the encryption keys.

So SSE-S3 and SSE-KMS both mean that AWS are handling the encryption keys.

And because of this, the keys are not stored on premises and so they don't meet the second criteria in the question.

And this means that they're both invalid and can be excluded.

Now, this leaves answers C, D and E, and we already know that we're assuming that we're ignoring answer E for now and only using it if we have to.

So we just have to evaluate if C and D are valid.

And if they are, then those are the answers that we select.

So SSE-C means that the encryption is performed by S3 with the keys that the customer provides.

So that works.

It's a valid answer.

So that means at the very least C is correct.

It can be used based on the criteria presented by the question.

Now, answer D suggests client side encryption, which means encrypting the data on the client side and just passing the encrypted data to S3.

So that also works.

So answers C and D are both potentially correct answers.

So both answers C and D do meet the requirements of the question.

And because of this, we don't have to evaluate answer E at all.

It's always been a questionable answer.

And since the question only requires us to specify two correct answers, we can go ahead and exclude E.

And that gives us the correct answers of C and D.

So that's another question answered.

And it's followed the same process that we used on the previous example.

So really answering questions within AWS is simply following the same process.

Try and eliminate any crazy answers.

So any answers that you can eliminate based just on the text of those answers, then exclude them right away because it reduces the cognitive overhead of having to pick between potentially four correct answers.

If you can eliminate the answers down to three or two, you significantly reduce the complexity of the question.

The next step is to find what really matters in the question, find the keywords in both the preamble and the question.

Then highlight and remove any question fluff.

So anything in the question which doesn't matter, eliminate any of the words which aren't relevant technically to the product or products that you select.

So this is something that comes with experience, being able to highlight what matters and what doesn't matter in questions.

And the more practice that you do, the easier this becomes.

Next, identify what really matters in the answers.

So again, this comes down to identifying any shared common words and removing those and then identifying any of the keywords that occur in the answers.

And then once you've got the keywords in the answers and the keywords in the questions, then you can eliminate any bad answers that occur in the question.

Now, ideally at this point, what remains are correct answers.

You might start off with four or five answers.

You might eliminate two or three.

The question asks for two correct answers.

And that's it.

You've finished the question.

But if you have more answers than you need to provide, then you need to quickly select between what remains and you can do that by doing this keyword matching.

So look for things which stand out.

Look for things which aren't best practice according to AWS.

Look for things which breach a timescale requirement in the question.

Look for things which can't perform at the levels that the question requires or that cost too much based on the criteria and the question.

Essentially, what you're doing is looking for that one thing that will let you eliminate any other answers and leave you with the answers that the question requires.

Generally, when I'm answering most questions, it's a mixture between the correct answer jumping out at me and eliminating incorrect answers until I'm left with the correct answers.

You can approach questions in two different ways.

Either looking for the correct answers or eliminating the incorrect ones.

Do whichever works the best for you and follow the same process throughout every question in the exam.

The one big piece of advice that I can give is don't panic.

Everybody thinks they're running out of time.

Most people do run out of time.

So follow the exam technique process that I detailed in the previous lesson to try and get you additional time, leave the really difficult questions until the end, and then just follow this logical process step by step through the exam.

Keep an eye on the remaining amount of time that you have at every point through the exam and I know that you will do well.

Most people fail the exam because of their exam technique, not their lack of technical capability.

With that being said, though, that's everything I wanted to cover in this set of lessons.

Good luck with the practice tests.

Good luck with the final exam.

And if you do follow this process, I know that you'll do really well.

With that being said, though, go ahead and complete this video and then when you're ready, I'll look forward to joining you in the next.

Welcome back and from the very start this course has been about more than just the technical side.

So this is part one of a two-part lesson set and in this lesson I'll focus on some exam technique hints and tips that you might find useful in the exam.

Now in terms of the exam itself it's going to have questions of varying levels of difficulty and this is also based on your own strengths and weaknesses.

Conceptually though understand that on average the AWS exams will generally feel like they have 25% easy questions, 50% medium questions and 25% really difficult questions.

Assuming that you've prepared well and have no major skill gaps this is the norm.

For most people this is how it feels.

The problem is the order of the difficulty is going to feel random so you could have all of your easy ones at the start or at the end or scattered between all of the other questions and this is part of the technique of the AWS exams how to handle question difficulty in the most efficient way possible.

Now I recommend conceptually that my students think of exams in three phases.

You want to spend most of your time on phase two.

So structurally in phase one I normally try to go through all of the 65 questions and identify ones that I can immediately answer.

You can use the exam tools including mark for review and just step through all of the questions on the exam answering anything that's immediately obvious.

If you can answer a question within 10 seconds or have a good idea of what the answer will be and just need to consider it for a couple more seconds this is what I term a phase one question.

Now the reason that I do these phase one questions first is that they're easy they take very little time and because you know the subject so well you have a very low chance of making a mistake.

So once you've finished all of these easy questions the phase one questions what you're left with is the medium or yellow questions and the hard or red questions.

My aim is that I want to leave the hard questions until the very end of the test.

They're going to be tough to answer anyway and so what I want to do at this stage in phase two is to go through whatever questions remain so whatever isn't easy and I'm looking to identify any red questions and mark them for review and then just skip past them.

I don't want to worry about any red questions in phase two.

What phase two is about is powering through the medium questions.

These will require some thought but they don't scare you they're not impossible.

The medium questions so the yellow questions should make up the bulk of the time inside the exam.

They should be your focus because these are the questions which will allow you to pass or fail the exam.

For most people the medium questions represent the bulk of the exam questions.

Generally your perception will be that most of the questions will be medium.

There'll be some easy and some hard so you need to focus in phase two which represents the bulk of the exam on just these medium questions.

So my suggestion generally is in phase two you've marked the hard questions for review and just skipped past them and then you focused on the medium questions.

Now after you've completed these medium questions you need to look at your remaining time and it might be that you have 40 minutes left or you might only have four minutes or even less.

In the remaining time that you have left you should be focusing on the remaining red questions the difficult questions.

If you have 40 minutes left then you can take your time.

If you have four minutes you might have to guess or even just click answers at random.

Now both of these approaches are fine because at this point you've covered the majority of the questions.

You've answered all of the easy questions and you've completed all of the medium questions.

What remains are questions that you might get wrong regardless but because you've pushed them all the way through to the end of your time allocation whether you're considering them carefully and answering them because you have 40 minutes left or whether you're just answering them at random they won't impact your process in answering the earlier questions.

So if you don't follow this approach what tends to happen is you're focusing really heavily on the hard questions at the start of the exam and that means that you run out of time towards the end but if you follow this three-stage process by this point all that you have left is a certain number of minutes and a certain set of really difficult questions and you can take your time safe in the knowledge that you've already hopefully passed to the exam based on the easy and medium questions and the hard ones as simply a bonus.

Now at a high level this process is designed to get you to answer all of the questions that you're capable of answering as quickly as possible and leave anything that causes you to doubt yourself or that you struggle with to the end.

So pick off the easy questions, focus on the medium and then finish up with the really hard questions at the end.

I know that it sounds simple but unless you focus really hard on this process or one like it then your actual exam experience could be fairly chaotic.

If you're unlucky enough to get hard questions at the start and you don't use a process like this it can really spoil your flow.

So before we finish this lesson just some final hints and tips that I've got based on my own experiences.

First if this is your first exam assume that you're going to run out of time.

Most people enter the exam not having an understanding of the structure and most people myself included with my first exam will run out of time.

The way that you don't run out of time and the way that you succeed is to be efficient, have a process.

Now assuming that you have the default amount of time you need to be aware that you have two minutes to read the question, read the answers and to make a decision.

So this sounds like a lot but it's not a lot of time to do all of those individual components.

You shouldn't be guessing on any answers until the end.

If you're guessing on a question then it should be in the hard question category and you should be tackling this at the end.

I don't want you guessing on any easy questions or any medium questions.

If you're guessing then you shouldn't be looking at it until right at the very end.

Another way of looking at this is if you are unsure about a question or you're forced to guess early on you need to be aware that a question that's later on so further on in the exam might prompt you to remember the correct answer for an earlier question.

So if you do have to guess on any questions then use the mark for review feature.

You can mark any question that you want for review as you go through the course and then at any point or right at the end you can see all the questions which are flagged for review and revisit them.

So use that feature it can be used if you're doubtful on any of the answers or you want to prompt yourself as with the hard questions to revisit them toward the end of the exam.

Now this should be logical but take all the practice tests that you can.

One of my favorite test vendors in the space is the team over at TutorialsDojo.com.

They offer a full range of practice questions for all of the major AWS exams so definitely give their site a look.

One of the benefits of the exam questions created over at TutorialsDojo is that they are more difficult than the real exam questions so they can prepare you for a much higher level of difficulty and by the time you get into the exam you should find it relatively okay.

So my usual method is to suggest that people take a course and then once they've finished the course take the practice test in the course, follow that up with the tutorials Dojo practice tests and for any questions they get wrong it can identify areas that they need additional study.

So rinse and repeat that process, perform that additional study, redo the practice tests and when you're regularly scoring above 90% on those practice tests then you're ready to do the real exam.

And at this point there are all of my suggestions for exam technique.

In the next lesson I want to focus on questions themselves because it's the questions and your efficiency during the process of answering questions which can mean the difference between success and failure.

So go ahead complete this video and in the next video when you're ready we'll look at some techniques on how you can really excel when tackling exam questions.

Welcome back and in this lesson I want to talk about a few related features of CloudFormation and those are weight conditions, creation policies and the CFN signal tool.

So let's jump in and get started straight away.

Before we look at all of those features as a refresher I want to step through what actually happens with the traditional CloudFormation provisioning process and let's assume that we're building an EC2 instance and we're using some user data to bootstrap WordPress.

Well if we do this the process starts with logical resources within the template and the template is used to create a Cloud Formation stack.

Now you know by now that it's the job of the stack to take the logical resources in a template and then create, update or delete physical resources to match them within an AWS account.

So in this case it creates an EC2 instance within an AWS account.

From CloudFormation's perspective in this example it initiates the creation of an EC2 instance so when EC2 reports back that the physical resource has completed provisioning the logical resource changes to create complete and that means everything's good right?

Well the truth is we just don't know.

With simple provisioning when the relevant system EC2 in this case tells CloudFormation that it's finished then CloudFormation has no further access to any other information beyond the fact that EC2 is telling it that that resource has completed its provisioning process.

With more complex resource provisions like this one where bootstrapping goes on beyond when the instance itself is ready then the completion state isn't really available until after the bootstrapping finishes and even then there's no built-in link to communicate back to CloudFormation whether that bootstrapping process was successful or whether it failed.

An EC2 instance will be in a create complete state long before the bootstrapping finishes and so even when it's finished if it fails the resource itself still shows create complete.

Creation policies, weight conditions and CFN signal provide a few ways that we can get around this default limitation and allow systems to provide more detailed signals on completion or not to CloudFormation.

So let's have a look at how this works.

The way that this enhanced signaling is done is via the CFN signal command which is included in the AWS CFN bootstrap package.

The principle is simple enough you configure CloudFormation to hold or pause a resource and I'll talk more about the ways that this is done next but you configure CloudFormation to wait for a certain number of success signals.

You want to make it so that resources such as EC2 instances tell CloudFormation that they're okay.

So in addition to configuring it to wait for a certain number of success signals you also configure a timeout.

This is a value in hours, minutes and seconds within which those signals can be received.

Now the maximum permitted value for this is 12 hours and once configured it means that a logical resource such as an EC2 instance will just wait.

It won't automatically move into a create complete state once the EC2 system says that it's ready.

Instead if the number of success signals that you define is received by CloudFormation within the timeout period then the status of that resource changes into create complete and the stack process continues with the knowledge that the EC2 instance really is finished and ready to go because on the instance you've configured something to explicitly send that signal or signals to CloudFormation.

CFN signal is a utility running on the instance itself actually sending a signal back to the CloudFormation service.

Now if CFN signal communicates a failure signal suggesting that the bootstrapping process didn't complete successfully then the creation of the resource in the stack fails and the stack itself fails.

So that's important to understand CFN signal can send success signals or failure signals and a failure signal explicitly fails the process.

Now another possible outcome of this is the timeout period can be reached without the required number of success signals and in this situation CloudFormation views this as an implicit failure.

The resource being created fails and then logically the stack fails the entire process that it's doing.

Now the actual thing which is being signaled using CFN signal is a logical resource specifically a resource such as EC2 or auto scaling groups which is using a creation policy or a specific type of separate resource called a weight condition resource.

Now AWS suggests that for provisioning EC2 and auto scaling groups you should use a creation policy because it's tied to that specific resource that you're handling but you might have other requirements to signal outside of a specific resource.

For example if you're integrating CloudFormation with an external IT system of some kind in that case you might choose to use a weight condition and next I want to visually step through how both of these work because it will make a lot more sense when you see the architecture visually.

Let's start with the example of an auto scaling group which uses a launch configuration to launch three EC2 instances.

These are within a template and that's used to create a stack.

Because I'm using a creation policy here a few things happen which are different to how CloudFormation normally functions.

First the creation policy here adds a signal requirement and timeout to the stack.

In this case the stack needs three signals and it has a timeout of 15 minutes to receive them.

So the EC2 instances are provisioned but because of the creation policy the auto scaling group doesn't move into a create complete state as normal.

It waits.

It can't complete until the creation policy directive is fulfilled.

The user data for the EC2 instances contains some bootstrapping and then this CFN signal statement at the bottom.

So once the bootstrapping process whatever it is has been completed and let's say that it's installing the Categorum application well the CFN signal tool signals the resource in this case the auto scaling group that it's completed the build.

So this CFN signal that's at the bottom left of your screen this is an actual utility which runs on the EC2 instance as part of the bootstrapping process.

And this causes each instance to signal once and the auto scaling group resource in the stack requires three of these signals within 15 minutes.

If it gets them all and assuming that they're all success signals then the stack moves into a create complete state.

If anything else happens so maybe a timeout happens or maybe one of the three instances has a bug then it will signal a failure and in any of those cases the stack will move into a create failed state.

Creation policies are generally used for EC2 instances or for auto scaling groups and if you do any of the advanced demo lessons in any of my courses you're going to see that I make use of this feature to ensure resources which are being provisioned are actually provisioned correctly before moving on to the next stage.

Now there are situations when you need some additional functionality maybe you want to pass data back to cloud formation or want to put general wait states into your template which can't be passed until a signal is received and that's where wait conditions come in handy.

Wait conditions operate in a similar way to creation policies.

A wait condition is a specific logical resource not something defined in an existing resource.

A wait condition can depend on other resources and other resources can also depend on a wait condition so it can be used as a more general progress gate within a template a point which can't be passed until those signals are received.

A wait condition will not proceed to create complete until it gets its signals or the timeout configured on that wait condition expires.

Now a wait condition relies on a wait handle and a wait handle is another logical resource whose sole job is to generate a pre-signed URL which can be used to send signals to.

It's pre-signed so that whatever using it doesn't need to use any AWS credentials they're included in the pre-signed URL.

So let's say that we have an EC2 instance or external server.

These are responsible for performing a process maybe some final detailed configuration or maybe they assign licensing something which has to happen after a part of the template but before the other part.

So these generate a JSON document which contains some amazing information or some amazing occurrence.

This is just an example it can be as complex or as simple as needed.

This document is passed back as the signal it has a status, a reason, a unique ID and some data.

Now what's awesome about this is that not only does this signal allow resource creation to be paused and then continued when this event has occurred but the data which has passed back can also be accessed elsewhere in the template.

We can use the get at function to query for the data attribute of the wait condition and get access to the details on the signal.

Now this allows a small amount of data exchange and processing between whatever is signaling and the cloud formation stack.

So you can inject specific data about a given event into the JSON document, send this back as a signal and then access this elsewhere in the cloud formation stack and this might be useful for certain things like licensing or to get additional status information about the event from the external system.

And that's wait conditions.

In many ways they're just like creation policies.

They have the same concept.

They allow a specific resource creation to be paused, not allowing progress until signaling is received.

Only wait conditions they're actually a separate resource and can use some more advanced data flow features like I'm demonstrating here.

AWS recommend creation policies for most situations because they're simpler to manage but as you create more complex templates you might well have need to use wait conditions as well and for the exams it's essential that you understand both creation policies and wait conditions which is why I wanted to go into detail on both.

Now that's all of the theory that I wanted to cover about creation policies and wait conditions and these are both things that you're going to get plenty of practical experience of in various demo lessons in all of my courses but I wanted to cover the theory and the architecture so that you can understand them when you come across them in those demos.

For now though thanks for watching go ahead and complete this video and when you're ready I'll look forward to you joining me in the next.

Welcome back to stage 5 of this advanced demo series.

And in this stage you're going to be adding a load balancer and auto scaling group to provision and terminate instances automatically based on the load of the system.

By adding a load balancer you'll also abstract connections away from individual instances which will allow elastic scaling and self-healing if any of the instances have problems.

Now the first step to moving towards this elastic architecture is to create the load balancer.

To do that move to the EC2 console, scroll down and toward the bottom under load balancing click on load balancers.

Go ahead and click on create load balancer and it's going to be an application load balancer that we're creating.

So click on create.

We're going to be calling the load balancer A4L WordPress ALB.

It's going to be an internet facing load balancer which means the nodes of the load balancer will be allocated with public IP addressing.

And we want the IP address type for this demonstration to be IP version 4.

Okay so now we need to select the subnets that the load balancer nodes will be placed into.

So first make sure that the animals for life VPC is selected so A4L VPC.

And then check the box next to US East 1A, 1B and 1C.

For US East 1A I want you to select the SN-PUB-A which is the public subnet inside Availability Zone A so US East 1A.

For US East 1B I want you to select the public subnet in AZB so SN-PUB-B.

And then lastly for US East 1C we'll be selecting the SN-PUB-C.

So this configures the subnets that the load balancer nodes will be placed into because they're public subnets and because we have the scheme set to internet facing these nodes will be provided with public IP addressing.

Next under security groups click on the cross to delete the default security group.

And then click in the drop down and go ahead and select A4L VPC-SG load balancer.

Now there will be some random afterwards that's okay just make sure you select A4L VPC-SG load balancer.

Now scroll down and under listeners and routing make sure that the protocol is set to HTTP and the port is set to 80.

Application load balancers work using target groups and so we need to define a target group to forward the traffic to.

Now we don't currently have any target groups which have been created so we need to go ahead and click on create target group.

Now under basic configuration the target type is going to be instances so make sure that that's selected.

Under target group name just enter A4L WordPress ALBTG.

Scroll down further still make sure the protocol is set to HTTP and port is set to 80 on this screen as well.

Make sure the VPC is set to A4L VPC.

The protocol version by default should be HTTP1 you can leave that as the default.

Under health checks make sure the health check protocol is HTTP and the health check path is forward slash.

Once that's set go ahead and click next.

Now we won't be adding any instances to the target group these can either be added manually or a target group can be integrated with an autoscaling group and that's something that we'll be configuring later in this advanced demo.

For now just scroll down to the bottom and click create target group.

Then go back to the previous tab click on the refresh icon and then select the A4L WordPress ALBTG from the drop down.

Now we won't be picking any add-on services so you don't need to check the AWS global accelerator.

Just scroll down to the bottom and click create load balancer.

Next click on view load balancer and then select the load balancer that you've just started creating and we'll need to create another parameter in the parameter store so we'll need the DNS name of the load balancer.

So go ahead and click on the little symbol next to that to copy that into your clipboard.

Next you'll need to move back to the parameter store.

Now because we're automating this environment we need to provide a way so that all of the EC2 instances know the DNS name of the load balancer because this will be used as a workaround to the fact that the IP addresses are hard coded into the database so we need to provide an automatic way of exposing the load balancer DNS name to the EC2 instances.

Click on create parameter for the parameter name forward slash A4L forward slash WordPress forward slash ALB for application load balancer and then DNS name so forward slash A4L forward slash WordPress forward slash ALB DNS name for description put DNS name of the application load balancer for WordPress.

We're going to be picking a standard tier parameter.

It's going to be a string parameter.

It's going to be a text for data type and in value go ahead and paste the DNS name of the load balancer which you just copied into your clipboard scroll down to the bottom and click on create parameter.

Now the next thing we're going to do is to update the launch template and this is quite a complex update so you need to understand exactly what we're doing.

Currently and I've mentioned this a few times throughout this demo series the IP address of the first EC2 instance that's used for a WordPress deployment is hard coded into the database.

Now this is fine if it's a static IP address but if it's not or if you're using multiple EC2 instances then you can't use IP addresses because they change both on an individual EC2 instance and if you're scaling using multiple instances.

So we need to replace this hard coded value with the DNS name of the load balancer.

So that's what we're going to do.

We're going to update the launch template with some final configuration so that it can adjust this configuration replacing the IP address with the DNS name of the load balancer.

So go back to the EC2 console, click on launch templates, select the WordPress launch template and click on actions modify template create new version.

Under the template version description we're going to use app only, users EFS file system defined in /a4l/wordpress/efs/fsid and then ALB home added to the WP database.

So we're going to make some on the fly adjustments to the WordPress database when every instance is provisioned to make sure that the load balancer DNS name is set to be the home URL for WordPress.

So again scroll all the way down to the bottom because we're using an older template as the foundation for this one.

All of the values will be pre-populated.

Expand advanced details and scroll all the way down to user data and then just expand this text entry to make it slightly easier to interact with.

As with the previous step position your cursor at the end of this top line and press enter twice.

We need to add the first two lines of script which will bring in the application load balancer DNS name into an environment variable using systems manager parameter store.

So now this instance when it's provisioning has the DNS name of the load balancer.

Now next move all the way down to the bottom of this user data.

So the last step that we want a machine to do when it's provisioning is to perform this update of the database.

So there's a fairly large block of text which you need to copy from this stages text instructions.

It's stage five and you need to paste this into the bottom of this file.

So right at the bottom after these last two fine statements paste in this block.

So this should start with the cat command on the top line of what you've just pasted in and then all the way down at the bottom.

It should end with forward slash home forward slash EC2 hyphen user forward slash update underscore WP underscore IP dot SH.

Essentially what this does is to bring in the WordPress configuration file to get the current authentication details for the database.

So all these lines at the top are just designed to get the authentication information.

So the DB name, the DB user and the DB password.

This line runs a database script to get the old value for the IP address of the original IP address of the EC2 instance.

So this is pulling in the original hard coded IP address.

Then we're going to take the load balancer DNS name and we're going to run a series of SQL commands to update the database moving from that hard coded IP.

To using the ALB DNS name.

Now what this is actually doing is this line here is creating a script file and it's going to put into this script file everything until this EOF directive.

So scrolling down this means that everything between these two lines is going to be stored in this script.

Then we're going to make the script executable using CHmod 755.

We're going to echo the path to this script into ETC RC.local which is run every time the instance is started up.

And then finally we're going to run this script the once to update this information right here and now.

So this new version of the launch template essentially changes what this hard coded IP address is every time to be the DNS name of the load balancer.

It means if we ever change the DNS name of this load balancer this script will automatically correct this hard coded value.

Now this is a thing specific to WordPress and there are many situations where you'll have applications which have certain nuances that you need to be aware of when creating elastic architectures.

This is the one for WordPress.

So now that we've made these changes go ahead and click on create template version to create that new version of this launch template.

Click on launch template some for the final time we need to update the default version.

So make sure this launch template is selected.

Click on actions scroll down select set default version click in the drop down the current default version is version three we want to select version four so select that and then click set as default version.

Now that means the launch template is updated and we can now provision instances in a fully elastic way.

Okay so this is the end of part one of this lesson.

It was getting a little bit on the long side and I wanted to give you the opportunity to take a small break maybe stretch your legs or make a coffee.

Now part two will continue immediately from this point so go ahead complete this video and when you're ready I look forward to you joining me in part two.

Welcome back to stage 5 of this advanced demo series.

And in this stage you're going to be adding a load balancer and auto scaling group to provision and terminate instances automatically based on the load of the system.

By adding a load balancer you'll also abstract connections away from individual instances which will allow elastic scaling and self-healing if any of the instances have problems.

Now the first step to moving towards this elastic architecture is to create the load balancer.

To do that move to the EC2 console, scroll down and toward the bottom under load balancing click on load balancers.

Go ahead and click on create load balancer and it's going to be an application load balancer that we're creating.

So click on create.

We're going to be calling the load balancer A4L WordPress ALB.

It's going to be an internet facing load balancer which means the nodes of the load balancer will be allocated with public IP addressing.

And we want the IP address type for this demonstration to be IP version 4.

Okay so now we need to select the subnets that the load balancer nodes will be placed into.

So first make sure that the animals for life VPC is selected so A4L VPC.

And then check the box next to US East 1A, 1B and 1C.

For US East 1A I want you to select the SN-PUB-A which is the public subnet inside Availability Zone A so US East 1A.

For US East 1B I want you to select the public subnet in AZB so SN-PUB-B.

And then lastly for US East 1C we'll be selecting the SN-PUB-C.

So this configures the subnets that the load balancer nodes will be placed into because they're public subnets and because we have the scheme set to internet facing these nodes will be provided with public IP addressing.

Next under security groups click on the cross to delete the default security group.

And then click in the drop down and go ahead and select A4L VPC-SG load balancer.

Now there will be some random afterwards that's okay just make sure you select A4L VPC-SG load balancer.

Now scroll down and under listeners and routing make sure that the protocol is set to HTTP and the port is set to 80.

Application load balancers work using target groups and so we need to define a target group to forward the traffic to.

Now we don't currently have any target groups which have been created so we need to go ahead and click on create target group.

Now under basic configuration the target type is going to be instances so make sure that that's selected.

Under target group name just enter A4L WordPress ALBTG.

Scroll down further still make sure the protocol is set to HTTP and port is set to 80 on this screen as well.

Make sure the VPC is set to A4L VPC.

The protocol version by default should be HTTP1 you can leave that as the default.

Under health checks make sure the health check protocol is HTTP and the health check path is forward slash.

Once that's set go ahead and click next.

Now we won't be adding any instances to the target group these can either be added manually or a target group can be integrated with an autoscaling group and that's something that we'll be configuring later in this advanced demo.

For now just scroll down to the bottom and click create target group.

Then go back to the previous tab click on the refresh icon and then select the A4L WordPress ALBTG from the drop down.

Now we won't be picking any add-on services so you don't need to check the AWS global accelerator.

Just scroll down to the bottom and click create load balancer.

Next click on view load balancer and then select the load balancer that you've just started creating and we'll need to create another parameter in the parameter store so we'll need the DNS name of the load balancer.

So go ahead and click on the little symbol next to that to copy that into your clipboard.

Next you'll need to move back to the parameter store.

Now because we're automating this environment we need to provide a way so that all of the EC2 instances know the DNS name of the load balancer because this will be used as a workaround to the fact that the IP addresses are hard coded into the database so we need to provide an automatic way of exposing the load balancer DNS name to the EC2 instances.

Click on create parameter for the parameter name forward slash A4L forward slash WordPress forward slash ALB for application load balancer and then DNS name so forward slash A4L forward slash WordPress forward slash ALB DNS name for description put DNS name of the application load balancer for WordPress.

We're going to be picking a standard tier parameter.

It's going to be a string parameter.

It's going to be a text for data type and in value go ahead and paste the DNS name of the load balancer which you just copied into your clipboard scroll down to the bottom and click on create parameter.

Now the next thing we're going to do is to update the launch template and this is quite a complex update so you need to understand exactly what we're doing.

Currently and I've mentioned this a few times throughout this demo series the IP address of the first EC2 instance that's used for a WordPress deployment is hard coded into the database.

Now this is fine if it's a static IP address but if it's not or if you're using multiple EC2 instances then you can't use IP addresses because they change both on an individual EC2 instance and if you're scaling using multiple instances.

So we need to replace this hard coded value with the DNS name of the load balancer.

So that's what we're going to do.

We're going to update the launch template with some final configuration so that it can adjust this configuration replacing the IP address with the DNS name of the load balancer.

So go back to the EC2 console, click on launch templates, select the WordPress launch template and click on actions modify template create new version.

Under the template version description we're going to use app only, users EFS file system defined in /a4l/wordpress/efs/fsid and then ALB home added to the WP database.

So we're going to make some on the fly adjustments to the WordPress database when every instance is provisioned to make sure that the load balancer DNS name is set to be the home URL for WordPress.

So again scroll all the way down to the bottom because we're using an older template as the foundation for this one.

All of the values will be pre-populated.

Expand advanced details and scroll all the way down to user data and then just expand this text entry to make it slightly easier to interact with.

As with the previous step position your cursor at the end of this top line and press enter twice.

We need to add the first two lines of script which will bring in the application load balancer DNS name into an environment variable using systems manager parameter store.

So now this instance when it's provisioning has the DNS name of the load balancer.

Now next move all the way down to the bottom of this user data.

So the last step that we want a machine to do when it's provisioning is to perform this update of the database.

So there's a fairly large block of text which you need to copy from this stages text instructions.

It's stage five and you need to paste this into the bottom of this file.

So right at the bottom after these last two fine statements paste in this block.

So this should start with the cat command on the top line of what you've just pasted in and then all the way down at the bottom.

It should end with forward slash home forward slash EC2 hyphen user forward slash update underscore WP underscore IP dot SH.

Essentially what this does is to bring in the WordPress configuration file to get the current authentication details for the database.

So all these lines at the top are just designed to get the authentication information.

So the DB name, the DB user and the DB password.

This line runs a database script to get the old value for the IP address of the original IP address of the EC2 instance.

So this is pulling in the original hard coded IP address.

Then we're going to take the load balancer DNS name and we're going to run a series of SQL commands to update the database moving from that hard coded IP.

To using the ALB DNS name.

Now what this is actually doing is this line here is creating a script file and it's going to put into this script file everything until this EOF directive.

So scrolling down this means that everything between these two lines is going to be stored in this script.

Then we're going to make the script executable using CHmod 755.

We're going to echo the path to this script into ETC RC.local which is run every time the instance is started up.

And then finally we're going to run this script the once to update this information right here and now.

So this new version of the launch template essentially changes what this hard coded IP address is every time to be the DNS name of the load balancer.

It means if we ever change the DNS name of this load balancer this script will automatically correct this hard coded value.

Now this is a thing specific to WordPress and there are many situations where you'll have applications which have certain nuances that you need to be aware of when creating elastic architectures.

This is the one for WordPress.

So now that we've made these changes go ahead and click on create template version to create that new version of this launch template.

Click on launch template some for the final time we need to update the default version.

So make sure this launch template is selected.

Click on actions scroll down select set default version click in the drop down the current default version is version three we want to select version four so select that and then click set as default version.

Now that means the launch template is updated and we can now provision instances in a fully elastic way.

Okay so this is the end of part one of this lesson.

It was getting a little bit on the long side and I wanted to give you the opportunity to take a small break maybe stretch your legs or make a coffee.

Now part two will continue immediately from this point so go ahead complete this video and when you're ready I look forward to you joining me in part two.

Welcome back to stage 4 of this advanced demo series.

Now in stage 4, we're going to perform the last step before we can make this a truly elastic and scalable design.

And we're going to migrate the wp-content folder which stores these priceless animal images from the EC2 instance onto EFS which is the elastic file system.

This is a shared network file system that we can use to store images or other content in a resilient way outside of the life cycle of these individual EC2 instances.

So to do that, we need to move back to the AWS console, click on the services drop down and type EFS.

Right click and open the EFS console in a new tab.

Once that's opened, click on create file system.

Now we're going to step through the full configuration options so rather than using this simplified user interface, go ahead and click on customize.

So the first step is to create the file system itself.

So for name, go ahead and call this a4l-wordpress-content.

Leave the storage class as standard.

These cat images are critical data and so we are going to leave automatic backups enabled.

And we're also going to leave life cycle management set to be the default so 30 days since the last access for throughput mode pick bursting which links the throughput to the size of the storage.

Then expand additional settings.

You've got two performance modes, general purpose and max IO.

For this demonstration, go ahead and select general purpose.

Max IO is for very specific high performance scenarios for 99% of use cases.

You should select general purpose.

Now also go ahead and untick enable encryption of data at rest.

If this were a production scenario, you would leave this on.

But for this demo, which is focusing on architecture evolution, it simplifies the implementation if we disable it.

So go ahead and make sure that encryption is disabled.

Once you've done that, that's all of the file system specific options that we need to configure.

So go ahead and click on next.

In this part, you're configuring the EFS mount targets, which are the network interfaces in the VPC, which your instances will connect with.

So in the virtual private cloud drop down, select it and then pick a for L VPC.

So this is the VPC that these mount targets are going to go into.

Now, each of the mount targets is secured by a security group.

The first thing we need to do is to strip off the default security group for the VPC.

So click in the crosses next to each of these security groups.

Now, you should have three rows, one for each availability zone.

So in my case, you are seized one A, one B and one C and make sure that you've got the same selected.

So one row for each availability zone, A, B and C.

Now in the subnet drop down for availability zone one A, I want you to go ahead and pick SN-AP-A.

So this should be 10.16.32.0/20.

For the US East one B row, I want you to go ahead and pick SN-AP-B.

This should be 10.16.96.0/20.

And then finally for US East one C, I want you to go ahead and pick SN-AP-C, which should be 10.16.160.0/20.

Now for all three rows within the security groups drop down, I want you to go ahead and select A4LVPC-SGEFS.

Again, for each of these, it will have some randomness after it, but just make sure you pick the right one.

A4LVPC-SGEFS.

And you need to pick that for each of the three rows.

Make sure you pick the right one because if you don't, it will impact your ability to connect.

So there the mount targets configured and they'll be allocated with an IP address in each of these subnets automatically, which will allow you to connect to them.

At this point, go ahead and click on Next.

You can configure some additional file system policies.

This is entirely optional.

We won't be using that.

So just go ahead and click on Next.

And then on the review screen, scroll all the way down to the bottom and just click on Create.

Now the file system itself will initially show as being in the creating state and it will then change to available.

Go ahead and click on the file system itself.

Click on the Network tab and then just scroll down and these are the mount targets which are being created.

Now in order to configure our EC2 instance, we will need all of these mount targets to be in the available state.

But what we can do to save some time is we can note down the file system ID of this EFS file system.

So this is this value.

You can see it at the top header here or you can see it in this row at the top.

Just note that down and copy that into your clipboard because we need to configure another parameter to point at this file system ID.

Because remember when we're scaling things automatically, it's always best practice to use the parameter store to store configuration information.

So click on Services, type Sys which are the first few letters of Systems Manager and open that in a new tab.

Once you're at the Systems Manager console, go ahead and click on Parameter Store and then you need to click Create Parameter to create a new parameter.

We're going to call this parameter forward slash A4L forward slash WordPress forward slash and then EFS for Elastic File System, FS for File System and then ID.

So EFS File System ID.

For description, put File System ID for WordPress content and then in brackets WP-Content and that will help us know exactly what this parameter is for.

As before, we'll be picking the standard tier, the type will be string, the data type will be text and then into the value, just go ahead and paste that file system ID.

And once you've done all that, you can go ahead and click on Create Parameter.

Once that's done, go back to the EFS console and if required, just hit refresh and make sure that all of these mount targets are in the available state.

This is what it should look like with all three showing a green tick and available.

Once that's the case, go to the EC2 console because now we're going to configure our EC2 instance to connect to this file system.

So go to Running Instances, locate the WordPress -LT instance, right click, select Connect, choose Session Manager and then click on Connect.

And this will open Session Manager console to the EC2 instance.

As always, type shudubash, press Enter, cd and press Enter and then type clear and press Enter again, just to clear the screen making it easier to see.

Now, even though EFS is based on NFS, which is a standard, in order to get EC2 instances to connect to EFS, we need to install an additional tools package.

And to do that, we use this command.

So type or paste that in and press Enter to install the EFS support package.

Once that's installed again, I'm going to clear the screen to make it easier to see.

Then I'm going to move to the Web Root folder by typing cd /vr/www/html.

And what I'm going to do is to move the entire wp-content folder somewhere else.

So if I just go inside this folder to illustrate exactly what it looks like and then do a list, you'll see that inside there are plugins, themes and uploads.

And inside those folders are any media assets used by WordPress.

So I'm just going to type cd /dot/ to move back up a level out of this folder.

And then I'm going to move this entire folder to the /tmp folder, which is a temporary folder.

So mv/wp-content///tmp and that moves that entire folder to the temporary folder.

Then we're going to create a new folder.

So shudu space mkdir space wp-content.

This will be the mount point for the EFS file system.

So I'm making an empty directory.

Then I'm going to clear the screen and then paste in the next two commands from the lesson instructions.

And this populates an environment variable called EFS/FSID with the value from the parameter you just created in the parameter store.

So this is now the file system ID of the EFS file system.

Now there's a file called fstab which exists in the /etc folder.

And inside there it's called fstab and this contains a list of file systems which are mounted on this EC2 instance.

Initially this only has the single line for the boot volume.

What we're going to do is add an additional line to this fstab file.

And this line is going to configure the EC2 instance so that it mounts our EFS file system on boot every single time.

And this is this command.

So it echoes this line.

So the file system ID from the environment variable.

We're going to mount it to the folder that we just created.

So the wp-content folder and these are all of the file system options.

So we're going to put that into the fstab file.

So if we now cap this file it's got this extra line.

And this means this file system will be mounted whenever the operating system starts.

And we can force this just for now by running mount space-a space-t space-efs space-defaults.

And this will mount the EFS file system onto this EC2 instance.

We can verify that by doing a df space-k.

And the bottom line should show us that we've now got this EFS file system mounted as the wp-content folder.

So this is the folder that WordPress expects its media to be inside.

Now all that remains is for us to migrate the existing data that we moved to the temporary folder back in to wp-content.

And to do that we use this command.

So we're using the mv command to move forward slash tmp forward slash wp-content forward slash star.

So any files and folders and then we're moving it back into var www.html wp-content.

So this is the EFS file system.

So run that and that will copy the data back to EFS, which remember is now mounted where WordPress expects it to be.

Now that might take a few moments to complete.

Once it's done, we just need to fix up the permissions.

So run this command chown space-bigr space-ec2-user colon apache space and then slash var slash www.

So this just reestablishes permissions and ownership of everything in this particular part of the file system.

Just make sure we won't have any problems going forward.

Now at this point we're going to use the reboot command to restart this instance.

And if everything goes well, the instance should start, the EFS file system should be loaded and WordPress should have access to all of this wp-content, which is now running from a network file system.

So go ahead type reboot and press enter.

If you press enter just to make sure that you are disconnected and I am.

So that's good.

So now I need to wait a few minutes for this EC2 instance or at least its operating system to restart.

So I'll go ahead and close down this session manager tab.

Go back to the EC2 console.

After waiting a few minutes, I'll right click select connect check session manager click on connect.

Assuming the instance has restarted, I'll be back at the prompt.

And if I do a DF space-k if everything's working as expected, the EFS file system will still be mounted into the directory that we configured.

If I go back to the EC2 console and just copy down the instances public IP version for address, either refresh the tab if you still got it open or paste in the IP address and reload that page.

And if everything's working as expected, all of these high quality critical cat pitches should still load from the WordPress blog.

So now at this point when we're interacting with the application, both the database and the wp-content both exist away from the EC2 instance.

And this means we're now in a position where we can scale the EC2 instance without worrying about the data or the media for any of the posts.

And this means we can now further evolve this architecture to be fully elastic.

Now there is one more thing that we need to do before moving on to the next stage of the demo and implementing this final step towards a fully elastic architecture.

And that's that we need to update the launch template to include this updated configuration so that it uses EFS.

To do that, go back to the EC2 console, go to launch templates, select the launch template.

So check the box, click on the actions drop down, select modify template, create new version.

For template version description, use app only, uses EFS file system defined in and then the parameter store value that contains the file system ID.

So this is just the description.

Now again, because we're creating a new version, it will populate all of the configuration with the previous template version.

But I'll need you to scroll all the way down to the bottom, expand advanced details and scroll all the way down.

Again, we're going to make some edits to the user data.

So expand this box a little bit to make it easier to read.

What I'll need you to do is to put your cursor after the end of this top line and just press enter twice to make some space and then paste in this set of configuration.

And again, this is stored within the instructions for this stage of the demo series that will just populate an environment variable with the file system ID that it will get from the parameter store.

Scroll down and next you're looking for a software installation line.

You're looking for this line, the line that performs the installation of the Maria DB server, the Apache web server and the W get utility.

Position your cursor after the word stress and then press space.

And then I'll want you to add this text followed by a space, which is Amazon hyphen EFS hyphen utils.

Next, scroll down a little bit further and you're looking for the line that says system, CTL, start, HTTBD.

Click on the end to position your cursor at the end of that line and then press enter twice to add some space and then paste in this next block also contained within this lessons instructions.

What this does is to make a WP hyphen content folder before we install WordPress, configure the ownership of the entire folder tree and then add the line for EFS to the FSTAB file and then mount this EFS file system in to VARWWWW/HTML/WP hyphen content.

And this means that when we're automatically provisioning this instance before we install WordPress, we're creating and mounting this EFS file system.

And then we go on to installing WordPress, configuring the database and performing the final fix of all of the permissions at that folder structure.

Next, scroll down.

We're done with all of the launch template user data configuration.

Just go ahead and click on create template version.

We need to make this new version the default.

So click on launch templates, select the WordPress launch template, click on actions, scroll down, select set default version, click in the dropdown.

Version two should currently be the default.

Change that to version three and click set as default version.

So at this point, you further evolved the architecture.

Now we have both the database for WordPress stored in RDS and the WP hyphen content data stored within the Elastic file system.

So we've solved many of the applications limitations.

We can scale the database independently of the application.

We've stored the media files separate from the instance.

So now we can scale the instance freely out or in without risking the media or the database.

We do still have two final limitations which will be fixing together in the next stage of this demo series.

One is that customers still connect to the instance directly so we don't have any health checks.

We don't have any auto healing capabilities and we're limited to how we can scale.

And then finally, the IP address of the instance is still hard coded into the database.

And so even if we did provision additional instances, WordPress would expect all of the data to be loaded from that one single original instance.

And to allow us to scale, we have to resolve both of those problems.

At this point though, you've done everything required in stage four.

So go ahead, complete this video.

And when you're ready, I look forward to you joining me in stage five of this advanced demo series.

Welcome back and in stage three of this demo series, you're going to change the single server architecture that's on screen now and move towards something a little more scalable.

You're going to migrate the database from the EC2 instance into a separate RDS instance and that means each of these can scale independently, so you can grow or shrink the database independently of the EC2 instance.

It also means that the data in the database lives past the lifecycle of the EC2 instance and this is required for later stages in the demo where you want to scale in and out based on load.

So let's go ahead and do that.

So you'll need to be at the AWS console, click on services and in the find services drop down, type RDS and then open that in a new tab.

Now we're going to create a subnet group first and a subnet group is what allows RDS to select from a range of subnets to put its databases inside.

In this case, we'll be giving RDS a selection of three subnets, so SN-DB-A, B and C.

So three availability zones which it can choose to deploy database instances into.

So to do that, look on the left hand menu and just click on subnet groups.

Click on create DB subnet group.

For name, call it WordPress RDS subnet group.

Under description, just type RDS subnet group for WordPress.

In the VPC drop down, select the A4L VPC.

Scroll down a little and then under availability zones, click in the drop down and check the box next to US East 1A, 1B and 1C because we have database subnets in each of those availability zones and these were created as part of the infrastructure cloud formation template that you applied at the start of this advanced demo.

Once you've selected those availability zones, next we need to pick the subnets inside those availability zones that the databases will go into.

So click in the subnets drop down.

Now you could go to the VPC console and get the IP address ranges that correspond to the different database subnets but I'm going to save us some time.

So in US East 1A, you need to pick 10.16.16.0/20.

That's the database subnet in availability zone A.

In availability zone B, you need to pick 10.16.80.0/20.

That's the database subnet in AZB.

And then in US East 1C, you need to pick 10.16.144.0 because that's the database subnet in availability zone C.

So now you've selected the three availability zones, the three subnets in those availability zones so you can scroll down and click on create.

So that creates the database subnet group that RDS uses in order to select which subnets database instances should go into.

The next step is to actually create the RDS instance itself.

And to start with, we're going to use a free tier eligible database.

So go ahead and click on databases, click on create database, select standard create.

RDS is capable of using lots of different database engines, but we're going to select MySQL.

So select MySQL.

Scroll down and under version, put the version number that's inside this lesson's description.

AWS regularly make changes and instead of using the version you see on this video, pick the one that's inside this lesson's description.

Scroll down.

Under templates, click on free tier because this will make sure that we're only selecting options that are eligible under the free tier.

And we want to keep the first part of this demo series completely within the AWS free tier.

Now under DB instance identifier, we need to give this instance a name.

So delete this placeholder and then just enter A4L wordpress.

Now for master username and password, we need to enter the values from the parameter store that we entered previously.

So click on services, start typing sys and then right click on systems manager and open in a new tab.

Go to the parameter store, look for the DB user parameter and then copy what's in the value field and then go back to the RDS console and paste that in for master username.

So that should be A4L wordpress user.

Do the same for the master password.

So for that, you need to go back to parameter store and this time you're looking for A4L wordpress DB password.

So select that.

Once you're here, click on show and then copy the value for this parameter.

Once you've got that value, paste it into both the master and confirm password boxes.

Scroll down further still and now you need to pick the database instance size.

Now because we've selected free tier eligible, we can only select DB.t3.micro.

Or in some cases, this may be slightly different, but it's only going to allow you to pick free tier eligible instance types.

So we can leave that selected.

It is the default because we picked free tier only.

Now scroll down to connectivity.

Under the virtual private cloud VPC, click in the drop down and select the A4L VPC.

So this defines the VPC that this database is going into.

Once you've selected that, make sure for subnet group, you've got WordPress RDS subnet group selected.

Choose no for publicly accessible and then for existing VPC security groups, I want you to go ahead and click on the cross next to default and then click in the drop down and select A4L VPC - SG database.

And again, this will have some randomness on the end, but that's perfectly okay.

So select A4L VPC - SG database.

Under availability zone preference, select US East 1A.

This makes sure this database just to start off with is in the same availability zone as the EC2 instance.

Scroll down further still, go past database authentication and then expand additional configuration.

And this is important because we need to set an initial database name.

So for the initial database name, we'll need to go back to the parameter store.

This time we need the value for the A4L WordPress DB name parameter.

So select that and then copy its value.

So copy that into the clipboard, go back to the RDS console and paste that in for the initial database name.

And that should be A4L WordPress DB.

At this point, we can leave everything else as default.

So scroll all the way down to the bottom and click on create database.

Now this can take anywhere up to 30 minutes to create the database and it will need to be fully ready before you move on to the next step.

So now's a great time to pause this video, go and grab a coffee and wait for this database to become available, at which point you can resume the video.

Now that this database instance is available, the next thing to do is to migrate the actual WordPress data.

And to do that, we need to move back to the EC2 console.

So open the EC2 console, locate WordPress -LT and then select that instance, right click, select connect, choose session manager and then click on connect.

We're going to perform the migration from this instance itself.

To start with run shudu space bash and press enter, cd and press enter and then type clear and press enter.

We're going to be running some commands which are in the text instructions for this stage of the demo series.

The first set of commands will load data from the parameter store into environment variables within the operating system.

So go ahead and copy all of the first block of commands and paste it in to this terminal.

This will load the DB password, the DB root password, DB user, DB name and DB endpoint all into environment variables and make sure to press enter on the last line just to complete that command.

Next we're going to export the data from the local MariaDB database instance and we'll do that using this command.

So mysqldump -h space and then uses these environment variables.

So the database endpoint which will be local host and then a space -u and then a space and then the database user which is also an environment variable and then a space -p and then DB password which is an environment variable and then a space and then DB name which is also an environment variable.

And then we direct the output of this command into a file called a4lwordpress.sql which is a database export file.

So the best way is to copy and paste this out of the lesson instructions and then press enter and then run an ls space -la and just make sure that you've got that a4lwordpress.sql file and this is an output of the current sqldatabase for WordPress.

Now next we need to change the parameter in parameter store for DB endpoint so that it points at our new RDS instance.

So go back to the RDS console, click on the a4lwordpress instance and then copy this endpoint name into your clipboard.

So it should start with a4lwordpress and then some random and then the region and then RDS and then amazonaws.com.

So copy all of that into your clipboard and then either open the systems manager console and go to the parameter store or if you still got it open in a previous tab then you can open that tab.

So click on parameter store to list all the parameters.

Now at this point we're going to delete one of these parameters and it needs to be a deletion because we're going to recreate it.

Please make sure that you do delete it and recreate it rather than just editing the value for the existing parameter because that won't work.

You'll need to select the checkbox next to a4lwordpress.db endpoint and then click on delete.

And once you've done that click on delete parameters to confirm that deletion and we're going to create a new parameter with the same name.

So click on create parameter for name put forward slash a4lwordpress/db endpoint which is the same name as before.

For description put WordPress endpoint name.

We're going to use the standard tier again.

It's going to be a string type.

The data type is going to be text and then in the value paste in the RDS endpoint that you just copied into your clipboard.

And once you've done that scroll down and click on create parameter.

Go back to the session manager tab that you've got open to the instance and we need to refresh the environment variable with the updated parameter store parameter.

So to do that copy and paste this next block of commands and this updates the db endpoint with the new RDS DNS name.

Once we've updated that then we can run the mysql command to load in the a4lwordpress.sql export into the RDS instance and that's using this command.

So again mysql -h space and then the RDS endpoint name which is in that environment variable and then specifying the db user db password and db name and then directing the command to load in the contents of this file.

So if we paste all that in and press enter that imports that database export into RDS.

So now RDS has the same data as our local Maria db installation.

Now to finalize the migration we need to update the wordpress configuration file.

So instead of pointing at the local Maria db instance it points at RDS.

And we can do that using sed and perform a replace of local host with the contents of the db endpoint environment variable which remember now contains the DNS name for the RDS instance.

And the location of the file that will be performing this replace on is /var/www/html/wp-config.php which is the wordpress configuration file.

So paste that in and press enter and that's reconfigured wordpress now so that it talks to the RDS instance for the database functionality.

Lastly we can run these commands to both disable Maria db so it doesn't start every time the operating system boots and set it to stopped right now.

So now Maria db is no longer running on this EC2 instance.

So we can verify that the functionality of our application is still there by going back to the EC2 console.

Selecting wordpress -lt just copy this public IP address into your clipboard.

If you already have it open in an existing tab you can refresh.

It should still load the blog and yet we've still got the same best animals blog post.

But now wordpress is loading the data for this blog post from the RDS instance.

Now to be really clear at this point wordpress when you create a blog post has two different sets of data.

It has the data of the blog post so the text, the metadata, the author, the date and time, the permissions, the published status and many other things they're stored in the database.

But any media, any content for this blog post is still stored locally in a directory called wp-content.

That is still on the EC2 instance or that we've migrated in this stage of the demo is the database itself from Maria db through to RDS.

Now before we finish with this stage of the demo series there's one final task and that's to update the launch template so we can launch additional EC2 instances.

But using this new configuration so pointing at the RDS instance.

So to do that go back to the EC2 console and click on launch templates.

Click in the checkbox next to the wordpress launch template.

Select the actions drop down and then locate and click modify template create new version.

Now for the description we're going to put single server app only.

So we're indicating with this version of the launch template we no longer have the database inside the instance itself.

Now because we're creating this from a previous version all of the boxes will be pre-populated.

What we need to do is to update the user data.

So go all the way down to the bottom and expand advanced details scroll all the way down to the bottom of that and find the user data box.

And I find it's easier if we just expand it to make it slightly easier to see.

There are a number of things which we need to adjust in this user data.

First just scroll down and you need to locate this block of commands.

So system CTL enable and system CTL start.

What we need to remove are the lines that refer to MariaDB.

So the top one is system CTL enable MariaDB select that and delete and then locate system CTL start MariaDB select that and delete.

So that prevents MariaDB starting on the EC2 instance.

Now because we're using an RDS instance we also need to remove this line which attempts to set the root password of the MariaDB database instance.

We don't need that anymore so delete that.

Scroll all the way down to the bottom and look for this block.

So it starts with echo create database DB name and it finishes with RM/TMP/DB.setup.

This is the block that creates the database within MariaDB, creates the user and sets all of the permissions.

But because we're using RDS now we don't need to do any of this so we're going to delete this block as well.

Once you've done that you can go ahead and click on create template version and this will create a new version but this time designed to use RDS.

Once you've done that go back to the launch template screen and click on the launch template.

We need to change it so that the new version is the default version that's used whenever we launch instances from this template.

So click on the launch template.

Once that's loaded you'll see we're currently on version one.

Change this to version two and you'll see the updated details and then click on the actions drop down.

Select set default version.

In the dialogue make sure that version two is shown under template version and then click on set as default version.

And at this point version two or the one which uses RDS is now set as default and this means when we use this template to launch any instances this is the version that will be used by default.

Now at this point that's everything that I wanted you to do in stage three of this demo series.

So you've migrated the data for a working WordPress installation from a local MariaDB database instance through to RDS.

And that's essential to be able to scale this application because now the data is outside of the lifecycle of the EC2 instance.

So we know that for any scale in or out events it won't impact the relational or SQL based data.

It also means that we can scale the database independently of the WordPress application instances.

So that helps us reach the desired outcome of a fully elastic architecture.

Now at this point we've actually fixed many of the limitations of this design.

At this point the only things that we need to fix are the application media.

So the WordPress content which still resides in a folder local to the EC2 instance.

So we need to migrate this out so that we can scale the instances in and out without risking that data.

The other things that are still limiting factors are that customers are still connecting directly to the instance.

So we need to resolve that by using a load balancer and the IP address of the instance is still hard coded into the database.

So if this EC2 instance fails for whatever reason and we provision a new one, it won't function because WordPress expects everything to be loaded from this IP address.

So that's something we need to resolve.

But at this point that's everything you need to do in stage three.

In stage four you'll be migrating these images from the EC2 instance into an elastic file system.

And that's one of the last stages that we need to do before we can make this a fully elastic design.

So go ahead complete this video and when you're ready I'll look forward to you joining me in stage four of this advanced demo series.

Welcome back to stage two of this advanced demo lesson and again have included full instructions attached to this lesson.

And this stage of the demo will be another one where you're entering lots of commands because you're going to automate the build of the WordPress application instance.

So again, I would recommend opening the instructions for this demo lesson and copy and pasting the commands rather than typing them out by hand.

Now at this point in the advanced demo series, you're going to have a leftover instance that you used to manually install WordPress in the previous stage.

It should be called WordPress - Manual.

So I'm going to want you to go ahead and right click on that and select terminate instance and confirm that process to remove this instance from your AWS account.

We're going to be setting up exactly the same single instance deployment of WordPress, so both the database and the application on the same instance.

But instead of manually building this, we're going to be using a launch template.

So from the EC2 console, just go ahead and click on launch templates under instances.

The first step is to create a launch template for our WordPress application.

So go ahead and click on create launch template.

Now launch templates are actually a new version of launch configurations that were previously used with auto scaling groups.

Launch templates allow you to either launch instances manually using the template or they can be part of auto scaling groups.

But what a launch template allows you to do is to specify all of the configuration in advance to launch an instance and that template can be used to launch one or many instances.

So we're going to create a launch template which will automate the installation of WordPress, MariaDB and perform all of the configuration.

And a launch template can actually have many different versions, which is a feature we'll use throughout this demo series as we evolve the design.

So the first step is to name this template and we're going to call it WordPress.

Under template version description, go ahead and enter single server DB and app.

And then check this box which says provide guidance to help me set up a template that I can use with EC2 auto scaling.

We're not immediately going to set it up as part of an auto scaling group, but it will help us highlight any options which are required if we want to use it with an auto scaling group.

Now launch templates can actually be created from scratch or they can be based on a previous template version.

If we expand source template, you're able to specify a template which this template is based on.

But in this case, we're creating one from scratch so we won't set any of those options.

Now just scroll down.

So the next thing we're going to define in this launch template is the AMI that we're going to use.

So go ahead and click on Quickstart.

And once this has changed, we're going to use the same AMI we've been using previously.

So I want you to go ahead and click on Amazon Linux, specifically Amazon Linux 2023.

It should be the SSD volume type.

It should be listed as free tier eligible and just make sure that you've got 64 bit x86 selected.

And then scroll down further still and in the instance type drop down, we're looking for the T series of instances.

And then you need to select the one that's free tier eligible.

In most cases, this will be T2.micro, but select whichever is free tier eligible.

We want to keep this advanced demo as much as possible within the free tier.

Scroll down again and for key pair, just make sure that it says don't include in the launch template.

Move down further still to network settings.

Then make sure select existing security group is selected.

And then in the security groups drop down, click in that and make sure that you select the A4L.

VPC - SG WordPress.

So this is the security group which will automatically be associated with any instances launched using this launch template.

So select A4L.

VPC - SG WordPress and there will be some randomness after this.

That's fine.

Just make sure you select the SG WordPress group and then we can scroll down further still.

Now we can leave storage volumes as default.

We won't set any resource tags.

We won't do any configuration of network interfaces, but I will want you to expand advanced details.

There are a few things that we need to set within advanced details.

The first is an IAM instance profile.

So click in this drop down and then make sure that you pick A4L.

VPC - SG WordPress instance profile.

Again, there will be some randomness.

That's fine.

What this is doing is creating the configuration which will attach an instance role to this EC2 instance.

And this instance role is going to provide all the permissions required to interact with the parameter store and the elastic file system and anything else that this instance requires.

And this was pre-created on your behalf using the cloud formation template.

Next, scroll down further still and look for credit specification.

Remember, this is the same option that you set when launching an instance manually.

Now, as before, it's always best to set this to unlimited.

But if you are using a brand new AWS account, then it's possible that AWS won't allow you to use this option.

So you should probably go ahead and pick standard.

It won't make that much of a difference.

I'm going to pick unlimited, but I do suggest if you are using a fairly new account, you go ahead and select standard.

So that's the configuration for the instance, the base level configuration.

What I want you to do now though is to scroll all the way down to the bottom and there's a user data box.

This user data allows us to specify bootstrapping information to automatically configure our EC2 instances.

So into this user data box, I want you to paste the entire code snippet within stage 2B of this stages instructions.

And again, they're attached to this lesson.

The top line should be hash bang forward slash bin forward slash bash and then a space hyphen XE.

And then if you scroll all the way down to the bottom, the last line should be RM space forward slash TMP forward slash DB dot setup.

And now we can see we've pasted this entire user data.

Once you've done that, go ahead and click on create launch template.

Now that user data that you just pasted in is essentially all of the commands that you ran in the previous stage of the demo.

Only instead of pasting them one by one, you've defined them within the user data.

So this simply automates the process end to end.

So to test this, go ahead and click on launch templates towards the top of the screen.

It should show that you have a single launch template.

It's called WordPress.

The default version is one and the latest version is one.

And as we move throughout this demo series, the latest version and the default version will change.

So just keep an eye on those as we go.

For now, though, I want you to click in the checkbox next to this launch template, click on actions and then launch instance from template.

So this is going to launch an EC2 instance using this launch template.

We're asked to choose a launch template and a version and define the number of instances and we can leave all of these as the defaults.

If we just scroll down, you'll see how it's pre-populating all of these values with the configuration from the launch template.

And that's what we want.

Under key pair name, just select to proceed without a key pair not recommended.

And that's the default value.

Scroll down further still.

Even the networking configuration is partially pre-populated.

The only thing we need to do is specify a subnet that this instance will be launched into.

And when we configure auto scaling groups to use this launch template, the auto scaling group will configure the subnets on our behalf.

Because we're launching an instance directly from the launch template, we have to specify this subnet.

So click in the subnet dropdown and then look for SN-PUB-A.

Because we're going to deploy this WordPress instance into the public subnet in Availability Zone A.

So select that.

Scroll down.

Look for the resource tag section and click on add tag.

We're going to add a tag to the instance launched by this template.

So into key, just type name and then for value, use WordPress-LT.

And this will just tell us that this is an instance launched using the launch template.

Once you've entered those, just scroll all the way down to the bottom and click launch instance.

And this will launch an EC2 instance using this template.

And this will automate everything that we had to do in the previous stage manually.

So this saves us significant time and it enables us to use automation in later stages of this demo series.

So now go ahead and click on the instance ID in this success box and this will take you to the EC2 console.

Just give this instance a couple of minutes to finish its build process.

Even though we're automating the process, it does still take some time to perform the installation and the configuration of all of those different components.

So go ahead and just copy the public IP version for address of this instance into your clipboard.

And then after you've waited a few minutes, open that in a new tab.

If you get an error or it opens with a blank page, then you just need to give it a few minutes longer.

But when it's finished, it should show the same WordPress installation screen.

Once it does load the installation screen, we're going to follow the same process.

So site title is Categorum, username is Admin.

Enter the same password and then enter the fake test at test.com email address.

Then click on install WordPress.

Then click on login.

Enter admin again.

Enter the password.

Click on login.

It looks as though our automated WordPress build has worked because the dashboard has loaded.

Click on posts.

Delete the default post.

Click on add new.

For the title, the best animals again, click on the plus, select gallery, click on upload.

And again, pick a selection of animal pictures and click on open.

Remember, this is a new EC2 instance.

So the one we previously terminated will have also deleted the data on that previous instance.

Once these images have uploaded, click on publish and then publish again to upload the images to the EC2 instance and store the data within the database.

So remember two components, the data stored in the database and the images or media stored locally on the EC2 instance.

Click on view post to make sure that this loads correctly.

It does.

So that means the automatic build has worked okay.

Everything's functioning as we expect.

This has been an automatic build of a functional WordPress application.

Now, the only thing that's changed from the previous stage of this advanced demo series is we've automated the build of this instance.

It still has much the same limitations as the previous stage.

So while we can improve the build time and we can use launch templates to support further automation, the database and application are still on the same instance.

So neither can scale without the other.

The database of the application is still located on that instance, meaning scale in or out operations risk this data.

The WordPress content store is also stored locally on the instance.

So again, any scale in or out operations risk the media that's stored locally as well as the database.

Customers still connect directly to the instance, which means we can't perform health checks or automatically heal any failed instances.

For this, we need a load balancer which we'll be looking at in later stages of this demo series.

And of course, the IP address of the instance is still hard coded into the database.

So this is something else we need to resolve as we move through the demo series.

With that being said, though, that is everything that you needed to do in stage two of this demo series.

So in this stage, you've automated the build of the WordPress instance using a launch template.

Now, in stage three, you're going to migrate the data from the local database on EC2 into RDS.

And this will move the data out of the lifecycle of the EC2 instance.

And this makes it easier to scale.

So in stage three, you're going to perform that migration and then update the launch template to take account of that configuration change.

So go ahead and complete this stage of the demo lesson.

And when you're ready, I'll look forward to you joining me in the next.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

Now that we've created all of those, we need to go ahead and install WordPress on our EC2 instance.

So move back to instances.

By now, the instance should be in the running state.

Right-click, select Connect, change it to Session Manager, and then go ahead and click on Connect.

This will allow us to connect into the EC2 instance without worrying about direct network access or having an SSH key pair.

Once you're connected, go ahead and type shudu bash and press Enter, then type cd and press Enter, and then type clear and press Enter.

And that will just clear the screen to make everything easy to see.

Now, at this point, there are a lot of commands that you'll need to type in to manually install WordPress.

Now, you can copy and paste these out of the text instructions for this stage of the demo lesson.

But while you're doing so, I want you to imagine that you'd have to type these in one by one, because I want you to get an appreciation for just how long this install would take if you were doing it entirely manually.

So first, we need to set some environment variables on this instance with the parameters that we've just stored in Parameter Store.

So go ahead and copy all of this set of commands out of this stage's instructions, and this will set environment variables on this instance with values from the Parameter Store.

And again, imagine how long this would take if you had to type all of this manually.

Once we've got those variables configured, next we need to just update the operating system on the instance, make sure it's running with all the patches, and just update the package repositories.

And we can do that with this command.

The next set of commands in this stage's instructions install prerequisites.

So this is the MariaDB database server, the Apache web server, WGet, some libraries, and a stress test utility.

So go ahead and paste in the next block of commands to install all of these packages.

Now, again, this is something that we will automate later in this demo series, but I want you to have an appreciation for just how long this takes.

I'll type clear again to clear the screen, and then the next set of commands will start up the web server and the database server and ensure that both of them start up automatically when the instance operating system is first started.

So if we restart this instance, both of these services will start up automatically.

Again, make sure you press enter on the last command to make sure that starts up successfully.

So that's the Apache web server and MariaDB that are both started and set to automatically start on operating system boot.

Again, I'll clear the screen, and the next command that you'll run sets the root password for the MariaDB database server.

So this is my SQL admin, and you're setting the password for the root user, and we're using the environment variable that we created earlier with values taken from the parameter store.

So that sets the root password for the local database instance.

Next, we're going to download and install WordPress, and we do that with the next block of commands.

So this first downloads the WordPress package.

It moves into the web root directory.

It expands that package and then clears up after itself.

So now we have WordPress installed.

Again, I'll clear the screen to make it easier to see.

This next set of commands replaces some placeholders in the wp-config.php file, which is the configuration for WordPress, and it replaces the placeholders with values taken earlier from the parameter store.

So this is how we're configuring WordPress to be able to connect to the local MariaDB database server.

The next block of commands that we use will fix up the permissions of all of this directory structure, so we don't have any problems accessing these files or any other security issues.

Again, make sure you press Enter on the last command, and then we're almost done.

The last step is to actually create the WordPress database, create the WordPress database user, set the password, and then grant permission on that database to that user.

So these are all steps that we need to do because we're using a self-managed MariaDB database instance.

So paste in this next block of commands and press Enter.

So this has created a db.setup file with a number of SQL commands, and then it's used the MySQL utility to run those commands, which have created the database, the database user, and set permissions, and then it's cleared up the temporary file after all of that's been done.

And at this point, that's all of the configuration needed.

We've installed WordPress, we've installed MariaDB, we've started them both up, we've corrected permissions, and adjusted the configuration files.

Now you've had the ability to copy and paste these commands from the lesson instructions, but imagine if you had to type them in all one by one.

It would take much longer, and he's also something that's prone to many errors.

That's something important to keep in mind as we move through this advanced demo.

So the next step is to move back to the EC2 console.

Make sure you've got the WordPress-manual instance selected, and then copy down the IP version for public IP address into your clipboard, and make sure that you do copy the public IP address, and don't click on the open address link, because that uses HTTPS, which we're not using.

So go ahead and open that in a new browser tab.

Now this is going to take you to the setup screen for WordPress.

We're going to perform a quick setup.

So under site title, I want you to enter CategorM.

Under username, I want you to enter Admin.

We'll keep things simple.

For password, enter the Animals for Life password that we've been using in previous steps.

Under email, go ahead and enter a fake email address, and then click on Install WordPress.

That'll perform the final installation steps, at which point you can click on login.

You'll need to enter the Admin username together with the password that you've just chosen, and then click on login.

So this is the WordPress dashboard, and this suggests that our WordPress application is working absolutely fine.

So to test it, just go to posts.

We're going to delete the default post of Hello World.

Once done, go ahead and click on Add New.

You can just close down this Welcome to Block Editor dialog.

Under title, use the best animal and then S, because we might have more than one animal, and then just put an exclamation mark at the end for effect.

Click on the plus underneath that title, select Gallery.

Click on Upload, select some animal pictures to upload.

If you don't have any, you can go to Google Images and download some cat or dog or gerbil or guinea pig pictures.

Anything that you want, chickens, snakes, just select a couple of animal pictures to upload, and then click on Open.

And then once they've uploaded, you can go ahead and click on Publish, and then Publish again, and this will publish this post.

And what it's doing in order to publish it is it's uploading the images into a local image store that's called wp-content.

And in addition to that, it's storing the metadata for this post into the local MariaDB database.

So there are two different places that data is stored, the local content store, as well as the database.

So keep that in mind as we move on throughout this lesson.

At this point, click on View Post.

Just verify the post loads, it does.

So that means everything's working as expected.

Now, the configuration that you've just implemented has a number of important limitations.

The first is that the application and database have been built manually, which takes time and doesn't allow automation.

It's been slow and annoying, and that's very much the intention.

Additionally, the database and the application are on the same instance.

Neither of them can scale without the other.

The database of the application is stored on an EC2 instance, and that means that scaling in or out risks data in this database.

The application media, so the content is stored, also local to the instance in a folder called wp-content, and this means again, any scaling events in or out risks this media.

Additionally, customer connections are directly to an instance, which prevents us from doing any form of scaling, automatic healing, or any health checks.

One final part about WordPress that isn't commonly known is the IP address of the instance is actually hard-coded into the database.

Now, where this starts to exhibit problems is when running inside AWS because EC2 instances don't have static IP addresses.

If we go back to the EC2 console, right-click on this instance, and then stop the instance.

Remember, a stop and start of an instance will not force the change of the public IP address of the instance, so restarting it isn't enough.

You need to stop and then start.

Watch what happens when the instance fully moves into a stop state.

First, it loses this public IP address and it moves into the stop state.

If I right-click to then start, that will take a few moments, but what will happen is once it's fully started, it will have a different IP version for public address.

So now if I copy that IP address into my clipboard, move back to the tab where the website was previously open, and then open this new IP address in a different browser tab and note how it doesn't load.

Even though the IP address is correct, it's not loading our WordPress website.

The reason for that is the application is hard-coded with the IP address that was used to install WordPress.

And so what it's attempting to do now is reference the old IP address.

It's trying to contact the previous EC2 instance.

Now, this is crucial because it prevents us from scaling the application.

If we create new EC2 instances, they'll all point back at this instance.

Even if we fix the database and content issues, we need to resolve the ability of WordPress to scale.

And don't worry, we'll look at that later in this demo series.

For now, that's everything you needed to do in stage one of this advanced demo.

You've manually created a WordPress application with the application and database running on the same instance.

In stage two, you're going to automate this process.

So go ahead, complete this part of the demo series, and when you're ready, I'll look forward to you joining me in stage two.

Welcome back and in this advanced demo lesson you're going to get the chance to experience how to do a practical architecture evolution.

Now one of the things that I find very common amongst my students is that they complete the certification and as soon as they get their first job interview many of them which have an architectural scenario component they struggle on how to get started, how to design an architecture for a given scenario.

So in this advanced demo series you're going to step through and evolve an architecture yourself.

So you'll start with a single EC2 instance running the WordPress blogging engine and this single instance will be running the application itself, the database and it will be storing the content for all of the blog posts.

And for this example we're going to assume it's an animal pictures blog.

Now crucially in this first stage you're going to build this server manually to experience all of the different components that need to operate to produce this web application.

Once you've built the instance manually next you'll replicate the process but using a launch template to provide automatic provisioning of this WordPress application but crucially it will still be the one single WordPress instance.

Next you'll perform a database migration moving the MySQL database off the EC2 instance and running it on a dedicated RDS instance.

So now the database, the data of this application will exist outside the life cycle of the EC2 instance and this is the first step of moving towards a fully elastic scalable architecture.

Next once you've migrated the database instead of storing the content locally on the EC2 instance you'll provision the Elastic File System or EFS which provides a network based resilient shared file system and you'll migrate all of the content for the WordPress application from the instance to this Elastic File System.

Once done these are all the components required to move this architecture to be fully elastic and that is being able to scale out or in based on load on that system.

So the next step will be to move away from your customers connecting directly to this single EC2 instance.

Instead you'll provision an autoscaling group which will allow instances to scale out or in as required and you'll configure an Elastic Load Balancer to point at that autoscaling group so your customers will connect in via the application load balancer rather than connecting to the instances directly and this will abstract your customers away from the instances it will allow your system to be fully resilient self-healing and fully elastically scalable.

So by completing this advanced demo lesson you'll learn how to get started with scenario based questions as part of job interviews.

With that being said let's go ahead and get started and to do that we need to move to the AWS console.

To get started you're going to need to be logged in to a full AWS account without any restrictions you should be logged in as an admin user.

If you're watching this demo as part of any of my courses then you need to use the general AWS account so that's the management account of the AWS organization which we've set up in the course and as always please make sure that you've selected the northern Virginia region.

Now attached to this lesson are two links one of them is a one-click provision for the base infrastructure of this advanced demo lesson and the other is a link to the GitHub repository which contains text-based instructions for every stage of this advanced demo.

So to start with go ahead and click on the one-click provisioning link.

This is going to take you to the quick create stack page and everything should be pre-populated.

The stack name should say A4LVPC all you need to do is check this acknowledgement box and then go ahead and click on create stack.

Now you'll need to wait for this stack to move from create in progress to create complete before you can continue with the demo so go ahead and pause the video and you can resume it once this stack is in a create complete state.

So now this stack's moved into the create complete state the first stage of this advanced demo series is to manually create a single instance WordPress deployment.

Now this CloudFormation template has created the architecture that you can see on screen now so the VPC together with the three tier architecture so database application and public split across three different availability zones.

So what you're going to do in this first part of this demo series is to create this single EC2 instance and you're going to do it manually so that you can experience all of the associated limitations.

So make sure that you do have the text-based instructions open and the link for those is attached to this lesson because it will make it easier because you can copy and paste any commands or any configuration items.

The first thing to do though is to click on services and then type EC2 into the services drop down and click on EC2 to move to the EC2 console.

We're going to be launching our WordPress instance so what I need you to do is to click on launch instance and then again on launch instance.

Now you should be fairly familiar with creating an EC2 instance so we're going to go through this part relatively quickly.

So first you need to name the EC2 instance so go ahead and enter WordPress - manual in the name box and then scroll down and select Amazon Linux specifically Amazon Linux 2023 and just make sure that it's shown as free tier eligible.

Simply make sure that it says 64-bit x86.

Once set scroll down again and go to the instance type box, click in the drop down and just make sure that you have a free tier eligible instance selected.

For most people this should be T2.micro but just make sure that it's an equivalent sized instance which is under the free tier.

Continue scrolling down and under the key pair box just click in the drop down and select proceed without a key pair because we won't be connecting to this instance using an SSH key we'll be using session manager.

Once selected scroll down further still and click on edit next to network settings.

In the VPC box make sure that A4LVPC is selected.

This is the animals for life VPC created by the one click deployment.

Then under subnet make sure that SN-PUB-A is selected.

This is the public subnet in availability zone A.

Below this make sure that for both auto assign public IP and auto assign IPv6 IP both of these need to be set to enable.

Once done scroll down again and next to firewall security groups check the box to say to select an existing security group.

And then in the drop down make sure that you pick A4LVPC-SG WordPress.

Now this will be followed by some randomness and that's okay just make sure that it's the SG-WordPress security group.

This will allow us to connect into this instance using TCP port 80 which is HTTP.

Once selected scroll down and we won't be making any changes to the storage we'll be using the default of 8GIB of GP3 storage.

Below this expand advanced details and there are a couple of things that we need to change.

First click on the drop down under IAM instance profile and just make sure that you select the A4LVPC-WordPress instance profile and again this will have some randomness after it and that's okay.

Scroll down and next you're looking for a box which says credit specification.

Now for this my preference is that you select unlimited because this will make the performance of the EC2 instance potentially better than not selecting anything at all or selecting standard.

Now on brand new AWS accounts it's relatively common that you can't select unlimited.

AWS don't allow you generally to select unlimited until the account has a billing history.

So you might want to select standard here to avoid any problems.

I'm going to select unlimited because my account allows it but if you've got a new AWS account then go ahead and select standard.

If you do choose to select unlimited and you do receive an error then you can go ahead and repeat this process but select standard.

So go ahead and select standard in your case and then scroll down and that's everything that we need to set at this point.

Everything else looks good so go ahead and click on launch instance.

So now that our instance is provisioning just go ahead and click on instances at the top and that will allow us to monitor the progress.

Now we'll need this to be in a running state before we perform the WordPress installation but there's one more set of steps that I want to do first.

Now throughout this advanced demo lesson we're going to be taking this single instance WordPress application and moving it towards a fully scalable or an elastically scalable design.

Now to do that we need to move away from statically setting any configuration options so we're going to make use of the parameter store which is part of systems manager and we're going to create some parameters that our automatic build processes later in this demo will utilize.

For now we're going to be performing everything manually but we'll still be using these variables because it will simplify what we have to type in the EC2 instance.

So go ahead and click on services.

Start typing systems manager and then once you see it populated in the list you can right click and open that in a new tab.

Once you're at the systems manager console on the left under application management just locate parameter store and click it to move to the parameter store console and we're going to create a number of parameters.

Now if you're watching this demo as part of my courses you may already have some parameters listed on this screen.

If you have any existing ones which begin with forward slash A4L then go ahead and delete them before continuing.

So go ahead and click on create parameter and the exact naming for each of these is in the full instructions contained on the github repository which is attached to this lesson so make sure you've got that open it'll make it significantly easier and less prone to errors.

We're going to create a number of parameters for WordPress and the first is the database username so the username that will have permissions on the WordPress database.

So I want you to set the name to forward slash A4L forward slash WordPress forward slash DB user.

For description WordPress database user you can set the tier for the parameter to standard or advanced to keep things in the free tier we're going to use standard it's going to be a string parameter the data type is going to be text and the value needs to be our actual database username so for this demonstration we're going to use A4L WordPress user so enter that and click on create parameter.

Now we're going to be moving quicker now now that you've seen the process our next parameter is going to be the database name so enter this in the name field for description WordPress database name again standard string data type of text and the value is going to be the WordPress database name so A4L WordPress DB scroll down and click on create parameter.

Next is going to be the database endpoint so the host name that WordPress will connect to so for name enter this A4L WordPress DB endpoint for the description.

WordPress endpoint name again standard string text for data type and then to start with because the database is on the same instance as the application the value will be local host so enter that and go ahead and click on create parameter.

Next we'll be creating a parameter to store the password of the WordPress user so click on create parameter this time it's A4L WordPress DB password for description WordPress DB password again standard tier but this time it's going to be a secure string for KMS key source use current account and then for KMS key ID it will be alias AWS SSM which is the default KMS key for this service for value go ahead and enter a strong password again this is for the WordPress user that has permissions to access the database so if this were production it would need to be a strong password now I recommend that you use the same password as I'm using in this demo it uses number letter substitution and I know that it works with all of the different system components now I've included this password in the text based instructions and I do recommend that you use it in your demo as well go ahead and enter something in this value and then scroll down and click on create parameter and then last time click on create parameter again for name this time A4L WordPress DB root password and this is the root password for the local database server that's running on the EC2 instance so for description WordPress DB root password standard again and then again secure string because we're storing a password KMS key sources my current account leave everything else as default and then enter another strong password if this were production generally this would be different from the previous password but as this is a demo you should use the same strong password as you used previously whichever you choose go ahead and enter that into the value box and then click on create parameter okay so this is the end of part one of this lesson it was getting a little bit on the long side and I wanted to give you the opportunity to take a small break maybe stretch your legs or make a coffee now part two will continue immediately from this point so go ahead complete this video and when you're ready I look forward to you joining me in part two.

Welcome back and in this demo lesson you're going to get the chance to quickly experience how session stickiness works with load balances.

Now it's going to be a pretty brief demo lesson because I've tried to automate much of the infrastructure configuration that you've already done by this point in the course.

I want to focus on this demo lesson purely on the session stickiness configuration so let's jump in and get started and we're going to start by applying a CloudFormation template which will create the basic infrastructure that we need.

So I'm going to move across to the AWS console.

Now to start with make sure you're logged into an AWS account and the user that you're using has admin privileges on that account and you've got the Northern Virginia region selected.

Now attached to this demo lesson and in the demo instructions is a one click link that you can use to deploy the infrastructure so go ahead and click on that link.

It'll take you to a quick create stack screen and all you'll need to do is to scroll all the way down to the bottom, check this capabilities box and then click on create stack.

Now that can take anywhere from five to ten minutes to create so while that's creating let's talk through the architecture that you'll be using for this demo.

The template which you're currently applying will create this architecture so it creates a VPC and then inside of that three public subnets one in each AZ then it creates an auto scaling group and linked to this is a launch template providing instance build directives.

The auto scaling group is set to create six EC2 instances, two in each AZ and then it creates a load balancer configured to run from each public subnet.

So this is the architecture that's going to exist in the AWS account once the cloud formation stack has finished creating.

Now in this demo you're first going to connect to the load balancer with session stickiness disabled.

This means that each time you connect to the load balancer the connection can be sent to any of the six instances meaning that each of them has around a 16.66 recurring chance to get a connection.

So you'll first connect to the load balancer in this configuration.

Once you've seen how that looks you're going to enable session stickiness and see how that affects the architecture.

What will happen is the first time you connect to the load balancer with session stickiness enabled a cookie called AWS ALB will be generated and returned to your browser.

Unfortunately for this guy it's not that type of cookie.

What happens next is that any connections made while the cookie is valid are locked to one specific EC2 instance and they'll be locked to that instance until the cookie expires or that instance fails its health check at which point any connections will move to a different EC2 instance.

Now at this point let's move back to the console and just check how the cloud formation creation process is going.

At this point mine is still in a create in progress and you'll need this stack to be in a create complete state before moving on.

So go ahead and pause the video and resume it once this changes to create complete.

Okay so now the stack is in a create complete status we're good to move on and the first thing we'll need to do is verify that all of the six EC2 instances are functioning as they should be.

So to do that go ahead and click on services and then type EC2 in the find services box and open that in a new tab then move to that tab and click on instances running.

Now again this might look a little bit different in your account that's okay what we need to do is select each of these instances in turn and we're looking for the instance public IP version 4 DNS name.

So go ahead and locate the public IP version 4 DNS field and just copy that into your clipboard and then open that in a new tab.

The instance should load and it should show an instance ID, a random color background and an animated catgif.

Now I want you to go ahead and open each of the remaining five instances each in its own tab so let's do that next.

So select the second instance, scroll down, locate the public DNS address and then open that in a new tab.

You'll see this has a different color background and a different animated catgif.

We'll do the third instance, again different color background, different catgif.

We'll do the fourth, once again different background, different gif.

Do the fifth, different background, different gif and then finally the sixth instance.

So we have each of the six EC2 instances all with a different background and a different catgif.

Next scroll down on the menu on the left and click on load balances.

You should see a load balancer which starts with ALB - ALB and then some random that's fine.

Select that and copy the load balance the DNS name into your clipboard and then open that in a new tab.

So this opens the load balancer and if you refresh that a few times you'll see that it moves between all of the EC2 instances.

Now it could load the same instance twice or it might cycle through the same EC2 instances but you should see as you refresh it's cycling between all of the available instances and that's because we don't have session stickiness enabled.

It's just doing a round robin approach to select different back-end instances within the target group.

So each time we refresh there's a chance that it will move to a different back-end instance.

Now let's assume at this point that we have an application which doesn't handle state in an external way so it stores the state on the EC2 instance itself.

Well to enable session stickiness with application load balances we do it on a target group basis.

So click on target groups and then click on the target group to go into its configuration.

Locate and click on the attributes tab.

Click on edit next to attributes.

To enable session stickiness all we have to do is check this box select load balancer generated cookie and then pick validity period for the cookie that's generated by the application load balancer.

So go ahead and leave this value as 1 but then click on the drop-down and change this from days to minutes.

Once you've done that click on save changes and now session stickiness is enabled on this load balancer.

If we go back to the tab that we have open to the load balancer and just keep hitting refresh you might notice initially that it changes to a new instance but at a certain point if you keep clicking it will lock to a specific EC2 instance and won't change.

So now we're on this particular EC2 instance it's got this instance ID and even though we keep hitting refresh the background and the catgif remains the same.

Now the way that this works and I can demonstrate this using Firefox if I go to the menu bar click on tools then browser tools then web developer tools and then click on the storage tab you'll be able to see that as part of accessing this load balancer I've got two cookies and one of the cookies the one that we're interested in is AWS ALB.

This is the cookie that controls the session stickiness so every time I access this load balancer from the first point when this cookie is generated it passes this cookie back to the load balancer and it knows which back-end EC2 instance I should be connected to and so I will stay connected to this back-end instance until the cookie expires or this instance fails its health check.

So let's test that what I want you to do is to copy down the instance ID that you're connected to and it will be different for you and just pay attention to the last few digits of the instance ID.

Now if I go back to the EC2 console go to dashboard and then instances running locate the instance you just noted down the ID for right click and then stop that instance and confirm.

We'll give that instance a few moments to stop if we go back to the load balancer tab and just keep hitting refresh now now that the instance is in a stopped state the load balancer detects that it's no longer valid and so I immediately switch to a brand new EC2 instance the cookie generated by the load balancer is updated to lock me to this new EC2 instance and I wouldn't have any idea that this back-end instance has failed and no longer responds to requests other than the fact that I can see that I've changed instances because I've created the instances to highlight which instance ID is being used.

Now if I go back to the EC2 console select this instance again right click and this time start the instance even though this instance is started up again I won't reconnect to that original back-end instance because now I'm locked to this instance and there's a chance that what might happen while you're doing this demo lesson is while that instance was in a stopped state because this has been configured to use elastic load balancer health checks it might have detected that this instance is in a failed state and so it's instructed the auto scaling group to terminate that instance and replace it with a new one so don't be surprised if when you try to start this instance up it's in a terminated state that's okay the system is working as intended.

So back to the load balancer tab I'll just keep hitting refresh and what we'll see is after the cookie expires there's always a chance that we could be moved onto a new EC2 instance.

To return the configuration back to how it was at the start of the demo we can go back to the EC2 console go down to target groups open this target group click on the attributes tab and then edit and then uncheck the stickiness box and save the changes and at this point the cookie that's generated will no longer lock our connections to one specific back-end instance and so over time if we keep refreshing this page we should be moved between different back-end EC2 instances because again now we no longer have session stickiness.

Now that's all I really wanted to highlight in this demo lesson I just wanted to give you some practical exposure to how the session stickiness feature works of application load balancers so this is something that you need to understand for the exam essentially if your application doesn't handle state externally to individual EC2 instances then you need the load balancer to make sure that any connections from a given user always end up on the same EC2 instance and the way to do that is with application load balancer controlled session stickiness now remember this does come with some negatives it means that the load balancer is not able to as efficiently distribute load across each of the back-end instances so while session stickiness is enabled it means customers are locked to one particular EC2 instance and even if customers locked to one instance generate much more load than customers locked to other instances the load balancer doesn't have the same level of flexibility to distribute connections so where possible application should be designed so they handle sessions externally to the instances and then you should not have session stickiness enabled and this is the way to ensure well-performing elastic architectures now at this point that's everything that you need to do in this demo lesson all that remains is to tidy up the environment so go back to the cloud formation console we can just go ahead and click on stacks click in the box next to the ALB stack click on delete and then click delete stack which will delete the stack and all of the infrastructure that it created at the start of this demo lesson at this point congratulations you've successfully completed this demo lesson and implemented the architecture that's on screen now as well as experienced how an application load balancer handles session stickiness so I hope you enjoyed the demo go ahead complete this video and when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this demo lesson you're going to experience the difference that EFS can make to our WordPress application architecture.

Now this demo lesson has three main components.

First we're going to deploy some infrastructure automatically using the one-click deployments.

Then I'm going to step through the CloudFormation template and explain exactly how this architecture is built.

And then right at the end you're going to have the opportunity to see exactly what benefits EFS provides.

So to get started make sure that you're currently logged in to the general AWS account, so the management account of the organization, and as always you need to have the Northern Virginia region selected.

Now this lesson actually has two one-click deployments.

The first deploys the base infrastructure and the second deploys a WordPress EC2 instance, which has been enhanced to utilize EFS.

So you need to apply both of these templates in order and wait for the first one to finish before applying the second.

So we're going to start with the base VPC RDS EFS template first.

So this deploys the base VPC, the Elastic File System and an RDS instance.

Now everything should be pre-populated.

The stack should be called EFS demo -vpc -rds -efs.

Just scroll all the way down to the bottom, check the capabilities box and click on create stack.

While that's going let's switch over to the CloudFormation template and just step through exactly what it does.

So this is the template that you're deploying using the one-click deployment.

It's deploying the Base Animals for Life VPC, an EFS file system as well as mount targets and an Aurora database cluster.

So if we just scroll down we can see all of the VPC and networking resources used by the Base Animals for Life VPC.

Continue scrolling down we'll see the subnets that this VPC contains IP version 6 information.

We'll see an RDS security group, a database subnet group.

We've got the database instance.

Then we've got an instance security group which controls access to all the resources in the VPC that we use that security group on.

Then we have a rule which allows anything with that security group attached to it to communicate with anything else.

We have a rule that the WordPress instance will use and note that this includes permissions on the Elastic File System.

Then we have the instance profile that that instance uses.

Then we have the CloudWatch agent configuration and this is all automated.

And if we just continue scrolling down here we can see the Elastic File System.

So we create an EFS file system and then we create a file system mount target in each application subnet.

So we've got mount target zero which is in application subnet A which is in US East 1A.

We've got mount target one which is an application subnet B which logically is in US East 1B.

And then finally target two which is in subnet app C which is in availability zone 1C.

So we create the VPC, the database and the Elastic File System in this first one click deployment.

Now we need this to be in a create complete state before we continue with the demo lessons.

So go ahead and pause the video, wait for this to move into a create complete status and then we can use the second one click deployment.

Okay that stacks now finished creating which means we can move on to the second one click deployment.

Now there are actually two WordPress one click deployments which are attached to this lesson.

We're going to use them both but for now I want you to use the WordPress one one click deployment.

So go ahead and click on that link this will create a stack called EFS demo hyphen WordPress one.

Everything should be pre-populated just go ahead and click on create stack.

Now this is going to use the infrastructure provided by that first one click deployment.

So it's going to use EFS demo hyphen VPC hyphen RDS hyphen EFS and let's quickly step through exactly what this is doing while it's provisioning.

So this is the cloud formation template that is being used and we can skip past most of this.

What I want to focus on is the resource that's being created so that's WordPress EC2.

So this is using cross stack references to import a lot of the resources created in that first cloud formation stack.

So it's importing the instance profile to use it's importing the web a subnet so it knows where to place this instance.

And it's importing the instance security group that's created in that previous cloud formation stack.

Now in addition to this if we look through the user data for this WordPress instance one major difference is that it's mounting the EFS file system into this folder.

So forward slash var forward slash w w w forward slash HTML forward slash WP hyphen content.

Now if you remember from earlier demo lessons this is the folder which WordPress users to store its media.

So now instead of this folder being on the local EC2 file system this is now the EFS file system.

The EFS file system is mapped into this folder on this WordPress instance.

Other than that everything else is the same WordPress is installed.

It's configured to you as the RDS instance the cow say custom login banner is displayed.

It automatically configures the cloud watch agent and then it signals cloud formation that it's finished provisioning this instance.

Now what we'll end up with when this stack has finished creating is an EC2 instance which will use the services provided by this original stack.

So let's just refresh this.

It's still in progress so go ahead and pause the video and wait for this stack to move into a create complete state and then we good to continue.

So this stacks now finished creating and if we move across to the EC2 console so click on services locate EC2 right click and open that in a new tab.

Then click on instances running and you'll see that we have this A4L WordPress instance.

Now if we select that copy the IP address into your clipboard and then open that in a new tab we need to perform the WordPress installation.

So go ahead and enter the site title the best cats and add some exclamation points.

For username we need to use admin then for the password go back to the cloud formation stack and click on parameters and we're going to use the DB password.

So copy that into your clipboard then go back paste it into the password box and then put test at test.com for the email address and click install WordPress.

Then as before we need to log in so click on login admin for username reenter that password and click on login.

Then we need to go to posts we need to click on trash below hello world to delete that post then click on add new close down this dialogue.

For title put the best cats ever and some exclamation points then click on the plus click gallery click upload.

There's a link attached to this lesson with four cat images so go ahead and download that link and extract it locate those four images select them and click on open.

And then once you've done that click on publish and publish again and then click on view post.

Now what that's doing in the background is it's adding these images to the WP hyphen content folder which is on the EC two instance but now we have that folder mounted using EFS and so the images are being stored on the elastic file system rather than the local instance file system.

The cat pictures are there but what we're going to do to validate this is to go back to instances right click on this a four L hyphen WordPress instance and click on connect and then connect to this instance using EC two instance connect.

Now once we connected to the instance you CD space forward slash VAR forward slash WWW forward slash HTML and then do an LS space hyphen LA to do a full listing you'll see that we have this WP hyphen content folder.

So type CD space WP hyphen content and press enter then we'll clear the screen and do an LS space hyphen LA and then inside this folder we have plugins themes and uploads go into the uploads folder do an LS space hyphen LA depending on when you do this demo lesson you should see a folder representing the year so move into that folder then a folder representing the month again this will vary depending on when you do the demo lesson.

Move into that folder and then you should see all four of my cat images and if you do a DF space hyphen K you'll be able to see that this folder so forward slash VAR forward slash WWW forward slash HTML WP hyphen content this is actually mounted using EFS so this is an EFS file system.

Now this means the local instance file system is no longer critical it no longer stores the actual media that we upload to these posts so what we can do is we can go back to cloud formation go to stacks select the EFS demo hyphen WordPress one stack and then click on delete and delete that stack so that's going to terminate the EC two instance that we've just used to upload that media.

We need to wait for that stack to fully delete before continuing so go ahead and pause the video and wait for this stack to disappear so that stacks disappeared and now there's a second WordPress one click deployment link attached to this lesson remember there are two so now go ahead and click on the second one this one should create a stack called EFS demo hyphen WordPress two scroll to the bottom and click on create stack that's going to create a new stack and a new EC two instance.

So while we're doing this just close down all of these additional tabs at the top of the screen close them all down apart from the cloud formation one.

We're going to need to wait for this to finish provisioning and move into the create complete state so again pause the video wait for this to change into create complete and then we go to to continue.

After a few minutes the WordPress two stack has moved into a create complete state click on services open the EC two console in a new tab click on instances running you'll see a new A4L hyphen WordPress instance this is a brand new instance which has been provisioned using the one click deployment link that you've just used so the WordPress two one click deployment link.

If we select this copy the public IP address into your clipboard and open that in a new tab it again loads our WordPress blog if we open the blog post.

Now we can see these images because they're being loaded from EFS from the file system that EFS provides so no longer are we limited to only operating from a single EC two instance for our WordPress application because now there's nothing which gets stored specifically on that EC two instance.

Instead everything stored on EFS and accessible from any EC two instance that we decide to give permissions to know what we can do to demonstrate this if we go back to cloud formation.

Now remember attached to this lesson are two WordPress one click deployments we initially applied number one then we deleted that and applied number two so now I want you to reapply number one.

So again click on the WordPress one one click deployment this again will create a new stack this time called EFS demo hyphen WordPress one click on create stack you need to wait for this to move into a create complete state so pause the video and resume it once the stack changes to create complete after a few minutes this stack also moves into create complete.

Let's click on resources we can see it's provisioned a single EC two instance so let's click on this to move directly to this new instance select it copy this instance is IP address into your clipboard and open that in a new tab and again we have our WordPress blog and if we click on the post it loads those images so now we have a number of EC two instances we have to EC two instances both with WordPress installed both using the same RDS data.

And both using the shared file system provided by EFS and it means that if any posts are edited or any images uploaded on either of these two EC two instances then those updates will be reflected on all other EC two instances and this means that we've now implemented this architecture that's on screen now and this is what's going to support us when we evolve this architecture more and add scalability in an upcoming section of the core.

For now though we've just been focused on the shared file system now all that remains at this point is for us to tidy up the infrastructure that we've used in this demo lesson so close down all of these tabs we need to be at the cloud formation console we need to start by deleting EFS demo WordPress one and WordPress two so pick either of those click delete and then delete stack then select the other delete and then delete stack.

Now we need both of these to finish deleting and then we can delete this last stack so go ahead and pause the video wait for both of these to disappear and then we can resume both of those have deleted so now we can click the final stack EFS demo hyphen VPC hyphen RDS hyphen EFS so select that delete and then delete stack and that's everything that you need to do in this demo lesson and once that stacks finished deleting the account will be in the same state as it was at the start of this.

Now I hope you've enjoyed this demo lesson and that it's been useful what you've implemented in this demo is one more supportive step towards us moving this architecture from being a monolith through to being fully elastic.

Now the application is in this state where we have a single shared RDS database for all of our application instances and we're also using a shared file system provided by EFS and this means that we can have one single EC2 instance we could have two EC2 instances or even 200 all of them sharing the same database and the same shared file system provided by EFS.

Now in an upcoming section of this course we're going to extend this further by creating a launch template which automatically builds EC2 instances as part of this application architecture.

We're going to utilize auto scaling groups together with application load balancers to implement an architecture which is fully elastic and resilient and this has been one more supportive step towards that objective.

At this point though that's everything that you needed to do in this demo lesson so go ahead complete this video and when you're ready I look forward to you joining me in the next.

Welcome back, this is part two of this lesson.

We're going to continue immediately from the end of part one, so let's get started.

Okay, so all three of these mount targets are now in an available state and that means we can connect into this EFS file system from any of the availability zones within the Animals for Life VPC.

So what we need to do is test out this process and we're going to interact with this file system from our EC2 instances.

So move back to the tab where we have the EC2 console open.

And at this point I want you to either, and this depends on your browser, I'll either want you to right click and duplicate this tab to open another identical copy.

If you can't do this in your browser then just open a new tab and copy and paste this URL into that tab.

You'll end up with two separate tabs open to the same EC2 screen.

So on the first tab we're going to connect to A4L-EFS instance A.

So right click and then select connect.

We're going to use instance connect.

So make sure the username is EC2-user and then click on connect.

Now right now this instance is not connected to this EFS file system and we can verify that by running a DF space-k and press enter.

You'll see that nowhere here is listed this EFS file system.

These are all volumes directly attached to the EC2 instance and of course the boot volume is provided by EBS.

Now within Linux all devices or all file systems are mounted into a folder.

So the first thing that we need to do to interact with EFS is to create a folder for the EFS file system to be mounted into.

And we can do that using this command so shudu space mkdir space-p space/efs/wp-content.

Now the hyphen p option just means that everything in this path will be created if it's not already.

So this will create forward/EFS if it doesn't already exist.

So press enter to create that folder.

So I'm going to clear the screen to keep this easy to see.

And the next thing I need to do is to install a package of tools which allows this instance or specifically the operating system to interact with the EFS product.

Now the command I'm going to use to install these tools is shudu to give us admin permissions and then DNF which is the package manager for this operating system.

And then a space hyphen y to automatically acknowledge any prompts and then a space and then install because I want to install a package and then a space.

And then the name of the tools that I want to install is amazon hyphen EFS hyphen utils.

So this is a set of tools which allows this operating system to interact with EFS.

So go ahead and press enter and that will install these tools and then we can configure the interaction between this operating system and EFS.

Again I'm going to clear the screen to keep this easy to see and I want to mount this EFS file system in that folder that we've just created.

But specifically I want it to mount every time the instance is restarted.

So of course that means we need to add it to the FSTAB file.

Now if you remember this file from elsewhere in the course it's contained within the forward/ETC folder.

So we need to move into that folder cd///ETC and then the file is called FSTAB.

So we need to run shudu to give us admin permissions and then nano which is a text editor and then the name of the file which is FSTAB.

So press enter and the file will likely have only one or two lines which is the root and/or boot volume of this instance.

So let's just move to the end because we're going to add a new line and this is contained within the lesson commands document but we're going to paste in this line.

So this line tells us that we want to mount this file system ID so file system ID colon forward/.

We want to mount that into this folder so forward/efs forward/wp-content.

We tell it that the file system type is EFS.

Remember EFS is actually based on NFS which is the network file system but this is one provided by AWS as a service and so we use a specific AWS file system which is EFS.

And the support for this has been installed by that tools package which we just installed.

Now the exact functionality of this is beyond the scope of this course but if you do want to research further then go ahead and investigate exactly what these options do.

What we need to do though is to point it at our specific EFS file system.

So this is this component of the line all the way from the start here to this forward/.

So to get the file system ID we need to go back to the EFS console and we need to copy down this full file system ID and yours will be different so make sure you copy your own file system ID into the clipboard.

Then go back here and select the colon and then delete all the way through to the start of this line.

And once you've done that paste in your file system ID what it should look like is the file system ID then a colon and then a forward/.

So at this point we need to save this file so control O to save and then enter and control X to exit.

Again I'm going to clear the screen to make it easier to see.

Then I'll run a DF space -K and this is what the file systems currently attached to this instance look like.

Then we're going to mount the EFS file system into the folder that we've created and the way that we do this is with this command.

So shudu mount and then we specify the name of the folder that we want to mount.

Now the way that this works is that this uses what we've just defined in the FSTAB file.

So we're going to mount into this folder whatever file system is defined in that file.

So that's the EFS file system and if we press enter after a few moments it should return back to the prompt and that's mounted that file system.

There we go we back at the prompt and if we do a DF space -K again we'll see that now we've got this extra line at the bottom.

So this is the EFS file system mounted into this folder.

Now to show you that this is in fact a network file system let's go ahead and move into that folder using this command.

And now that we're in that folder we're going to create a file.

So we're going to use shudu so that you have admin privileges and then we're going to use the command touch which if you remember from earlier in the course just creates an empty file.

And we're going to call this file amazing test file dot txt.

Go ahead and press enter and then do an LS space -LA and you'll see that we now have this file created within this folder.

And while we're creating it on this EC2 instance it's actually put this file on a network file system.

Now to verify that let's move back to the other tab that we have open to the EC2 console the one that's still on this running instances screen.

And now let's go ahead and connect to instance B.

So right click on instance B select connect again instance connect verify the username is as it should be and click on connect.

So now we're on instance B.

Let's do a DF space -K to verify that we don't currently have any EFS file system mounted.

Next we need to install the EFS tools package so that we can mount this file system.

So let's go ahead and install that package clear the screen to make it easier to see then we need to create the folder that we're going to be mounting this file system into.

We'll use the same command as on instance A.

Then we need to edit the FSTAB file to add this file system configuration.

So we'll do that using this command so shudu space nano space forward slash ETC forward slash FSTAB press enter.

Remember this is instance B so it won't have the line that we added on instance A.

So we need to go down to the bottom paste in this placeholder and then we need to replace the file system ID at the start with the actual file system ID.

So delete this leaving the colon and forward slash go back to the EFS console copy the file system ID into your clipboard.

Move back to this instance paste that in everything looks good.

Save that file with control O press enter exit with control X then we back at the prompt clear the screen.

We'll use the shudu mount forward slash EFS forward slash WP hyphen content command again to mount the EFS file system onto this instance and again it's using the configuration that we've just defined in the FSTAB file press enter.

After a few moments you'll be placed back at the prompt we can verify whether this is mounted with DF space hyphen K.

It has mounted by the looks of things it's at the bottom.

So now if we move into that folder so CD forward slash EFS forward slash WP hyphen content forward slash and press enter.

We now in that folder and if we do a listing so LS space hyphen LA what we'll see is the amazing test file dot txt which was created on instance A.

So this proves that this is a shared network file system where any files added on one instance are visible to all other instances.

So EFS is a multi user network based file system that can be mounted on both EC2 Linux instances as well as on premises physical or virtual servers running Linux.

Now this is a simple example of how to use EFS for now we've done everything that we need to do in this demo lesson so we just need to clean up all of the infrastructure that we've used to do that.

Go back to the EFS console we're going to go ahead and delete this file system so we should already have it selected just select delete you'll need to confirm that process by pasting in the file system ID.

So go ahead and put your file system ID and then select confirm.

Now that can take some time to delete and you'll need to wait for this process to complete.

Once it has completed we're going to go ahead and move across to the cloud formation console.

You should still have this open in a tab if you don't just type cloud formation in the search box at the top and then move to the cloud formation console.

You should still have the stack name of implementing EFS which is the stack you created at the start with the one click deployment.

Go ahead and select this stack then click on delete and confirm that deletion and once that finishes deleting that's all of the infrastructure gone that we've created in this demo lesson.

So I hope this has been a fun and enjoyable demo lesson where you've gained some practical experience of working with EFS at this point though that is everything that you need to do in this demo lesson.

So go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this demo lesson I want to give you some abstract practical experience of using the Elastic File System or EFS.

Now we're going to need some infrastructure.

Before we apply that as always make sure that you're logged into the general AWS account, so the management account of the organization and you'll need the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment link so go ahead and click that.

This is going to provision some infrastructure.

It's going to take you to the quick create stack screen and everything should be pre-populated.

You'll just need to scroll to the bottom, check the box beneath capabilities and then click on create stack.

You're also going to be typing some commands within this demo lesson so also attached to this lesson is a lesson commands document.

Go ahead and open that in a new tab.

So this is just a list of the commands that we're going to be using during the demo lesson and there are some placeholders such as file system ID that you'll need to replace as we go but make sure you've got this open for reference.

Now we're going to need this stack to be in a create complete state before we continue with the demo lesson so go ahead pause the video and resume it once your stack moves into a create complete state.

Okay so the stacks now moved into a create complete status and what this has actually done is create the animals for life base VPC as well as a number of EC2 instances.

So if we go to the EC2 console and click on instances running you'll note that we've created a for L - EFS instance A and a for L - EFS instance B and we're going to be creating an EFS file system and mount points and then mounting that on both of these instances and interacting with the data stored on that file system.

We're going to get you the experience of working with a network shared file system so let's go ahead and do that.

So to get started we need to move to the EFS console so in the search box at the top just type EFS and then open that in a brand new tab.

We're going to leave this tab open to the instances part of the EC2 console because we're going to come back to this very shortly.

So let's move across to the EFS console that we have open in a separate tab and the first step is to create a file system so a file system is the base entity of the elastic file system product and that's what we're going to create.

Now you've got two options for setting up an EFS file system you can use this simple dialogue or you can click on customize to customize it further.

So if we're using the simple dialogue we'd start by naming the file system so let's say we use A4L - EFS and then you'd need to pick a VPC for this file system to be provisioned into and of course we'd want to select the animals for life VPC.

Now we want to customize this further we don't want to just accept these high-level defaults so we need to click on customize.

This is going to move us to this user interface which has many more options so we've still got the A4L - EFS name for this file system.

Now for the storage class we're going to pick standard which means the data is replicated across multiple availability zones.

If you're doing this in a test or development environment or you're storing data which is not important then you can choose to use one zone which stores data redundantly but only within a single AZ.

Now again in this demonstration we are going to be using multiple availability zones so make sure that you pick standard for storage class.

You're able to configure automatic backups of this file system using AWS backup and if you're taking an appropriate certification course this is something which I'll be covering in much more detail.

You can either enable this or disable it obviously for a production usage you'd want to enable it but for this demonstration we're going to disable it.

Now EFS as I mentioned in the theory lesson comes with different classes of storage and you can configure lifecycle management to move files between those different storage classes so if you want to configure lifecycle management to move any files not accessed for 30 days you can move those into the infrequent access storage class and you can also transition out of infrequent access when anything is accessed so go ahead and select on first access for transition out of IA.

So in many ways this is like S3 with the different classes of storage for different use cases.

When you're creating a file system you're able to set different performance and throughput modes.

For throughput mode you can choose between bursting and enhanced.

If you pick enhanced you're able to select between elastic and provisioned.

I've talked more about these in the theory lesson.

We're going to pick bursting.

Now for performance you can choose between general purpose and max I/O.

General purpose is the default and rightfully so and you should use this for almost all situations.

Only use max I/O if you want to scale to really high levels of aggregate throughput and input output operations per second so only select it if you absolutely know that you need this option.

You've also got the ability to encrypt the data on the file system and if you do encrypt it it uses KMS and you need to pick a KMS key to use.

Of course this means that in order to interact with objects on this file system permissions are needed both on the EFS service itself as well as the KMS key that's used for the encryption operation.

Now this is something that you will absolutely need to use for production usage but for this demonstration we're going to switch it off.

We won't be setting any tags for this file system so let's go ahead and click on next.

You need to configure the network settings for this file system so specifically the mount targets that will be created to access this file system.

Now best practice is that any availability zones within a VPC where you're consuming the services provided by EFS you should be creating a mount target so in our case that's US - East - 1A, 1B and 1C.

So we're going to go through and configure this so first let's delete all of these default security group assignments.

Every mount target that you create will have an associated security group so we'll be setting these specifically.

For now though we need to choose the application subnet in each of these availability zones so in the top drop-down which is US - East - 1A I'm looking for app A so go ahead and do the same.

In US - East - 1B I want to select the app B subnet and then in US - East - 1C logically I'll be selecting the app C subnet so that's app A, app B and app C.

Now for security groups the CloudFormation 1 click deployment has provisioned this instance security group and by default this security group allows all connections from any entities which have this attached so this is a really easy way that we can allow our instances to connect to these mount targets so for each of these lines go ahead and select the instance security group you'll need to do that for each of the mount targets so we'll do the second one and then we'll do the third one and that's all of the network configuration options that we need to worry about so click on next it's here where you can define any policies on the file system so you can prevent root access by default you can enforce read only access by default you can prevent anonymous access or you can enforce encryption in transit for all clients connected to this EFS file system so any clients that connect to the mount targets to access the file system you can ensure that that uses encryption in transit and if you're using this in production you might want to select at least this last option to improve security for this demo lesson we're not going to use any of these policy options nor are we going to define a custom policy in the policy editor instead we'll just click on next at this point we just need to review everything's to our satisfaction everything looks good so we're going to scroll down to the bottom and just click on create now in order to continue with this demo lesson we're going to need both the file system and all of its mount targets so go into the file system click on network and you'll see three mount targets being created all three of these need to be ready before we can continue the demo lesson so this seems like a great time to end part one of this demo lesson go ahead and finish this video and then when all of these mount targets are ready to go you can start part two.

Welcome back and in this demo lesson you're going to get some experience of migrating a snapshot which you've previously taken from Aurora in provisioned mode and migrate this into Aurora running in serverless mode.

Now before we begin as always make sure that you're logged in to the general AWS account, so the management account of the organization and you'll need to have Northern Virginia selected.

Now attached to this lesson is a one-click deployment link and I'll need you to go ahead and open that to start the process.

Now once you've got this open we're going to need the Aurora snapshot name that you created in a previous demo.

So click on the services drop down and locate RDS.

It's probably going to be in the recently visited section if not you can search in the box at the top but go ahead and open that in a new tab.

Go to that tab and once it's loaded click on snapshots and you should have these two snapshots in your account.

The first snapshot is a4l wordpress -with -cat - post -mySQL57.

The other snapshot the one that we're going to use is this one so a4l wordpress -aura -with -cat -post.

Go ahead and select that entire snapshot name and copy that into your clipboard because we're restoring an Aurora provisioned snapshot into Aurora serverless.

We're not performing a migration we're performing a restore and so we don't need the snapshot ARN we need the snapshot name.

So go back to the cloud formation stack everything should be pre-populated but there's a box that you need to paste in the snapshot name that you'll be restoring so that's this one paste that in check the acknowledgement box at the bottom under capabilities and then create stack.

Now that process can take up to 45 minutes to complete sometimes it can be a little bit quicker and while that's working we're going to follow the same process through manually but we're going to stop before provisioning the Aurora serverless cluster.

So go back to the RDS tab make sure that you still have this snapshot selected then click on actions and then restore snapshot and I want to step through the options available when restoring an Aurora provisioned snapshot into Aurora serverless.

So these are the options you'll have when you're restoring an Aurora provisioned snapshot you'll see a list of compatible engines so anything compatible with the snapshot that you're restoring in our case it's only my SQL compatibility then you'll have to select your capacity type now it defaults to provisioned but we want to restore to a serverless cluster so we'll select serverless.

You need to select the version of Aurora serverless that you're restoring to and again it's only going to show you compatible versions in this case only 2.07.1 and that's why I was so precise with the version numbers when doing the demos earlier in this section.

Now under database identifier it's here where we would need to provide a unique identifier within this region inside this account for what we're restoring so we might use a4l wordpress-serveless we then need to provide connectivity information so we'd click in the VPC drop-down and make sure we select the animals for life VPC we'd still need to provide a database subnet group to use now currently there isn't one that exists in the account because the cloud formation template is still provisioning but we'd need to choose a relevant subnet group in this box we'd also need to choose a VPC security group which controls access to this database cluster then we have additional configuration and this is a feature which I'm going to be talking about in a dedicated lesson if you're doing the developer or sysops associate courses and this is an API which can be provisioned to give access to the data within this Aurora serverless cluster and it can do so in a way which is very lightweight and this makes it ideal for use with things like serverless applications which prefer a connectionless architecture so this is something that you will use if you want to use for example Aurora serverless with a serverless application based on lambda now something unique to Aurora serverless is the concept of capacity units and I've talked about these in the theory lesson where I talk about Aurora serverless these are the units of database service which the Aurora serverless cluster can make use of and you're able to set a minimum capacity unit and a maximum capacity unit and this provides a range of resources that this cluster can move between based on load on the cluster so as I've talked about in the theory lesson it will automatically provision more capacity or less capacity between these two values based on load now you have additional options for scaling and one that I'll be demonstrating a little bit later on in this demo lesson is how you can actually pause the compute capacity after a consecutive number of minutes of inactivity and this as long as your application supports it can actually reduce the amount of cost that you have running a database platform down to almost zero so you won't have any compute capacity build when the Aurora serverless cluster isn't in use and again I'll be demonstrating that very shortly in this demo lesson you're able to set encryption options just like with other forms of RDS and then under additional configuration you can also configure backup options now these options are obviously based on restoring a snapshot and you have a similar yet more extensive set of options if you're creating an Aurora serverless cluster from scratch so if we select Amazon Aurora and then we go down and select the serverless capacity type then obviously we can select from different versions and we have a wider range of options that we can set so the cluster identifier the admin username and password we've still got the capacity settings we still need to define connectivity options we've got additional configuration options around creating a database controlling the parameter group customizing backup options encryption and enabling deletion protection so whether you're restoring a snapshot or creating an Aurora serverless cluster from scratch these options are similar but you have access to slightly more configuration if you're creating a brand new cluster because when you're restoring a snapshot many of these configuration items are taken from that snapshot at this point we're not going to actually create the cluster manual so I'm going to cancel out of that and I'm going to refresh and as you can see we already have our Aurora serverless DB cluster and it's in an available state so let's go back to our cloud formation stack and refresh it's still in a create in progress state for the stack itself and in order to continue with this demo lesson we're going to need this to be in a create complete state so go ahead pause the video wait for your stack to move into a create complete state and then we can continue so this stacks now moved into a create complete state and we're good to continue so the first thing that I want to draw your attention to if we move back to the RDS console and then let's just refresh you'll see that this cluster is currently using two Aurora capacity units let's go inside the cluster we'll be able to see that it's available it's currently using two capacity units but otherwise it looks very similar to a provisioned Aurora cluster now what we're going to do is click on services open the EC2 console in a new tab go to instances running you should see a single WordPress instance so select that copy the public IP version 4 address into your clipboard making sure not to use this open address and open that in a new tab you'll see that it loads up the WordPress application and it still has the post within it that you created in the previous demo lesson the best cats ever and if you open this post you'll see that it doesn't have any of the attached images because remember they're not stored in the database they're stored on the local instance file system and that's something that we're going to rectify in an upcoming section of the course either called advanced storage or network storage depending on what course you're currently taking but I just wanted to demonstrate that all we've done is restore an Aurora provision snapshot into an Aurora serverless cluster and it still operates in the same way as Aurora provisioned but this is where things change if we go back to the RDS console we know that this Aurora serverless cluster makes use of Aurora capacity units or ACUs and currently it's set to move between one and two Aurora capacity units and the reason it's currently set to two is because we've just used it we've just restored an existing snapshot into this cluster and that operation comes with a relatively high amount of overhead so it needs to go to the two capacity units maximum in order to give us the best performance now what we're going to see over the next few minutes if we just sit here and keep refreshing this screen what should happen is that because we're not using our application first we're going to see it drop down from two capacity units to one capacity unit and that will of course reduce the costs for running this Aurora serverless cluster after a certain amount of time it's going to go from one capacity unit to zero capacity units because it's going to pause the cluster because of no usage we've got this configured if I click on the configuration tab to pause the compute capacity after a number of consecutive minutes of inactivity and it's set to five minutes so after five minutes of no usage on this database it's actually going to pause the compute capacity and we won't be incurring any costs for the compute side of this Aurora serverless cluster so that's one of the real benefits of Aurora serverless versus all of the other types of RDS database engine so let's just go ahead and refresh this and see if it's already changed from two capacity units it's currently still on two so let's select logs and events and refresh we don't see any events currently so this means that we've had no scaling events on this database but if we click on monitoring you'll see how the CPU utilization has decreased from around 25% to just over 5% and the database connection count has reduced from the one when we just accessed the application back down to zero after a few refreshers we'll see that it either decreases from two capacity units down to one or it will go straight to zero if we reach this five minute timer before it performs that scaling event to reduce from two to one so in our case we've skipped the point of having one capacity unit we've reached that five minute threshold where it pauses the compute capacity and so it's gone straight down to zero so your experience might vary it might go from two down to one and then pause or it might go from two straight down to zero but in a case for me my database is currently running at zero capacity units because this time frame has been reached with no activity and the compute has been paused so this means I have no costs for the compute side of Aurora serverless now if I go back to the application and do a refresh you'll see that we don't get a refresh straight away there's a pause and this is because now that the database cluster experiences some incoming load it's unpausing that compute it's resuming the compute part of the cluster and this isn't an immediate process so it's important to understand that when you implement an application and use this functionality the application does need to be able to tolerate lengthier connection times now sometimes in the case of WordPress you will see an error page when you attempt to do a refresh because a timeout value within WordPress is reached before the cluster can resume in the case of this demo lesson that didn't happen it was able to resume the cluster straight away and if we go back to the RDS console and then refresh this page we'll be able to see just how many capacity units this cluster is now operating with and it's operating with two capacity units now in production usage you could be a lot more granular and customize this based on the needs of your application in my case my minimum is one and my maximum is two and my pause time frame is a relatively low five minutes because I wanted to keep it simple for this demo lesson in production usage you might have a larger range between minimum and maximum you might have a higher minimum to be able to cope with a certain level of base load and the time frame between the last access and the pausing of the compute might be significantly longer than five minutes but this demonstration lesson is just that a demo and it's just designed to highlight this at a really high level so that when it comes to you using this in production you understand the architecture now that's everything that I wanted to cover in this demo lesson it's just been a brief bit of experience of using Aurora serverless now to tidy up to return the account into the same state as it was at the start of the demo lesson just go ahead and close down all of these tabs we need to go back to the cloud formation console make sure the Aurora serverless stack is selected and then just go ahead and click on delete and then delete stack and that will remove all of those resources returning the account into the same state as it was at the start of the demo now this whole section of the course has been around trying to improve the database part of our application so we've moved from having a database running on the same server as the application we've split that off we've moved it into rds and we've evolved that from my sequel rds through to Aurora provisioned and now to Aurora serverless we still have one major limitation with our application and that's that for any posts you make on the blog the media for those posts are stored locally on the instance file system and that's something that we're going to start tackling next in the course and we're going to be using the elastic file system product or EFS at this point though that's everything that I wanted to cover in this demo lesson go ahead and complete this video and when you're ready I look forward to you joining me in the next.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

Now the next thing that I want to demonstrate is how we can restore RDS if we have data corruption.

The way that we're going to simulate this is to go back to our WordPress blog and we're going to corrupt part of this data.

So we're going to change the title of this blog post from the best cats ever to not the best cats ever, which is clearly untrue.

But we're going to change this and this is going to be our simulation of data corruption of this application.

So go ahead and click on update to update the blog post with this new obviously incorrect data.

Now let's assume that we need to restore this database from an earlier snapshot.

Now let's ignore the automatic backup feature of RDS and just look at manual snapshots.

Well, let's move back to the RDS console and click on snapshots and we'll be able to see the snapshot that we created at the start of this demo lesson.

Remember, this does have the blog post contained within it in its original correct form.

Now to do a restore, we need to select this snapshot, click on actions and then restore snapshot.

Now I mentioned this in the theory lesson about backups and restores within RDS.

Restoring a snapshot actually creates a brand new database instance.

It doesn't restore to the existing one using normal RDS.

So we have to restore a snapshot.

Obviously the engine set to MySQL community and we're provided with an entry box for a brand new database identifier.

And we're going to use a4lwordpress-restore.

So this allows us to more easily distinguish between this and the original database instance.

We also need to decide on the deployment option.

So go ahead and select single DB instance.

This is only a demo, so we don't need to select multi-AZ DB instance.

We need to pick the type of instance that we're going to restore to.

And again, because this is a new instance, we're not limited to the previous free tier restrictions.

So we're able to select from any of the available instance types.

So go ahead and select burstable classes and then pick either t2 or t3.micro.

We'll leave storage as default.

We'll need to provide the VPC to provision this new database instance into.

So we'll make sure that a4l-vpc1 is selected and we'll use the same subnet group that was created by the one-click deployment, which you used at the start of this demo.

You're allowed to choose between public access yes or no.

We'll choose no.

You'll have to pick a VPC security group to use for this RDS instance.

Now the one-click deployment did create one, so click in the drop-down and select the RDS multi-AZ snap RDS security group.

So not the instance security group, but the RDS security group.

Once you've selected that, then delete default, scroll down.

You can specify database authentication and encryption settings.

And again, if applicable in the course that you're studying, I'll be covering these in a separate lesson.

We'll leave all of that as default and click on restore DB instance.

Now this is going to begin the process of restoring a brand new database instance from that snapshot.

Now the important thing that you need to understand is this is a brand new instance.

We're not restoring the snapshot to the same database instance.

Instead, it's creating a brand new one.

Now when this finishes restoring, when it's available for use, if we want our application to make use of it, and the restored non-corrupted data, then we're going to need to change the application to point at this newly restored database.

So at this point, go ahead and pause the video because for the next step, which is to adjust the WordPress configuration, we need this database to be in an available state.

So pause the video, wait for the status to change from creating all the way through to available, and then we're good to continue.

Okay, so the snapshot restore is now completed and we have a brand new database instance, A4LWordPress-Restore.

And in my case, it took about 10 minutes to perform that restoration.

Now just to reiterate this concept, because it's really important, it features all the time in the exams, and you'll need this if you operate in the real world using AWS.

If we go into the original RDS instance, just pay attention to this endpoint DNS name.

So we have a standard part, which is the region, and then .rds, and then .amazonaws.com.

Before this, though, we have this random part.

Now this represents the name of the database instance as well as some random.

If we go back to the databases list and then go into the restored version, now we can see that we have A4LWordPress-Restore.

And this is different than that original database endpoint name for the original database.

So the really important, the critical thing to understand is that a restore with a normal RDS will create a brand new database instance.

It will have a brand new database endpoint DNS name, the CNAME, and you will need to update any application configuration to use this brand new database.

So go ahead and just leave this open in this tab because we'll be needing it very shortly.

Click on Services, find EC2, and open that in a new tab.

So as a reminder, if we go back to the WordPress tab and just hit Refresh, we can see that we still have the corrupt data.

Now what we want to do is point WordPress at the restored correct database.

So to do that, go to the EC2 tab that you just opened, right click on the A4LWordPress instance, select Connect.

We're going to use Instance Connect, so choose that to make sure the username is EC2-user and then connect to the instance.

This process should be familiar by now because we're going to edit the WordPress configuration file.

So cd/var/www/html, then we'll do a listing ls-la, and we want to edit the configuration file which is wp-config.php, so shudu, space, nano which is the text editor, space, wp-config.php.

Once we're in this file, just scroll down and again we're looking for the dbhost configuration which is here.

Now this DNS name you'll recognize is pointing at the existing database with the corrupt data.

So we need to delete all of this just to leave the two single quotes.

Make sure your cursor's over the second quote.

Go back to the RDS console and we need to locate the DNS name for the A4LWordPress-Restore instance.

Remember this is the one with the correct data.

So copy that into your clipboard, go back to EC2 and paste that in, and then Ctrl+O and Enter to save, and Ctrl+X to exit.

That's all of the configuration changes that we need.

If we go back to the WordPress application and hit refresh, we'll see that it's now showing the correct post, the best cats ever, because we're now pointing at this restored database instance.

So the key part about this demo lesson really is to understand that when you're restoring a normal RDS snapshot, you're restoring it to a brand new database instance, its own instance with its own data and its own DNS endpoint name.

So you have to update your application configuration to point at this new database instance.

With normal RDS, it's not possible to restore in place.

You have to restore to a brand new database instance.

Now this is different with a feature of Aurora which I'll be covering later in this section, but for normal RDS, you have to restore to a brand new instance.

So those are the features which I wanted to demonstrate in this demo lesson.

I wanted to give you a practical understanding of the types of recovery options and resilience options that you have available using the normal RDS version, so MySQL.

Now different versions of RDS such as Microsoft SQL, PostgreSQL, Oracle, and even AWS specific versions such as Aurora and Aurora Serverless, they all have their own collections of features.

For the exam and for most production usage, you just need to be familiar with a small subset of those.

Generally, you'll either be using Oracle, MSSQL, or one of the open source or community versions, so you'll only have to know the feature set of a small subset of the wider RDS product.

So I do recommend experimenting with all of the different features and depending on the course that you're taking, I will be going into much more depth on those specific features elsewhere in this section.

For now though, that is everything that I wanted to talk about, so all that remains is for us to tidy up the infrastructure that we've used in this demo lesson.

So go to databases.

I want you to select the A4L WordPress -Restore instance because we're going to delete this fully.

We're not going to be using this anymore in this section of the course, so select it, click on the Actions drop down, and then select Delete.

Don't create a final snapshot.

We don't need that.

Don't retain automated backups and because we don't choose either of these, we need to acknowledge our understanding of this and type Delete Me into this box.

So do that and then click on Delete.

Now that's going to delete that instance as well as any snapshots created as part of that instance.

So if we go to Snapshots, we only have the one manual snapshot.

If we go to System Snapshots, we can see that we have one snapshot for this Restore database, and if you're deleting a database instance, then any system created snapshots for that database instance will also be deleted either immediately or after the retention period expires.

So those will be automatically cleared up as part of this deletion process.

We're not going to delete the manual snapshot that we created at the very start of this lesson with the catpost in because we're going to be using this elsewhere in the course.

So leave this in place.

Click on Databases again.

We're going to need to wait for this Restored Database instance to finish deleting before we can continue.

So go ahead and pause the video, wait for this to disappear from the list, and then we can continue.

Okay, so that Restored Database instance has completed deleting.

So now all that remains is to move back to the CloudFormation console.

You should still have a tab open.

Select the stack deployed as part of the one-click deployment.

It should be called RDS Multi-AZ Snap.

Select Delete and then confirm that deletion, and that will clear up all of the infrastructure that we've used in this demo lesson.

It will return the account into the same state as it was at the start of this demo with one exception.

And that one exception is the snapshot that we created of the RDS instance as part of this deployment.

So that's everything you need to do in this demo lesson.

I hope you've enjoyed it.

I know it's been a fairly long one where you've been waiting a lot of the time in the demo for things to happen, but it's important for the exam and real-world usage that you get the practical experience of working with all of these different features.

So you should leave this demo lesson with some good experience of the resilience and recovery features available as part of the normal RDS product.

Now at this point, that's everything you need to do, so go ahead and complete this video, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this demo lesson we're going to continue implementing this architecture.

So in the previous demo lesson you migrated a database from a self-managed MariaDB running on EC2 into RDS.

In this demo lesson you're going to get the experience working with RDS's multi-availability zone mode as well as creating snapshots, restoring those snapshots and experimenting with RDS failover.

Now in order to complete this demo lesson you're going to need some infrastructure.

So let's move across to our AWS console.

You need to be logged in to the general AWS account.

So that's the management account of the organization and as always make sure that you have the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment link so go ahead and open that.

This will take you to a quick create stack page and everything should be pre-populated and ready to go.

So the stack name is RDS multi-AZ snap.

All of the parameters have default values.

Multi-AZ is currently set to false so leave that at false, check the capabilities box at the bottom and then click on create stack.

Now this infrastructure will take about 15 minutes to apply and we need it to be in a create complete state before we continue.

So go ahead, pause the video and resume it once CloudFormation has moved into a create complete state.

Okay so now that this stack has moved into a create complete state we need to complete the installation of WordPress and add our test blog post because we're going to be using those throughout this demo lesson.

Now this is something that you've done a number of times before so we can speed through this.

So click on the services drop down, move to the EC2 console.

We need to go to running instances and we'll need the public IP version 4 address of A4L-WordPress.

So go ahead and copy the public IP version 4 address into your clipboard.

Don't use this open address.

Open that in a new tab.

We'll be calling the site as always the best cats for username put admin for the password.

We'll be using the animals for life strong password and then as always test at test.com for the email address.

Enter all of that and click on install WordPress.

Then you'll need to log in admin for the username and to the password click on login.

Once we logged in go to posts click on trash under hello world to delete the existing post and then add a new post.

Close down this dialogue for the title of the post the best cats ever click on the plus select gallery.

At this point go ahead and click the link that's attached to this lesson to download the blog images.

Once downloaded extract that zip file and you'll get four images.

Once you've got those images ready click on upload locate those images select them and click on open and that will add those to the post.

Once they're fully loaded in we can go ahead and click on publish and then publish again and that will publish this post to our blog.

And as a reminder that stores these images on the local instance file system and adds the post metadata to the database and that's now running within RDS.

Now I want to step through a few pieces of functionality of RDS and I want you for a second to imagine that this blog post is actually a production enterprise application.

Maybe a content management system and I want to view all of the actions that we perform in this demo lesson through the lens of this being a production application.

So go ahead and return to the AWS console click on services and we're going to move back to RDS.

The first thing that we're going to do is to take a snapshot of this RDS instance.

So just close down any additional dialogues that you see go to databases.

Then I want you to select the database that's been created by the one click deployment link that you used at the start of this demo lesson.

Then select actions and then we're going to take a snapshot.

Now a snapshot is a point in time copy of the database.

When you first do a snapshot it takes a full copy of that database so it consumes all of the capacity of the data that's being used by the RDS instance.

So this initial snapshot is a full snapshot containing all of the data within that database instance.

Now we're going to take a snapshot and we're going to call it a four L wordpress hyphen with hyphen cat hyphen post hyphen mySQL hyphen and then the version number without any dots or spaces.

Now depending on when you're watching this video doing this lesson you might have been using a different version of SQL.

And so in the lesson description for this lesson I've included the name of the snapshot that you need to use.

So go ahead and check that now and include that in this box.

So that informs us what it is, what it contains and the version number that this snapshot refers to.

So go ahead and enter that and then click on take snapshot and that's going to begin the process of creating this snapshot.

Now the process takes a variable amount of time.

It depends on the speed of AWS on that particular day.

It depends on the amount of data contained within the database and it also depends on whether this is the first snapshot or a subsequent snapshot.

Now the way that snapshots work within AWS is the first snapshot contains a full copy of all of the data of the thing being snapshotted and any subsequent snapshot only contains the blocks of data which have changed from that last previous successful snapshot.

So of course the first snapshot always takes the longest and everything else only takes the amount of time required to copy the changed data.

So if we just give this a few minutes let's keep refreshing.

Mine's still reporting at 0% complete so we need to allow this to complete before we move on.

So go ahead and pause the video and resume it once your snapshot has completed.

And there we go our snapshots now moved into an available status and the progress has completed.

And in my case that took about five minutes to complete from start to finish.

So again just to reiterate this snapshot has been taken.

It's a copy of an RDS MySQL database of a particular version and it contains our WordPress database together with the cat post that we just added.

And that's important to keep in mind as we move on with the demo lesson.

Now you could go ahead and take another snapshot and this one would be much quicker to complete.

It would only contain any data changed between the point that you take it and when you took this previous snapshot.

I'm not going to demonstrate that in this video but you can do that.

And for production usage you may use snapshots in addition to the normal automated backups provided by RDS.

Snapshots that you take manually live past the life cycle of the RDS instance.

And if you want to tidy them up you have to do that manually or by using scripts that you create.

So snapshots that are taken manually are not managed by RDS in any way.

And that's important to understand from a DR and the cost management perspective.

Now the next thing that I want to demonstrate is the multi AZ mode of RDS.

So if we go back to the RDS console just expand this menu and go to databases.

Currently this database is using a single RDS instance.

So this RDS instance is not resilient to the failure of an availability zone within this region.

Now to change that process we can provision a standby replica in another availability zone and that's known as multi AZ.

Now it's worth noting that this is not included within the AWS free tier.

So there will be a small charge to do this optional step to enable multi AZ mode.

Make sure that you have the database instance selected and then click on modify.

Now it's on this screen that we can change a lot of the options which relate to this entire RDS instance.

We've got the option to adjust the database identifier, provide a new database admin password.

We can change the DB instance size or type if we want.

We can adjust the amount of storage available to the database instance, even enable storage auto scaling.

But what we're looking for specifically is adjusting the availability and durability settings.

Currently this is set to do not create a standby instance and we're going to modify this.

We're going to change it to create a standby instance and this is something that's recommended for any production usage.

This creates a standby replica in a different availability zone.

So it picks another availability zone, specifically another subnet that's available within the database subnet group that was created by the one click deployment.

So we're going to set that option and scroll down and then select continue.

Now because we have a maintenance window defined on this RDS instance, we have two different options of when to apply this change.

We can either apply the change during the next scheduled maintenance window.

Remember, this is a definable value that you can set when you create an RDS instance or you modify its settings.

Or we can specify that we want to apply immediately the change that we're making.

And for this demo lesson, that's what we're going to do.

Now it does warn you that any changes could cause a performance impact and even an outage.

So it's really important that if you are applying changes immediately, you understand the impact of those changes.

So make sure that you have apply immediately selected and then click on modify DB instance.

Now a multi AZ deployment is essentially an automatic standby replica in a separate availability zone.

What happens behind the scenes is that the primary database instance is synchronously replicated into this standby replica inside a different availability zone.

Now this provides a few benefits.

It provides data redundancy benefits.

It means that any operations which can interrupt IO such as system backups will occur from the standby replica.

So won't impact the primary database and that provides a real advantage for production RDS deployments.

But the main reason beyond performance is that it helps protect any databases in the primary instance against failure of an availability zone.

So if the availability zone of the primary instance fails and then the C name of the database will be changed to point at the standby replica.

And that will minimize any disruption to your application and its users.

Now if we just hit refresh, we can see the status is modifying and what's happening behind the scenes is AWS are taking a snapshot of the primary DB instance.

It's restoring that snapshot into the standby replica, which is in a different availability zone.

And then it's setting up synchronous replication between the primary and the standby replica.

So this is a process which happens behind the scenes.

But it does mean that we need to wait for this process to be complete until the process is complete.

This is not a multi AZ deployment.

So go ahead and pause the video and wait for the status to change away from modifying.

We need this to be in an available state in order to continue with the demo.

So go ahead and pause the video and resume it once this modification has completed.

Okay, so the status has now changed to available.

And in my case, it took about 10 minutes to enable multi AZ mode.

So that's the provisioning of a standby replica in another availability zone.

Now, the likelihood of an AZ failure happening while I'm recording this demo lesson is relatively small, but we can simulate a failure to do that.

If we have the database instance selected and then select the actions drop down and then reboot, we can use the option reboot with failover.

If we choose this option, then part of the process is that a simulated failover occurs.

So the C name, the database endpoint, that's moved so that it now points at the standby replica and then the old primary instance is restarted.

So that's what we're going to do to simulate this process.

So go ahead and select to reboot the database instance.

Make sure that you have reboot with failover selected and then click on confirm.

And this will begin the process of rebooting the database instance.

Now, if we go back to the WordPress blog and we click on view post, you'll see that right away it's not immediately loading.

And that's because the failover from the primary to the standby isn't immediate.

Failover times are typically 60 to 120 seconds.

So that's important to keep in mind if you're deploying RDS in a business critical situation.

It doesn't offer immediate failover.

So let's just stop this and hit reload again.

And now we can see that the page is starting to load because the C name for the database has been moved from pointing at the primary to pointing at the standby replica, which is the new primary.

Okay, so this is the end of part one of this lesson.

It was getting a little bit on the long side and so I wanted to add a break.

It's an opportunity just to take a rest or grab a coffee.

Part two will be continuing immediately from the end of part one.

So go ahead, complete the video and when you're ready, join me in part two.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

Okay, so the instance is now in an available state.

Let's just close down this informational dialogue at the top.

And let's just minimize this menu on the left.

Let's maximize the amount of screen space that we have for this specific purpose.

So I just want us to go inside this database instance and explore together the information that we have available.

So I talked in the theory lesson how every RDS instance is given an endpoint name and an endpoint port.

So this is the information that we'll use to connect to this RDS instance.

Networking wise, this instance has been provisioned in US-EAST-1A.

It's in the Animals for Life VPC and it's used our A4L subnet group that we created at the start of this demo.

And that means that it's currently utilizing all three database subnets in the Animals for Life VPC.

But it's chosen because we only deployed one instance to use US-EAST-1A.

Now this is the VPC security group that we're going to need to configure.

So right click on this and open it in a new tab and move to that tab.

This is the security group which controls access to this RDS instance.

So let's expand this at the bottom.

So currently it has my IP address being the only source allowed to connect into this RDS instance.

So the only inbound rule on the security group protecting this RDS instance is allowing my IP address.

So we're going to click on Edit and then click on Add Rule.

And we're going to add a rule which allows our other instances to connect to this RDS instance.

So first in the type drop down click and then type mySQL to get the same option as the line above and then click to select.

Next go ahead and type instance into the source box and then select the migrate to RDS-instance security group.

Now this is the security group that's used by any instances deployed by our one click deployment.

And this allows those instances to connect to our RDS instance and that's what we want.

So go ahead and select that and then click on Save Rules.

And this means now that our WordPress instance can communicate with RDS.

So now let's move back to the RDS tab and then make sure we're inside the A4L WordPress database instance.

So that's the connectivity and the security tab.

We also have the monitoring tab and it's here where you can see various CloudWatch provided metrics about the database instance.

You also have logs and events related to this instance.

So if we go and have a look at recent events we can see all of the events such as when the database instance was created, when its first backup was created.

And you can explore those because they might be different in your environment.

You can click on the Configuration tab and see the current configuration of the RDS instance.

The Maintenance and Backups tab is where you can configure the maintenance and backup processes and then of course you can tag the RDS instance.

Now in other lessons in this section of the course and depending on what course you're taking I will be talking about many of these options, what you can modify and which actions you can perform on RDS instances.

But for now we're just going to move on with this demo.

So the next step is that we need to migrate our existing data into this RDS instance.

So what we're going to do is to click on the Connectivity and Security tab and we're going to leave this open.

We're going to need this endpoint name and port very shortly.

You should still have a tab open to the EC2 console.

If you don't you can reach that by going on Services and then opening EC2 in a new tab.

But I want you to select the A4L-WordPress instance and then right click and connect to it using Instance Connect.

So go ahead and do that.

Once you've done that we're going to start referring to the lesson commands document.

So make sure you've got that open.

We're going to use this command to take a backup of the existing MariaDB database.

So we need to replace a placeholder.

What we need to do is delete this and replace it with the private IP address of the MariaDB EC2 instance.

So go back to the EC2 console, select the DB-WordPress instance and copy the private IP version 4 address into your clipboard.

And then let's move back to the WordPress instance and paste that in.

Go ahead and press Enter and it will prompt you for the password.

And the password is the same Animals for Life strong password that we've been using everywhere.

Copy that into your clipboard.

So this is the password for the A4L WordPress user on the MariaDB EC2 instance.

So paste that in and press Enter and then LS-LA to confirm that we now have this A4L WordPress.SQL database backup file.

And we do, so that's good.

So as we did in the previous demo lesson, we're going to take this backup file and we're going to import it into the new destination database, which is going to be the RDS instance.

To do that, we'll use this command, but we're going to need to replace the placeholder hostname with the CNAME of the RDS instance.

So go ahead and delete this placeholder, then go back to the RDS console and I'll want you to copy the endpoint name into your clipboard.

So select it, right click and then copy.

We won't need the port number because this is the standard MySQL port and if you don't specify it, most applications will assume this default.

So just make sure that you have the endpoint DNS name or endpoint CNAME in your clipboard.

And then back on the WordPress EC2 instance, go ahead and paste this database name into this command and press Enter.

And again, you'll be asked for the password and that's the same Animals for Life strong password.

So copy that into your clipboard, paste that in and press Enter.

And that's imported this A4LWordPress.SQL file into the RDS instance.

So now we need to follow the same process and change WordPress so that it points at the RDS instance.

And we do that by moving to where the WordPress configuration file is.

So cd space forward slash var forward slash ww w forward slash html and press Enter.

And then shudu.

So we have admin privileges, nano, which is a text editor and then wp-config.php and press Enter.

Then we need to scroll down and we're looking for where it says DB host and currently it has a host name here.

Now if you go back to the EC2 console and you look at the A4L-DB-WordPress instance, you'll see that its private IP version for DNS name is what's listed inside this configuration item.

So it's currently pointing at this dedicated database instance.

What we need to do is replace that and we're going to replace it with the RDS database DNS name or the CNAME of this RDS instance.

So copy that into your clipboard and then go ahead and delete this private DNS name for the MariaDB EC2 instance and then paste in the RDS endpoint name, also known as the RDS CNAME.

Once you've done that, control O and Enter to save and control X to exit.

And now our WordPress instance is pointing at the RDS instance for its database.

Now we can verify that by checking WordPress, move back to instances, select the WordPress instance, copy the public IP version for addressing to your clipboard.

Don't use this open address link.

Open that in a new tab.

Go ahead and just click on the best cats ever to verify the functionality and it does look as though it's working.

And to verify that, if we go back to the EC2 console, select the A4L-DB-WordPress instance and right click and then stop that instance.

Now the original database that was providing database services to WordPress is going to move into a stopped state.

And if our WordPress blog continues functioning, we know that it's using the RDS instance.

So let's keep refreshing and wait for this to change into a stopped state.

There we go.

It's stopped.

And if we go back to our WordPress page and refresh, it still loads.

And so we know that it's now using RDS for its database services.

So at this point, that's everything that I wanted you to do in this demo lesson.

You've stepped through the process of provisioning an RDS instance.

So you've created a subnet group, provisioned the instance itself, explored the functionality of the instance, including how to provide access to it by selecting a security group.

And then editing that security group to allow access.

You've performed a database migration and you've explored how the RDS instance is presented in the console.

So that's everything that you need to do within this demo lesson.

And don't worry, we're going to be exploring much more of the advanced functionality of RDS as we move through this section of the course.

For now, though, I want us to clear up the infrastructure that we've created as part of this demo lesson.

Now, because we've provisioned RDS manually outside of CloudFormation, unfortunately, there is a little bit more manual work involved in the cleanup.

So I want you to go to the RDS console, move to databases, select this database, click on actions, and then select delete.

Now it will prompt you to create a final snapshot and we're not going to do that.

We're not going to retain automated backups and so you'll need to acknowledge that upon instance deletion, automated backups including any system snapshots and pointing time recoveries will no longer be available.

And don't worry, I'll be talking about backups and recovery in another lesson in this section of the course.

For now, just acknowledge that and then type delete me into this box and confirm the deletion.

Now this deletion is going to take a few minutes.

It's not an immediate process.

It will start in a deleting state and we need to wait for this process to be completed before we continue the cleanup.

So go ahead and pause this video and wait for this instance to fully delete before continuing.

Now that the instance has been deleted, it vanishes from this list.

Next, we need to delete the subnet group that we created earlier.

So click on subnet groups, select the subnet group and then delete it.

You'll need to confirm that deletion.

Once done, it too should vanish from that list.

Next, go to the tab you've got open to the VPC console, scroll down and select security groups.

Now look through this list and locate the security group that you created as part of provisioning the RDS instance.

It should be called a4LVPC-RDS-SG.

Select that, click on actions and then delete security group and you'll need to confirm that process as well.

Once that's deleted, the final step is to go to the cloud formation console and then you'll need to delete the cloud formation stack that was created using the one-click deployment at the start of the demo.

It should be called migrate to RDS.

Select it, click on delete and confirm that deletion.

And once deleted, the account will be returned into the same state as it was at the start of the demo lesson.

So all of the infrastructure that we've used will be removed from the account and the account will be in the same state as at the start of the demo.

Now I hope you've enjoyed this demo and that we're repeating the same WordPress installation and then the creation of the blog post over and over again.

But I want you to get used to different parts of this process over and over again.

You need to know why not to use a database on EC2.

You need to know why not to perform a lot of these processes manually.

From this point onward in the course, we're going to be using RDS to evolve our WordPress design into something that is truly elastic.

And so all of these processes, the things I'm having you repeat are really useful to aid in your understanding of all of these different components.

So from this point onward, we're going to be automating the creation of RDS and focusing on the specific pieces of functionality that you need to understand.

But at this point, that's everything that you need to do in this demo.

So go ahead, complete the video and when you're ready, I look forward to you joining me in the next.

Welcome back and in this demo lesson you're going to get some experience of how to provision an RDS instance and how to migrate a database from an existing self-managed MariaDB database instance through to RDS.

So over the next few demo lessons in this section of the course, you're going to be evolving your database architecture.

We're going to start with a single database instance, then we're going to add multi-AZ capability as well as talking about backups and restores.

But in this demo lesson specifically, we're going to focus on provisioning an RDS instance and migrating data into it.

Now in order to get started with this demo lesson, as always make sure that you're logged into the general AWS account, so the management account of the organization and you need to have the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment link that you'll need to use to provision this demo lesson's infrastructure.

So go ahead and click on that link now.

That's going to move you to a quick create stack screen.

The stack name should be pre-populated with migrate to RDS.

Scrolling down all of the parameter values will be pre-populated.

All you need to do is to click on the capabilities checkbox and then create stack.

There's also a lesson commands document linked to this lesson and I'd suggest you go ahead and open that in a new tab because you'll be referencing it as you move through this demo lesson.

Now you'll notice that this will look similar to the previous demo lesson's lesson commands document, but it has one small difference.

The initial command way of doing the backup of the source database, because that source database is going to be stored on a separate MariaDB database running on a separate EC2 instance, instead of taking the backup from the local instance, in this case it's connecting to a separate EC2 instance.

Otherwise, most of these commands are similar to the ones you used in the previous demo lesson.

Now you're going to need to wait for this stack to move into a create complete state before you continue the demo.

So go ahead and pause the video, wait for your stack to change to create complete and then you're good to continue.

Okay, so that cloud formation stack has now moved into a create complete state and it's created a familiar set of infrastructure.

Let's go ahead and click on the services drop down and then move to the EC2 console and just take a look.

So if we click on instances, you'll see that we have the same two instances as you saw in the previous demo lesson.

So we have A4L-WordPress, which is running the Apache web server and the WordPress application.

And then we have A4L-DB-WordPress and this is running the separate MariaDB database instance.

So what we need to do in order to perform this migration is first create the WordPress blog itself and the sample blog post.

And this is the same thing that we did in the previous demo.

So we should be able to go through this pretty quickly.

So go ahead and select the A4L-WordPress instance and copy its public IP version for address into your clipboard and then open that in a new tab.

And again, make sure not to use the open address because this uses HTTPS.

So copy the public IP version for address and then open that in a new tab.

Again, we're going to call the site the best cats.

We're going to use admin for the username.

And then for the password, let's go back to the CloudFormation tab.

Make sure you've got the migrate to RDS stack selected and then click on parameters.

We're going to use the same database password.

So copy that into your clipboard and replace the automatically generated one with the animals for live complex password.

And then enter test@test.com into the email box and click on install WordPress.

Once installed, click on login.

You'll need to use the admin username and the same password.

Click on login.

Then we're going to go to posts.

We're going to select the existing Hello World post.

Select trash this time.

Then click on add new.

Close down this dialog for title.

We're going to use the best cats ever.

Click on the plus.

Select gallery.

At this point, go ahead and click the link that's attached to this lesson to download the blog images.

Once downloaded, extract that zip file and you'll get four images.

Once you've got those images ready, click on upload, locate those images, select them and click on open.

Wait for them to load in.

Select publish and publish again.

And that saved the images onto the application instance and added the data for this post onto the separate MariaDB database.

So now we have this simple working blog.

Let's go ahead and look at how we can provision an RDS instance and how we can migrate the data into that RDS instance.

So move back to the AWS console.

Click on the services drop down and type RDS into the search box and open that in a new tab.

Now, as I've mentioned in the theory parts of this section, RDS is a managed database server as a service product from AWS.

It allows you to create database instances and those instances can contain databases that your applications can make use of.

Now to provision an RDS instance, the first thing that we need to do is to create a subnet group.

Now a subnet group is how we inform RDS which subnets within a VPC we want to use for our database instance.

So first we need to create a subnet group.

So select subnet groups on the menu on the left and then create a DB subnet group.

Now we're going to use a4lsn group, so animals for life subnet group for both the name and for the description.

And then select the VPC drop down and we're going to select the a4l-vpc1vpc.

So this is the animals for life VPC which has been created by the one click deployment that you used at the start of this demo.

Now once we've selected a name and a description and a VPC for this subnet group, then what we need to do is select the subnets that this database will be going into.

So we're going to select the database subnets in US East 1A, US East 1B and US East 1C.

So click on the availability zone drop down and pick those three availability zones.

So 1A, 1B and 1C.

Once we've selected the availability zones that this subnet group is going to use, next we pick the subnets.

So click on the drop down.

Now we want to pick the database subnets within the animals for life VPC and all we can see here are the IP address ranges.

So to help us with this click on the services drop down, type VPC and then open that in another new tab.

Once that loads, go ahead and click on subnets, sort the subnets by name and then locate sn-dba, dbb and dbc.

And just move your cursor across to the right hand side and note what the IP address ranges are for those different database subnets.

So 16, 80 and 144.

Go back to the RDS console, click on the subnets drop down and we need to pick each of those three subnets.

So 16, 80 and 144.

So these represent the database subnets in availability zone 1A, 1B and 1C.

And then once we've configured all of that information, we can go ahead and click on create to create this subnet group.

So this subnet group is something that we use when we're provisioning an RDS instance.

And as I mentioned moments ago, it's how RDS determines which subnets to place database instances into.

Now when we're only using a single database instance, then that decision is fairly easy.

But RDS deployments can scale up to use multiple replicas in multiple different availability zones.

You can have multi-AZ instances, read replicas.

Aurora has a cluster architecture which we'll talk about later in this section.

And so subnet groups are essential to inform RDS which subnets to place things into.

So now that we've configured that subnet group, let's go ahead and provision our RDS database instance.

So to do that, click on databases and then we're going to create a database.

So click on create database.

Now when you're creating a database, you have the option of using standard create where you have visibility of all of the different options and then easy create which applies some best practice configurations.

Now I want you to get the maximum experience possible, so we're going to use standard create.

Now when you're creating an RDS database instance, you have the ability to pick from many different engines.

So some of these are commercial like Oracle or Microsoft SQL Server.

And with some of these, you have the option of either paying for a license included with RDS or you can bring your own license.

For other database engines, there isn't a commercial price to pay for their usage and so they're much cheaper to use.

But you should select the engine type which is compatible with your application.

Now we're going to be talking about Amazon Aurora in dedicated lessons later in this section of the course.

Amazon Aurora is an AWS designed database product which has compatibility with MySQL and PostgreSQL.

For this demo lesson, we're going to use MySQL.

So go ahead and select MySQL and it's going to be using MySQL Community Edition.

So now let's just scroll down and step through some of the other options that we get to select when provisioning an RDS instance.

Now for all of these database engines, you have the ability to pick different versions of that engine.

And this is fairly critical because there are different major and minor versions that you can select from.

And different versions of these have different limitations.

So for example, we're going to be talking about snapshots later in this section.

And if you want to take a snapshot of an RDS database and then import that into an Aurora cluster, you need to pick a compatible version.

And then Aurora Serverless which we'll be talking about later on in this section has even more restrictions.

Now to keep things simple, I want you to ignore what version I pick in this video and instead look in this lesson's description and pick the version that I indicate in the lesson description because I'll keep this updated if AWS make any changes.

Now you can choose to use a template.

These templates give you access to only the options which are relevant for the type of deployment that you're trying to use.

So in production, you would pick the production template.

If you have any smaller or less critical dev or test workloads, then you could pick this template.

If you want to ensure that you can only select free tier options, then you should pick this template.

And that's what we're going to do in this demo because we want this demo to fall under the free tier.

So click on the free tier template.

I'll be talking about availability and durability later in this section because we've selected free tier only.

We don't have the ability to create a multi AZ RDS deployment.

And now we need to provide some configuration information about the database instance specifically.

So the first thing that we need to do is to provide a database instance identifier.

So this is the way that you can identify one particular instance from any other instances in the AWS account in the current region.

So this needs to be unique.

So we're going to use a four L WordPress for this database instance.

Then we need to pick a username which will be given admin privileges on this database instance.

And we're going to replace admin with a four L WordPress.

So we're going to use this for both the database identifier and the admin user of this database.

Now for the password for this admin user, we're going to move back to the cloud formation console and we're going to use this same animals for life complex password.

So copy that into your clipboard and paste it in for the password and the confirm password box.

And this just keeps things consistent between the self banished database and the RDS database.

Scroll down further still and it's here where you can select the database instance class to use.

Now because we've selected free tier only, we're limited as to what database size and type we can pick.

If we'd have selected production or dev test from the templates above, we would have access to a much wider range of database instance classes, both standard, memory optimized and burstable.

But because we've selected the free tier template, we're limited as to what we can select.

Now this might change depending on when you're watching this demonstration, but at the point I'm recording this video, it's db.t3.micro.

So don't be concerned if you see something different in this box.

Just make sure that you select the type of instance which falls under the free tier.

Then continue scrolling down and we need to pick the size of storage and the type of storage to use for this RDS instance.

Now whether you need to select this is dependent on what engine type you pick.

If you select Aurora, which we'll be talking about later on in this section, then you don't need to pre-allocate storage.

If you're using the MySQL version of RDS, then you do need to set a type of storage and a size of storage.

Now we're going to use the minimum which is 20GIB because our requirements for this database are relatively small.

And if we wanted to, if this was production, we could set storage autoscaling.

And this allows RDS to automatically increase the storage when a particular threshold is met.

But again, because this is a demo and it's only using a very small blog, we don't need storage autoscaling.

So go ahead and uncheck that option.

Now we need to select a VPC for this RDS instance to go into.

So click in the drop down and select the Animals for Life VPC.

So that's A4L-VPC1.

And then we need to pick a subnet group.

Now this is the thing that we've just created.

We only have one in this account, so there's nothing else to select.

But this is how we can advise RDS on which subnets to use inside the VPC.

Scroll down further still and we can specify whether we want this database to be available.

We want this database to be publicly accessible.

So this is whether we want instances and devices outside the VPC to be able to connect to this database.

This obviously comes with some security trade-offs.

And because we don't need that in this demonstration, because the only thing that we want to connect to this RDS instance is our WordPress instance, which is in the same VPC, then we can select Not to Use Public Access.

So make sure the No option is selected.

Now the way that you control access to RDS is you allocate a VPC security group to that instance.

So we could either choose an existing security group or we could create a new one.

So it's this security group which surrounds the network interfaces of the database and controls access to what can go into that database.

So we want to create a new VPC security group.

So we want to make that option.

We're going to call the security group A4LVPC-RDS-SG.

And we need to remember to update this so that our WordPress instance can communicate with our RDS instance.

And we'll do that in the next step.

If we wanted to pick a specific availability zone for this instance to go into, then we could select one here or we can leave it up to RDS to pick the most suitable.

So we can select No Preference.

Continue scrolling down.

We won't change the Database Authentication option because we want to allow password authentication.

Continue scrolling down and we're going to expand Additional Configuration.

By default, an RDS instance is created with no database on that instance.

In this case, because we're migrating an existing WordPress database into RDS, we're going to go ahead and create an initial database.

And to keep things easy and consistent, we're going to use the same name, so A4L WordPress.

Now you can enable automatic backups for RDS instances.

And I'll be talking about these in a separate theory lesson.

If you do select automatic backups, then you can also pick a backup retention period as well as a backup window.

So we've got Advanced Monitoring, various log exports.

We don't need to use any of those.

You can also set the Maintenance window for an RDS instance.

So when Maintenance will be performed, you can enable Deletion Protection if you want.

If this is a production database, we don't need to do that.

What we're going to do is scroll all the way down to the bottom and then click on Create Database.

Now this process can take some time.

I've seen it take anywhere from five to 45 minutes.

And we're going to need this to be finished before we move on to the next step.

So this seems like a great time to end this video.

It gives you the opportunity to grab a coffee or stretch your legs.

Wait for this database creation to finish.

And then when you're ready, I'll look forward to you joining me in part two of this video.

Welcome to this demo lesson where you're going to migrate from the monolithic architecture on the left of your screen towards a tiered architecture on the right.

Essentially you're going to split the WordPress application architecture, you're going to move the database from being on the same server as the application to being on a different server and this will form step one of moving this architecture from being a monolith through to being a fully elastic architecture.

Now this is the first stage of many but it is a necessary one.

Now in order to perform this demonstration you're going to need some infrastructure.

Before we apply the infrastructure just make sure that you're logged in to the general AWS account, so the management account of the organization and as always you need to have the Northern Virginia region selected.

Now once you've got both of those set there's a one-click deployment link attached to this lesson so go ahead and click on that link.

What this is going to do is deploy the Animals for Life base infrastructure, it's going to deploy the monolithic WordPress application instance and it's also going to deploy a separate MariaDB database instance that you're going to use as part of the migration.

Now everything set, the stack name should be set to a suitable default, all you need to do is to scroll all the way down to the bottom, check this capabilities box and click on create stack.

Now also attached to this lesson is a lesson commands document which contains all the commands you'll be using throughout this demo.

So go ahead and open that in a new tab, you'll be referencing it constantly as you're making the adjustments to the WordPress architecture.

Now we're going to need this CloudFormation stack to be fully complete before we can continue so go ahead and pause the video and resume once the CloudFormation stack moves into a create complete state.

So now the stacks moved into a create complete state, we're good to continue.

Now this has created the base Animals for Life infrastructure which includes a number of EC2 instances so let's take a look at those, let's click on services and then locate and open EC2 in a brand new tab.

Once you're at the EC2 console if you do see any dialogues around user interface updates then just go ahead and close those down and then click on instances running.

Once you're here you'll see two EC2 instances, one will be called A4L-WordPress and this is the monolith so this is the EC2 instance which contains the WordPress application and the built-in database.

So this is the WordPress installation that we're going to migrate from and then this instance A4L-DB-WordPress this contains a standalone MariaDB installation so we're going to migrate the database for WordPress from this instance onto the DB instance and this will create a tiered application architecture rather than the monolith which we currently have.

So step number one is to perform the WordPress installation so to do that I want you to go ahead and copy the public IP version for address of the WordPress EC2 instance into your clipboard and then open it in a new tab.

Now be careful not to use the open address link that will use HTTPS which we're not currently using so copy the IP address into your clipboard and open that in a new tab.

Now when you do that you'll see a familiar WordPress installation dialog we're going to create a simple blog for site title go ahead and call it the best cats for username pick admin and then for the password instead of using the randomly selected one go ahead and use this same complex password that we've used for the CloudFormation template so this is animals for life but with number substitution.

So if you go back to your CloudFormation tab and go to the parameters tab this is the same password that we use for the DB password and the DB root password.

Now of course in production this is incredibly bad practice we're just doing it in this demo to keep things simple and avoid any mistakes.

So back to the WordPress installation screen site title the best cats username admin this for the password and then just go ahead and type a fake email so I don't want to use my real email for this I'm going to type test at test.com you can do the same and then go ahead and click on install WordPress so this is installed the WordPress application and it's using the Maria DB server that's on the same EC2 instance so part of the same monolith.

So we're going to log in we'll need to type admin and then use the animals for life strong password and click on login and once we logged in we're going to create a simple blog post so click on posts we're going to select the existing hello world post select trash this time then click on add new then we're going to add a new post we can close down this introduction dialogue and for title go ahead and type the best cats ever and then some exclamation points next click on this plus sign and we're going to add a gallery now at this point you're going to need some images to upload to this blog post I've attached an images link to this lesson so if you go ahead and click that link it will download a zip file if you extract that zip file it's going to contain four image files all four of my cats so at this point once you've downloaded and extracted that file go ahead and click on upload locate those images there should be four select them all and click on open that will add these images to this blog post and once you've added them all you can go ahead and click on publish and then publish again and this will publish this blog post so it will add data to the database that's running on the monolithic application instance as well as store these images on the local instance file system now making a point of mentioning that these images are stored on the file system because as you'll see later in the course this is one of the things that we need to migrate when we're moving to a fully elastic architecture we can't have images stored on the instances themselves we need to move that to a shared file system for now though we're focusing on the database so at this point we have the working blog the images for this blog are stored on the local file system of a4l-wordpress and the data for that blog post is stored on the MariaDB database that's also running on this EC2 instance so the next step of this demo lesson is that you're going to migrate the data from a4l-wordpress onto a4l-db-wordpress and this is an isolated MariaDB instance this is dedicated for the database so to do this migration select a4l-wordpress right click we're going to connect to this instance we'll be using EC2 instance connect so just make sure that the username is set to EC2-user and then click on connect now this is where you're going to be using the commands that are stored within the lesson commands document so you need to make sure that you have this ready to reference because it's far easier to copy and paste these commands and then adjust any placeholders rather than type them out manually because that's prone to errors the first step is to get the data from the database that's running on this monolithic application instance and store it in a file on disk so that's the first thing we need to do we need to do a backup of the database into a .sql file now to do that we use this command so it's a utility called my sql-dump it uses the -u to specify the user that we're going to be using to connect to the database then we use -p to specify that we want to provide a password and we could either provide the password on the command line or we could have it prompt us now if we supply the password with no spaces next to this -p then it will accept it as input on this command if we don't specify anything so there's a space here then it's going to ask us for the password the next thing we specify is the database name that we want to do the dump of in this case it's a4l WordPress which is the database for the animals for life WordPress instance now if we just run this command on its own it would output the dump so all of the data in the database to standard output which in this case is our screen we don't want it to do that we want it to store the results in a file called a4l WordPress dot sql and so we use this symbol which means that it's going to take the output of this component of the command and it's going to redirect it into this file so let's go ahead and run this command and it's going to prompt us for the password for this database now to get that go back to cloud for information make sure parameters are selected and it's this password that we need which is the DB password so copy that into your clipboard go back to the instance paste that in press enter and that will output all the data in the database to this file now you won't see any indication of success or failure but if you do an LS space -la and press enter one of the files that you'll see is a4l WordPress dot sql so now we have a copy of the WordPress database containing our blog post the next thing that we need to do is to take this file this backup of the database and inject it into the new database that we want to use so the dedicated Maria DB EC2 instance and to do that we're going to use this command so this command has two components the first component is this which connects to the Maria DB database instance the second component is this which takes the backup that we've just made and it feeds it into this command so this backup contains all the necessary definitions to create a new database and inject the data required this component of the command just allows us to connect to this new dedicated Maria DB instance now there are some place holders that we need to change the database name that we're going to use is the same so a4l WordPress we're still going to want to be prompted for a password so -p is what we use this time though we're going to connect using a user called a4l WordPress so we're not using the root user we're going to connect to this separate Maria DB database instance using a user a4l WordPress the only thing that we need to change is that we need to connect to a non-local host so when we used the mysql dump command we didn't specify a host to connect to and this defaulted to local host so the current machine in the case of this command we're operating with a separate server this dedicated EC2 instance which is running the Maria DB database server so a4l -db -wordpress we need to connect to this so what we'll need to connect to this is the private IP version for address of this separate database instance so select it look for private IP version for addresses and then click on the icon next to this to copy the private IP version for address of this separate database server into your clipboard then return to the application instance and we need to replace the placeholder here with that value so make sure that you're one space after the end of this placeholder and just delete this leave a space between -h and where the cursor is and then paste in that IP address so this is going to connect to this separate EC2 instance using its private IP it's going to use the a4l WordPress user it will prompt us for a password it will perform the operation on the a4l WordPress database and it's going to use the contents of this backup file to perform those tasks so go ahead and press enter and you'll be prompted for a password now again it's the same password this has all been set up as part of the cloud formation one-click deployment this lesson is about the migration process not setting up a database server so I've automated this component of the infrastructure so copy the DB password into your clipboard go back to the instance paste it in and press enter so now we've uploaded our WordPress application database into this separate MariaDB database server the next step is to configure WordPress to point at this new database server so to do that cd space forward slash var forward slash www forward slash html and press enter and then we're going to run a shudu space nano which is a text editor space wp-config.php and this is the WordPress configuration file so press enter now what we're looking for if we scroll down is we're looking for the line which says define and then a space and then DB host so this is the database host that WordPress attempts to connect to and currently it's set to local host which means it will use the database on the same EC2 instance as the application we're going to delete this local host so delete until we have two single quotes and then make sure that you still have the private IP version for address of this separate database instance in your clipboard if you don't just go ahead and copy it again from the EC2 console and then paste that in place of local host so now you should see DB underscore host and this now represents this private IP address and now the private IP address that you should use here will be different you need to use your private IP address of your a4l - DB - WordPress EC2 instance so now that you've updated this configuration file press control o and enter to save and then control x to exit out of editing this file now this now means that the WordPress instance is going to be communicating with the separate MariaDB database instance let's verify that let's go back to the tab that we have to our WordPress application and let's just go ahead and do a refresh if everything's working as expected we should see that the blog reloads successfully now this means that this blog is now pointing at this separate MariaDB database instance to be doubly sure of this though let's go back to the WordPress instance and let's shut down the MariaDB database server and we do that using this command so shudu space service space MariaDB space and then stop so type or copy and paste that command in and press enter and that's going to stop the MariaDB database service which is running on a4l WordPress so now the only MariaDB database that we have running is on the a4l - DB - WordPress EC2 instance now we can go back to the WordPress tab and hit refresh and assuming it loads in as it does in my case this now confirms that WordPress is communicating with this dedicated MariaDB EC2 instance now the reason why I wanted to step you through all these tasks in this demo lesson is the time a firm believer that in order to understand best practice architecture you need to understand bad architecture and as I mentioned in the theory lesson there is almost no justification for running your own self-managed database server on an EC2 instance in almost all situations it's preferable to use the RDS service but I need you to understand exactly how the architecture works when you're self managing a database and how to migrate from a monolithic all-in-one architecture through to having a separate self managed database in the demo lesson that's coming up next in the course you're going to migrate from this through to an RDS instance so that's step two but at this point you've done everything that I wanted you to do in this demo lesson you've implemented the architecture that's on screen now on the right all we need to do is to tidy up all of the infrastructure that we've used within this lesson so to do that it's nice and easy just go back to the cloud formation console make sure that you have the monolith to EC2 DB stack selected click on the delete button and then confirm that deletion and that stack deleting will clean up all of the infrastructure that we've used throughout this demo lesson and it will return the account into the same state as it was at the start of the lesson at this point you've completed all of the tasks that I want you to do so I hope you've enjoyed this demo lesson go ahead and complete this video and when you're ready I'll look forward to you joining me in the next.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

Now one final thing before we finish with this demo lesson, and I want to talk about private hosted zones.

So move back to the Route 53 console.

I'm going to go to Hosted Zones, and I'm going to create a private hosted zone.

So click "Create Hosted Zone" because it's a private hosted zone, it doesn't even need to be one that I actually own.

So I'm going to call my hosted zone "IlikeDogsReally.com".

It's going to be a private hosted zone.

And for now, I'm going to associate it with the default VPC in US-East-1.

So I'm going to pick the region, US-East, and then select Northern Virginia, and then click in the VPC ID box, and we should see two VPCs listed.

One is the Animals for Life VPC, it's tagged A4L-VPC1, but I'm not going to pick this one, I'm going to pick the one without any text after it, which is the default VPC.

So once that's set, I'm going to create the hosted zone.

Then inside the hosted zone, I'm going to create a record.

The record's going to use the simple routing policy.

Click on "Next".

I'm going to define a simple record.

I'm going to call it "www".

The record type is going to be "a routes traffic to an IP version 4 address and some resources".

I'm going to click in this endpoint box and select IP address or another value, depending on record type.

And then into this box, I'm just going to put a test IP address of 1.1.1.1.

And then down at the bottom, I'm going to click "1M" to change this TTL to 60 seconds.

And I'm going to click "Define simple record".

And then finally, "Create records".

So now we have a record called "www.ilikedogsrealy.com".

So copy that into the clipboard.

Move back to the EC2 console.

Click on "Dashboard".

Click on "Instances running".

Right click, "Connect".

We're going to use EC2 "Instance connect".

And then just click on "Connect".

Now once connected, I'm going to try pinging the record which I just created.

So "Ping Space" and then paste in "www.ilikedogsrealy.com" and press "Enter".

What you should see is "Name or service not found".

The reason for this is the private hosted zone which we created is currently associated with the default VPC.

And this instance is not in the default VPC.

To enable this instance to resolve records inside this private hosted zone, we need to associate it with the "Animals for Life" VPC.

So go back to the Route 53 console.

Expand "Hoster Zone Details" and then "Edit hosted zone".

Scroll down and we're going to add another VPC.

In the region drop down, "US-East-1" and then in the "Choose VPC" box select "A4L-VPC-1".

Scroll down and save changes.

Now this might take a few seconds to take effect, but if we go back to the EC2 instance and try to run this ping again, and we still get "Name or service not found".

So what I want you to do is go ahead and pause this video, wait for 4 or 5 minutes and then resume and try this command again.

Now in my case it took about 5 minutes, but after a while I can now ping www.ilikedogsreally.com because I've now associated this private hosted zone with the VPC that this instance is running from.

Now that's everything that I wanted to cover in this demo lesson, so all that remains is for us to clean up all of the infrastructure which we've created in this demo lesson.

So if we go back to the Route 53 console and select "Health Checks", first we're going to delete the health check.

So select "A4L Health" and click on "Delete Health Check" and confirm.

Click on "Hostered Zones".

Go inside the private hosted zone that you created.

Select the www.ilikedogsreally.com record and then click on "Delete Record".

Confirm that deletion.

Go back to "Hostered Zones".

Select the entire private hosted zone and click on "Delete".

Type "Delete" and then click to confirm.

And that will delete the entire private hosted zone.

Then go inside the public hosted zone that you have.

Select the two www records that you created earlier in this lesson.

Click on "Delete Records".

Click "Delete" to confirm.

Then go to the S3 console.

Click on the bucket that you created earlier in this lesson.

Click "Empty".

Copy and paste or type "Permanently Delete" and click on "Empty".

Once that bucket is emptied click on "Exit".

With it still selected click on "Delete".

Copy and paste or type the full name into the box and click on "Delete Bucket".

Then go to the EC2 console.

Click the hamburger menu.

Scroll down.

Click "Elastic IPs".

Select the elastic IP that you associated with the EC2 instance.

Click on the actions drop down.

Disassociate and then click to disassociate.

With it still selected click on "Actions".

Release elastic IP addresses and click on "Release".

At that point all of the manually created infrastructure has been removed.

Go back to the cloud formation console.

Go to "Stacks".

Select the stack that you created at the start of this lesson using the one click deployment.

It should be called DNS and failover demo.

Select it.

Click on "Delete".

Then click on "Delete Stack" to confirm that deletion.

Once that's deleted the account will be back in the same state as it was at the start of the lesson.

At this point that's everything I wanted to cover in this demo.

I hope it's been enjoyable and it's given you some good practical experience of how to use failover routing and private hosted zones.

That will be useful both for the exam and real world usage.

At this point that's everything so go ahead and complete this video.

When you're ready I'll look forward to you joining me in the next.

Welcome to this demo lesson where you're going to get experience configuring fail-over routing as well as private hosted zones.

Now with this demo lesson you have the choice of either following along in your own environment or watching me perform the steps.

If you do wish to follow along in your own environment you will need a domain name that's registered within Route 53.

Remember that was an optional step at the start of this course so if you did register a domain of your own then you can do this demo lesson.

In my case I registered animals for life 1337.org.

If you registered a domain it will be different and so wherever you see me use animals for life.org you need to replace it with your registered domain.

If you didn't register one then you'll have to watch me perform all of these steps because you can't do this lesson without your own registered domain.

In order to get started you need to make sure that you're logged in as the I am admin user of the general AWS account which is the management account of the organization and you'll need to have the Northern Virginia region selected.

Now we're going to need to create some infrastructure in order to perform this demo lesson so attached to this lesson is a one-click deployment link and you should go ahead and click that link now.

That's going to take you to a quick create stack screen.

Everything should be pre-populated the stack name is DNS and failover demo all you'll need to do is scroll down to the bottom check this capabilities box and then click on create stack.

That's going to take a few minutes and it's going to create infrastructure that we're going to need to continue with the demo lesson so go ahead and pause the video wait for your stack to move into a create complete state and then we're good to continue.

Okay so the stacks now in a create complete state and it's created a number of resources the most important one being a public EC2 instance so we just need to test this first so if you just click in the search box and type EC2 and then right click to open that in a new tab.

Once you're there click on instances running and you should see a4l-web just select that under public IP version 4 just click on this symbol to copy the IP address into your clipboard make sure you don't click open address because that's going to try and use HTTPS which we don't want so copy this IP address into your clipboard and then open that in a new tab and you should see the animals for life super minimal homepage and if you see that it means everything's working as intended so go ahead and close down that tab.

Now we also need to give this instance an elastic IP address so that it has a static public IP version 4 address now to give it an elastic IP on the menu on the left scroll down to the bottom under network and security select elastic IPs and then we need to allocate an elastic IP make sure us - east - 1 is in this box scroll down and click on allocate once the elastic IP address is allocated to this account select it click on actions and then associate elastic IP once we're at this screen make sure instance is selected click in this search box and then select a4l-web once selected click in the private IP address box and select the private IP address of this instance and then check the box to say allow this elastic IP address to be re-associated once all that's complete click on associate and that now means that our EC2 instance has been allocated with a static IP version 4 address now we're configuring failover DNS and so the EC2 instance is going to be our primary record so we're going to assume that this is the animals for life main website and we want to configure an S3 bucket which is running as the backup in case this EC2 instance fails so the next thing we need to do is to create the S3 bucket so click in the search box type S3 and open that in a new tab and then go to the S3 console and at this point we're going to create an S3 bucket and configure it as a static website now the naming of the S3 bucket is important earlier in the course you should have registered a domain name in my case I registered animals for life 1337.org so I'm going to create a bucket with the name www.animalsforlife1337.org you need to create one which is called www.and then the domain name that you registered so I'm going to click and create bucket the bucket name is www.animalsforlife1337.org and it's going to be in the US east northern Virginia region which is US-East-1 then we're going to scroll down and we're going to need to uncheck block all public access because this bucket is going to be used to host a static website I'll need to acknowledge that I'm okay with that so I'll do that and then scroll all the way down to the bottom and then I'm going to click on create bucket then I'm going to go inside the bucket click on upload and then add files now attach to this lesson is an assets file I want you to go ahead and download that file then extract it and wave extracted it it should create a folder called R53 underscore zones underscore and underscore failover go inside that folder and there'll be two more folders one which is 01 underscore A4L website and another which is 02 underscore A4L failover we're interested in the A4L failover so go into that folder select both these files so index.html and minimal.jpeg click on open and then upload those files so we'll scroll down and click on upload once that's completed click on close then we go into enable static website hosting so click on properties and to enable this it's all the way down towards the bottom click on edit next to static website hosting and enable it make sure that host a static website is selected and then for the index document and the error document we're going to type index.html and once both of those are entered scroll down to the bottom and save changes now we've one final thing to do on this bucket we need to add a bucket policy so that this bucket is public so we need to click on permissions scroll down and then under bucket policy click on edit and this bucket currently does not have a bucket policy now also inside the assets folder that you extracted earlier in this lesson there's a file called bucket underscore policy.json this is the file so you'll need to copy the contents of that file into your clipboard and then inside this policy box paste that in and then click on the icon next to the bucket ARN to copy that into your clipboard and then we need to replace this placeholder with what you've just copied so I want you to select from just to the right of the first speech mark all the way through to before the forward slash so you should have ARN colon AWS colon S3 colon colon colon colon and then example bucket and then go ahead and paste the text from your clipboard which will overwrite that with the actual bucket ARN so it should look like this once you've got that scroll down and save the changes so now we have the failover website configured the static website running from the S3 bucket so now we need to go ahead and move to the route 53 console where we going to create a health check and configure the failover record so click in the search box type route 53 right click and open that in a new tab then click on health checks we're going to create a health check for the health check name type a4l health and it's going to be an end point health check scroll down we're going to specify the endpoint by IP address the protocols going to be HTTP and we need the IP address of the EC2 instance so if we go back to the EC2 console the EC2 instance is now using the elastic IP so if we scroll down and click on elastic IPs and copy the elastic IP into our clipboard then go back to the route 53 console and paste that in and the health check is going to be configured to health check the index.html document so in path we need to click and type index.html then we're going to expand advanced configuration and by default a health check is checking every 30 seconds so this is a standard health check we need to change this to fast because we want our health check to react as fast as possible if our primary website fails so select fast scroll down to the bottom click on next we don't want to create an alarm because we don't want to take any action if this health check fails we're just going to use it as part of our fail-over routing so go ahead and make sure no is selected and then click create health check now the health check is going to start off with an unknown status because it hasn't gathered enough information about the health of the primary website it's going to take a few minutes to move from this status to either healthy or unhealthy what we can do though is if we check this we can click on the health checkers tab and start to see the results of the globally distributed set of health check endpoints so we can see that we're already getting success HTTP status code 200 and this is telling us our primary website is already passing these individual checks and after a couple of minutes if we hit refresh we should see that the status changes from unknown to healthy so next we need to create the failover record so click on hosted zones locate the hosted zone for the domain that you registered at the start of the course and click it then click on create record now you can switch between two different modes either the quick create record mode or the wizard mode we're going to keep this demo simple so click on switch to wizard we're going to choose a failover record so select failover and click next we're going to call the record www we're going to set a TTL of one minute so click 1m and that will change the TTL seconds to 60 scroll down and we're going to define some failover records so click define failover record first we need to create the primary record so click in this first drop down and we're going to pick IP address or another value depending on record type so click that and then we need the elastic IP address so go back to the EC2 console and copy the elastic IP into your clip board and paste that into this box and then for failover record type this is the primary record so click on primary we need to associate it with a health check so click in that drop down and choose a for L health now once we do that it means that this primary record will only be returned if this health check is healthy otherwise the secondary record will be returned which we're going to define in a second under record ID just go ahead and type EC2 this needs to be unique within this set of records with the same name so going to call one EC2 and the other S3 so this one's EC2 so define that failover record and then we're going to define a new failover record so click that box again this time in this drop down we need to scroll down and we're going to select alias to an S3 website endpoint so select that choose the region and it needs to be US - East - 1 once selected you should be able to click in this box and see the S3 bucket that you just created so click on this to select that S3 bucket and we're going to set this as the secondary record so click on secondary we won't be associating this with a health check and we won't be evaluating the target health this record will only ever be used if the primary fails its health check and so we want this record to take effect whenever the health check associated with the primary fails and we're going to test that by shutting down the EC2 instance so this record should then take over so finally we need to enter S3 in the record ID and click on define failover record once we've done both of those we can go ahead and click on create records so now that we have both of those records in place the primary pointing at EC2 and the secondary at S3 if we copy down this full DNS name into our clipboard and open that in a new tab that should direct towards the animals for life.org super minimal homepage remember this is the website running on EC2 now what we need to do is to simulate a failure so go back to the EC2 console scroll to the top click on EC2 dashboard then instances running right click on this instance select stop instance and confirm that by clicking stop so now we've stopped this instance it should begin failing the health check so let's go back to the route 53 console click on health checks select this a4 health health check click on the health checkers tab and then click on refresh and over the coming seconds we should start to see some failure responses in this status column there we go we're getting connection timed out and over the next minute or so we should see that the status of the health check overall should move from healthy to unhealthy let's click on refresh it might take a minute or so for that to take effect so let's just give it a minute or so and now we can see that it's moved into an unhealthy state now this means that our failover record will detect this and then it's going to start returning the secondary record rather than the primary now DNS does have a cache remember we set the TTL value to 60 seconds so one minute but what we should find after that cache expires if we go back to this tab which we have open to the www.animalsforlife.org website and if we now hit refresh we should see that it changes to the animals for life.org super minimal failover page and this is the website that's running on s3 so the failover record has used a health check detected the failure of the EC2 instance and redirected us towards the backup s3 site so now we can go ahead and reverse that process if we go back to the EC2 console we can right click on this instance and start the instance that will take a few minutes to move from the stopped state through the pending state and then finally to running and once it's in a running state if we go back to the route 53 console and select this health check and then refresh on the health checkers initially we'll see a number of different messages if we keep hitting refresh over the next few minutes we should see this change to an okay message there we can see the first HTTP status code 200 if we keep refreshing we'll see more of those again more 200 statuses which means okay now that all of these are coming back okay let's click refresh on the health check itself it's still showing us unhealthy let's give it a few more seconds now it's reporting as healthy again if we go back to the tab that we have open to the website and click on refresh now it should change back to the original EC2 based website and it does so that means our failover record has worked in both directions it's failed over to s3 and failed back to EC2 okay so this is the end of part one of this lesson it was getting a little bit on the long side and so I wanted to add a break it's an opportunity just to take a rest or grab a coffee part 2 will be continuing immediately from the end of part one so go ahead complete the video and when you're ready join me in part 2.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

So let's go back to the instance now.

Just press enter a few times to make sure it hasn't timed out.

That's good.

Now there's a small bug fix that we need to do before we move on.

The CloudWatch agent expects a piece of system software to be installed called CollectD.

And on Amazon Linux that is not installed.

So we need to do two things.

The first is to create a directory that the agent expects to exist.

So run that command.

And the second is to create a database file that the agent also expects to exist.

And we can do that by running this command.

Now at this point we're ready to move on to the final step.

So we've installed the agent and we've run the configuration wizard to generate the agent configuration.

And we're now safely stored inside the parameter store.

The final step is to start up the CloudWatch agent and provide it with the configuration that's stored inside the parameter store.

And by doing that the agent can access the configuration.

It can download it.

It can configure itself as per that configuration.

And then because we've got an attached instance role that has the permissions required, it can also inject all of the logging data for the web server and the system into CloudWatch logs.

So the final step is to run this command.

So this essentially runs the Amazon hyphen CloudWatch hyphen agent hyphen CTL.

And it specifies a command line option to fetch the configuration.

And it uses hyphen C and specifies SSM colon and then the parameter store parameter name.

Essentially what this command does is to start up the agent, pull the config from the parameter store, make sure the agent is running and then it will start capturing that logging data and start injecting it into CloudWatch logs.

So at this point if it's functioning correctly, what you should be able to do is go back to the AWS console, go to services, type CloudWatch and then select CloudWatch to move to the CloudWatch console.

Then if we go to log groups, now you might see a lot of log groups here.

That's fine.

Every time you apply the animals for life VPC templates, it's actually using a Lambda function which we haven't covered yet to apply an IP version six workaround, which I'll explain later in the course when we cover Lambda.

What you should find though is if you just scroll down all the way to the bottom, you should see either one, two or three of the log groups that we've created.

In this example on screen now, you can see that I have /var/log/httbd/error_log.

Now these logs will start to appear when they start getting new entries and those entries are sent into CloudWatch.

So right now you can see that I only have the error log.

Now if you don't see access underscore log, what you can do is go back to the EC2 consoles, select the WordPress instance that you've created using the one click deployment and then copy the public IP version four address into your clipboard.

Don't use this link, just copy the IP address and then open that in a new tab.

Now by doing that, it will generate some activity within the Apache web server and that will put some log items into the access log and that will mean that that logging information will then be injected into CloudWatch logs using the CloudWatch agent.

So if we move back to CloudWatch logs and then refresh, scroll down to the bottom.

Now we can see the access underscore log file.

Open the log stream for the EC2 instance.

This log file details any accesses to the web server on the EC2 instance.

You won't have a lot of entries in this.

Likewise, if you go back to log groups and look for the error log, that will detail any errors, any accesses which weren't successfully served.

So if you try to access a web page which doesn't exist, if there's a server error or any module errors, these will show inside this log group.

Now also, because we're using the CloudWatch agent, we also have access to some metrics inside the EC2 instance that we otherwise would not have had.

If we click on metrics and just drag this up slightly so we can see it, you'll see the AWS namespaces.

So these are namespaces with metrics inside that you would have had access to before, but there'll also be the CWAgent namespace and inside here, just maybe select the image ID, instance ID, instance type name.

Inside there, you'll see all of the metrics that you now have access to because you have the CloudWatch agent installed on this EC2 instance.

So these are detailed operating system level metrics such as disk, IO, read and write, and you would have not had access to these before installing the agent.

If we select another one, image ID, instance ID, instance type CPU, we'll be able to see the CPU cores that are on this instance together with the IO weight and the user values.

Again, these are things that you would not have had access to at this level of detail without the CloudWatch agent being installed.

Now I do encourage you to explore all of the different metrics that you now have access to as well as to how the log groups and log streams look with this agent installed.

But this is the end of what I had planned for this demo lesson.

So as always, we want to clear up all of the infrastructure that we've created within this demo lesson.

So to do that, I want you to move back to the EC2 console, right click on this instance, go down to security, select modify IAM role, and then remove the CloudWatch role from this instance.

You'll need to confirm that by following the instructions.

So to detach that role, then click on services and move back to IAM, click on roles.

And I want you to remove the CloudWatch role that you created earlier in this demo.

So select it and then click delete role.

You'll need to confirm that deletion.

What we're not going to do is delete the parameter value that we've created.

So if we go to services and then move back to systems manager, go to parameter store, because this is a standard parameter.

This won't incur any charges.

And we're going to be using this later on in future lessons of this course and other courses.

So this is a standard configuration for the CloudWatch agent, which we'll be using elsewhere in the course.

So we're going to leave this in place.

The last piece of cleanup that you'll need to do is to go back to the CloudFormation console.

You should have the single CW agent stack in place that you created at the start of the demo using the one click deployment.

Go ahead and select the stack, click on delete, and then confirm that deletion.

And once that's completed, all of the infrastructure you've used in this demo will be removed and the account will be back in the same state as it was at the start of this demo.

Now that's everything that I wanted you to do in this demo.

I just wanted to give you a brief overview of how to manually install the CloudWatch agent within an EC2 instance.

Now there are other ways to perform this installation.

You can use systems manager or bake it into AMIs or you can bootstrap it in using the process that you've seen earlier in the course.

We're going to be using the CloudWatch agent during future demos of the course to get access to this rich metric and logging information.

So most of the demos which follow in the course will include the CloudWatch agent configuration.

At this point though, that is everything I wanted you to do in this demo.

Go ahead, complete this video, and when you're ready, I'll look forward to you joining me in the next. in the next.

Welcome back and welcome to this demo where together we'll be installing the CloudWatch agent to capture and inject logging data for three different log files into CloudWatch logs as well as giving us access to some metrics inside the OS that we wouldn't have otherwise had visibility of.

So it's going to be a really good demonstration to show you the power of CloudWatch and CloudWatch logs when combined with the CloudWatch agent.

Now in order to do this demo you're going to need to deploy some infrastructure.

To do so just make sure that you're logged in to the general AWS account, so the management account of the organization and as always make sure you've got the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment URL which will deploy the infrastructure that you'll be using during this demo.

So go ahead and click on that link.

This will take you to a quick create stack screen.

The stack name should be pre-populated with CW agent.

You just need to scroll all the way down to the bottom, acknowledge the capabilities and click on create stack.

Also attached to this lesson is a lesson commands document which will contain all of the commands you'll be using during this demo lesson.

So go ahead and open that in a new tab.

Now you're going to need to let this cloud formation stack move into a create complete state before you continue the demo.

So go ahead and pause the video, wait for the status to change to create complete and then you're good to continue.

Okay so now this stack is in a create complete state then we good to continue the demo.

Now during this demo lesson you're going to be installing the cloud watch agent on an EC2 instance and this EC2 instance has been provisioned by this one-click deployment.

So the first thing that we need to do is to move across to the EC2 console and connect to this instance.

Once you're at the EC2 console click on instances running.

You should see one single EC2 instance called A4L WordPress.

Just go ahead and select this, right-click on it, select connect.

We're going to connect into this instance using EC2 instance connect so make sure that's selected.

Make sure also that the username is set to EC2-user and then connect into the instance.

Now if everything's working as it should be you should see the animals for life custom login banner when you log into the instance.

In my case I do see that and that means everything's working as expected.

So this demonstration is going to have a number of steps.

First we need to download the cloud watch agent then we need to install the agent then we need to generate the configuration file that this install of the agent as well as any future installs of the agent could use and then we need to get the cloud watch agent to read this config and start capturing and injecting those logs into cloud watch logs.

So step one is to download and install the agent and the command to do this is inside the lesson commands document which is attached to this lesson and that will install the agent but crucially it won't start it.

What we need to do before we can start the agent is to generate the config file that we'll use to configure this and any future agents but because we also want to store that config file inside the parameter store and because we also want to give this instance permissions to interact with cloud watch logs before we continue we need to attach an IAM role to this instance an EC2 instance role so that's the next step.

So we need to move back to the EC2 console click on services and then open the IAM console because we'll be creating an IAM role to attach to this instance you'll need to go to roles create role it'll be an AWS service role using EC2 so select EC2 and then click on next we'll need to attach two managed policies to this role so I've included the names of those managed policies in the lesson commands document the first is cloud watch agent server policy so make sure you type that in the filters policy and then check that box and the second is Amazon SSM full access so type that in the box select that policy and then scroll down and click on next and we'll call this role cloud watch role so enter cloud watch role and click on create role and once we've done that we can attach this role to our EC2 instance so we need to move back to the EC2 console go to instances right click on the instance go to security and then modify IAM role and then click on the drop down and select cloud watch role which is the role that you've just created then click update IAM role now that we've allocated that instance with the permissions that it needs to perform the next set of steps go ahead and connect to that instance again the tab may have timed out that you previously had open so if it doesn't respond you need to close it down and reopen it if it does respond that's fine keep the existing tab once we back in the terminal for the instance we need to start the cloud watch agent configuration wizard and the command to do that is also in the lesson commands document attached to this lesson so go ahead and paste that in and press enter and that will start off the configuration wizard for the cloud watch agent now for most of these values we can accept the defaults but we need to be careful because there are a number of them that we can't so press enter and accept the default for the operating system it should automatically detect Linux press enter it should automatically detect that it's running on an EC2 instance press enter to use the root user again that should be the default press enter for stats D press enter for the stats D port press enter for the interval press enter for the aggregation interval press enter to monitor metrics from collect D again that's the default press enter to monitor host metrics so CPU and memory press enter to monitor CPU metrics per core press enter for the additional dimensions press enter to aggregate EC2 dimensions press enter for the default resolution so 60 seconds for the default metric config that you want the default will be basic go ahead and enter 3 for advanced this captures additional operating system metrics that we might actually want so use 3 for this value press enter to indicate that we satisfied with the above config next we'll move to the log configuration part of this wizard so press enter for the default of no we don't have an existing cloud watch log agent config to import press enter which is the default for yes we do want to monitor log files you'll be asked for the log file path to monitor so the first one that we want to monitor and again these are in the lesson commands document so the first log path is forward slash var forward slash log forward slash secure press enter you'll be asked for the log group name the default is just the log name itself so secure but we're going to enter the full path I always prefer using the full path for the log group names for any system logs so going to enter var log secure again you'll be asked for the log stream name remembering the theory part of this lesson I talked about how a log stream will be named after the instance which is injecting those logs so the default choice is to do that to use the instance ID so press enter it's here where you can specify a log group retention in days we're just going to accept the default for the log group retention value the default will be yes we do want to specify additional log files so press enter the log file path for this one will be var log HTTP d access underscore log so enter that the log group name again will default to the name of the actual log we want the full path so enter the full path again press enter the log stream name the default for this is again the instance ID which is fine just press enter go ahead and accept the default for the log group retention in days press enter again we've got one more log file that we want to enter this time the log file path is var log HTTP d error underscore log again the log group name will default the name of the actual log we want to use the full path so enter the same thing again the default choice for log stream name will be again the instance ID that's fine press enter go ahead and accept the default for the log group retention in days and now we finished adding log files we won't want to log any additional files so press 2 and that will complete this logging section of this wizard it's asking us to confirm that we're happy with this configuration file and it's telling us that the configuration file is stored at forward slash opt forward slash aws forward slash amazon hyphen cloud watch hyphen agent forward slash bin and then config dot json in that folder now that's where it stores it on the local file system but we can also elect to store this json configuration inside the parameter store and I thought that since we've previously talked about the theory of the parameter store and done a little bit of interaction it would be useful for you to see exactly how it can be used in a more production like setting so the default is to store the configuration in the parameter store so we're going to allow that press enter it'll ask us for the parameter name to use and the default is Amazon cloud watch hyphen linux and that's fine so press enter it'll ask us for the region to use because parameter store is like many other services a regional service and the default region is the one where the instance is in so it automatically detects that we're in us east one which is northern Virginia so go ahead and accept that default choice it'll ask us for the credentials that it can use to send that configuration into the parameter store now these credentials will be obtained from the role that we've attached to this instance in the previous step so you can accept the default choice it'll use those credentials to store that configuration inside the parameter store and if we move back to the ec2 console and we switch back to the parameter store so just type SSM to move to systems manager which is the parent product of parameter store if we go down to the parameter store item on the menu on the left we'll be able to see this single parameter Amazon cloud watch hyphen linux and if we open that up and just scroll down we can see that the value is a JSON document with the full configuration of the cloud watch agent so we can now use this parameter to configure the agent on this ec2 instance as well as any other ec2 instances we want to deploy so if you create the cloud watch configuration once and then store it into parameter store then when you create ec2 instances at scale as you'll see how to do later in the course when we talk about auto scaling groups then you can use the parameter store to deploy this type of configuration at scale in a secure way okay so this is the end of part one of this lesson it was getting a little bit on the long side and so I wanted to add a break it's an opportunity just to take a rest or grab a coffee part 2 will be continuing immediately from the end of part one so go ahead complete the video and when you're ready join me in part 2.

Welcome back and in this demo lesson, I'm just wanting to give you some practical experience with interacting with the parameter store inside AWS.

So to do that, make sure you're logged into the IAM admin user of the management account of the organization and you'll need to have the Northern Virginia region selected.

Now there's also a lesson commands document linked to this lesson, which contain all of the commands that you'll need for this lessons demonstration.

So before we start interacting with the parameter store from the command line, we need to create some parameters.

And the way that we do that is first move to systems manager.

So the parameter store is actually a sub product of systems manager.

So move over to the systems manager console.

And once you're there, you'll need to select the parameter store from the menu on the left.

So it should be about halfway down on the left and it's under application management.

So go ahead and select parameter store.

Now once you're in parameter store, the first thing that you'll need to do to remove this default welcome screen logically is to create a parameter.

So go ahead and click on create parameter.

Now when you create a parameter, you're able to pick between standard or advanced.

Standard is the default and that meets most of the needs that most people have for the product.

And you can create up to 10,000 parameters using the standard tier.

With the advanced tier, you can create more than 10,000 parameters.

The parameter value can be longer at eight kilobytes versus the four kilobytes of standard.

And you do gain access to some additional features.

But in most cases, most parameters are fine using the default, which is the standard tier.

With the standard tier, there's no additional charge to use this up to the limit of 10,000 parameters.

The only point at which parameter store costs any extra is if you use the faster throughput options or make use of this advanced tier.

And we won't be doing that at any point throughout the course.

We'll only be using standard.

And so there won't be any extra parameter store related charges on your bill.

Now I mentioned that a parameter is essentially a parameter name and a parameter value.

And it's here where you set both of those.

There's an optional description that you can use and you can set the type of the parameter.

The options being string, string list, which is a comma separated list of individual strings and then secure string, which utilizes encryption.

So we're gonna go ahead at this point and create some parameters that we're then going to interact with from the command line.

So the first one we'll create is one that's called forward slash my-cat-app forward slash DB string.

So this is the name of a parameter and it will also establish a hierarchy.

So anytime we use forward slashers, we're establishing a hierarchy inside the parameter store.

So imagine this being a directory structure.

Imagine this being the root of the structure.

Imagine my-cat-app being the top level folder and inside there, imagine that we've got a file called DB string.

So we're going to store this, we're going to store this hierarchy and we need to set its value.

So we'll keep this for now as a string and this is going to be the database connection string for my-cat-app.

So we'll just enter the value that's in the lesson commands document.

So DB dot all the cats dot com colon 3306.

And 3306 of course is the my SQL standard port number.

At this point, we could enter an optional description.

So let's go ahead and do that.

Connection string for cat application.

So just type in a description here.

It doesn't matter really what you type and then scroll down and hit create parameter.

So that's created our first parameter, my-cat-app forward slash DB string.

Now we're going to go ahead and do the same thing but for DB user.

So click on create parameter and then just click in this name box and notice how it presents you with this hierarchy.

So now we've got two levels of this hierarchical structure.

We've got the my-cat-app at the top and then we've got the actual parameter that we created at the bottom here.

So this has already established this structure.

So let's go ahead and create a new parameter.

This time it's going to be forward slash my-cat-app forward slash DB user.

We'll not bother with the description for this one.

We'll keep it at the default of standard and it will also be a string.

And then for the value, it'll be boss cat.

So enter all that and click on create parameter.

Next let's create a parameter again.

If we click in this name this time, we've got this hierarchy that's ever expanding.

So we've got the top level at the top and then below it two additional parameters, DB string and DB user.

And we're going to create a third one at this level.

So this time it's going to be called forward slash my-cat-app forward slash DB password.

This time though, instead of type string, it's going to be a secure string so that it encrypts this parameter.

And it's going to use KMS to encrypt the parameter.

And because it's using KMS, we'll need to select the key to use to perform the cryptographic operations.

We can either select a key from the current account, so the account that we're in, or we can select another AWS account.

And in either case, we'll need to pick the key ID to use and by default, it uses the product default key for SSM.

So that's using alias forward slash AWS forward slash SSM.

And you always have the option of clicking on this dropdown and changing it if you want to benefit from the extra functionality that you get by using a customer managed KMS key.

This is an AWS managed one.

So you won't be able to configure rotation and you won't be able to set these advanced key policies.

But in most cases, you can use this default key.

So at this point, we'll leave it as the default and we'll enter our super secret password, amazing secret password, 1337, and then click create parameter.

We're not finished yet though, click on create parameter again.

And I like to be inclusive, so not everything in my course is going to be about cats.

We're going to create another parameter, my-dog-app forward slash DB string.

We'll keep standard, we'll keep the type as string and then the value for connecting to the my-dog application.

So the DB string is going to be DB if we really must have dogs.com colon 3306.

So type that in and then click on create parameter.

And then lastly, we're going to create one more parameter.

This time the name is going to be forward slash rate my lizard.

So rate hyphen my hyphen lizard forward slash DB string.

The tier is going to be standard again.

The type is going to be string.

And for the value, it will be DB.

This is pretty random.com colon 3306.

So type that in and then click on create parameter.

So now we've created a total of five parameters.

We've created the DB string, the DB user, and the DB password for the cat application.

And then the DB string for the dog application as well as the rate my lizard application.

So a total of five parameters and one of them is using encryption.

So that's the DB password for the my cat application.

So now let's switch over to the command line and interact with these parameters.

And to keep things simple, we're going to use the cloud shell.

So this is a relatively new feature made available by AWS.

And this means that we don't have to interact with AWS using our local machine.

We can do it directly from the AWS console.

So click on the cloud shell icon on the menu on the top.

This will take a few moments to provision because this is creating a dedicated environment for you to interact with AWS using the command line interface.

So you'll need to wait for this process to complete.

So go ahead and pause the video and wait until this logs you into the cloud shell environment at which point you can resume the video and we're good to continue.

It'll say preparing your terminal and then you'll see a familiar looking shell much like you would if you were connected to a Linux instance.

And now you'll be able to interact with AWS using the command line interface, using the credentials that you're currently logged in with.

Now to interact with parameter store using the command line, we start by using AWS and then a space, SSM, and then a space, and then the command that we're going to use is get-parameters.

Now by default, what we need to provide the get-parameters command with is the path to a parameter.

So in this case, if we wanted to retrieve the database connection string for the rate my lizard application, then we could provide it with this name.

So forward slash rate-my-lizard/dvstring.

And this directly maps back through to the parameter that we've just created inside the parameter store.

So this parameter.

So if you go ahead and type that and press enter, it's going to return a JSON object.

Inside that JSON object is going to be a list of parameters and then for each parameter, so everything inside these inner curly braces, we're going to see the name of the parameter that we wanted to retrieve, the type of the parameter, the value of the parameter.

In this case, db.this_is_pretty_random.com/3306, the version number of the parameter because we can have different version numbers, the last modified date, the data type, and then the unique arn of this specific parameter.

And so this is an effective way that you can store and retrieve configuration information from AWS.

Now we can also use the same structure of command to retrieve all of those other parameters that we stored within the parameter store.

So if we wanted to get the db string for the my-dog-app, then we could use this command.

And again, it would return the same data structure.

So a JSON object containing a list of parameters and each of those parameters would contain all of this information.

I'll clear the screen to keep this easy to see.

We could do the same for the my-cat-app, retrieving its database connection string.

And again, it would return the same JSON object with the parameters list.

And then for each parameter, this familiar data structure.

Now what you can also do, and I'm going to clear the screen before I run this, is instead of providing a specific path to a parameter.

So if you remember, we had almost a hierarchy that we created with these different names.

So we have the my-cat-app hierarchy and then inside there db-pastword, db-string, db-user.

We have my-dog-app and inside there db-string and then rate-my-lizard and also db-string.

So rather than having to retrieve each of these individual parameters by specifying the exact name, we can actually use get parameters by path.

So let's demonstrate exactly how that works.

So with this command, we're doing a get-parameters-by-path and we're specifying a path to a group of a number of parameters.

So in this case, my-cat-app is actually going to be the first part of the path of db-pastword, db-string and db-user.

So by creating a hierarchical structure inside the parameter store, we can retrieve multiple parameters at once.

So this time we're returning a JSON structure.

Inside this JSON structure, we have a list of parameters and then we're retrieving three different parameters, db-pastword, db-string and db-user.

Now note how db-pastword is actually a type of secure string and by default, if we don't specify anything, we return the encrypted version of this parameter.

So the ciphertext version of this parameter.

This ensures that we can interact with parameters without actually decrypting them and this offers several security advantages.

Now I've cleared the screen to make this next part easy to see because it's very important.

Because we're using KMS to encrypt parameters, the permissions to access KMS keys to perform this decryption, this is separate than the permissions to access the parameter store.

So if this user, I am admin in this case, has the necessary permissions to interact with KMS to use the keys to decrypt these parameters, then we can also ask the parameter store to perform that decryption whilst we retrieve the parameters.

The important thing to understand is the permissions to interact with the parameter store are separate than the permissions to interact with KMS.

So to perform a decryption whilst we're retrieving the parameters, we would use this command.

So it's the same command as before, aws, SSM, get-parameters-by-path, and then we're specifying the my-cat-app part of the hierarchy.

So remember, this represents these three parameters.

Now, if we ran just this part on its own, which was the command we previously ran, this would retrieve the parameters without performing decryption.

But by adding this last part, this is the part that performs the decryption on any parameter types which are encrypted.

And if you recall, one of the parameters that we created was this DB password, which is encrypted.

So if we run this command, this time it's going to retrieve the /my-cat-app/db password parameter, but it's going to decrypt it as part of that retrieval operation and return the plain text version of this parameter.

And just to reiterate, that requires both the permissions to interact with the parameter store, as well as the permissions to interact with the KMS key that we chose when creating this parameter.

Now, we're logged in as the IAM admin user, which has admin permissions, and so we do have permissions on both of those, on SSM and on KMS, so we can perform this decryption operation.

Now, you're going to be using the parameter store extensively for the rest of the course and my other courses.

It's a great way of providing configuration information to applications, both AWS and bespoke applications within the AWS platform.

It's a much better way to inject configuration information when you're automatically building applications or you need applications to retrieve their own configuration information.

It's much better to retrieve it from the parameter store than to pass it in using other methods.

So we're going to use it in various different lessons as we move throughout the course.

In this demo lesson, I just wanted to give you a brief experience of working with the product and the different types of parameters.

But at this point, let's go ahead and clear up all of the things that we've created inside this demo lesson.

So close down this tab, open to Cloud Shell.

Back at the parameter store console, just go ahead and check the box at the top to select all of these existing parameters.

If you do have any other parameters, apart from the ones that you've created within this demo lesson, then do make sure that you uncheck them.

You should be using an account dedicated for this training, so you shouldn't have any others at this point.

But if you do, make sure you uncheck them.

You should only be deleting ones for 8-mile lizard, my dog app, and my cat app.

So make sure that all of those are selected and then click on delete to delete those parameters, and you'll need to confirm that deletion process.

And at this point, that's everything that I wanted you to do in this lesson.

You've cleared up the account back to the point it was at the start of this demo lesson.

So go ahead, complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome to this demo lesson where you're going to get the experience of working with EC2 and EC2 instance roles.

Now as you learned in the previous theory lesson, an instance role is essentially a specific type of IAM role designed so that it can be assumed by an EC2 instance.

When an instance assumes a role which happens automatically when the two of them are linked, that instance and any applications running on that instance can gain access to the temporary security credentials that that role provides.

And in this demo lesson you're going to get the experience of working through that process.

Now to get started you're going to need some infrastructure.

Make sure that you're logged in to the general AWS account, so that's the management account of the organization and as always you'll need to be within the Northern Virginia region.

Assuming you are, there's a one click deployment link which is attached to this lesson so go ahead and click that link.

That will take you to a quick create stack page.

The stack name will be pre-populated with IAM role demo and all you need to do is to scroll down to the bottom, check this capabilities box and then click on create stack.

This one click deployment will create the animals for live VPC and EC2 instance and an S3 bucket.

Now in order to continue with this demo we're going to need this stack to be in a create complete state.

So go ahead and pause the video and then when the stack moves into a create complete status then we're good to continue.

Okay so this stacks now in a create complete state and we're good to continue.

So to do so go ahead and click on the services drop down and then type EC2, locate it, right click and then open that in a new tab.

Once you're at the EC2 console click on instances running and you should be able to see that we only have the one single EC2 instance.

Now we're going to connect to this to perform all the tasks as part of this demo.

So right click on this instance, select connect, we're going to use EC2 instance connect.

Just verify that the username does say EC2-user and then click on connect.

Now the AMI that we use to launch this instance is just the standard Amazon Linux 2 AMI.

And so if we type AWS and press enter it comes with the standard install of the AWS CLI version 2.

Now it's important to understand that right now this instance has no attached instance role and it's not been configured in any way.

It's the native Amazon Linux 2 AMI that's been used to launch this instance.

And so if we attempt to interact with AWS using the command line utilities, for example by running an AWS S3 LS, the CLI tools will tell us that there are no credentials configured on this instance and will be prompted to provide long term credentials using AWS Configure.

Now this is the method that you've used to provide credentials to your own installed copy of the CLI tools running on your local machine.

So you've used AWS Configure and set up two named configuration profiles.

And the way that you provide these with authentication information is using access keys.

Now this instance has no access keys configured on it and so it has no method of interacting with AWS.

We could use AWS Configure and provide these credentials but that's not best practice for an EC2 instance.

What we're going to do instead is use an instance role.

So to do that you're going to need to move back to the AWS console.

And once you're there click on services and in the search box type IAM.

We're going to move to the IAM console so right click and open that in a new tab.

As I mentioned earlier an instance role is just a specific type of IAM role.

So we're going to go ahead and create an IAM role which our instance can assume.

So click on roles and then we're going to go ahead and click on create role.

Now the create role process presents us with a few common scenarios.

We can create a role that's used by an AWS service, another AWS account, a web identity or a role designed for SAML 2.0 Federation.

In our case we want a role which can be assumed by an AWS service specifically EC2.

So we'll select the type of trusted entity to be an AWS service then we'll click on EC2 and then we'll click on next.

Now for the permissions in this search box just go ahead and type S3 and we're looking for the Amazon S3 read only access.

So there's a managed policy that we're going to associate with this role.

So check the box next to Amazon S3 read only access and then we'll click on next.

And then under role name we're going to call this role A4L instance role.

So it's easy to distinguish from any other roles we have in the account.

So go ahead and enter that and click on create role.

Now as I mentioned in the theory lesson about instance roles when we do this from the user interface.

It's actually created a role and an instance profile of the same name and it's the instance profile that we're going to be attaching to the EC2 instance.

Now from a UI perspective both of these are the same thing.

You're not exposed to the role and the instance profile as separate entities but they do exist.

So now we're going to move back to the EC2 console and remember currently this instance has no attached instance role and we're unable to interact with AWS using this EC2 instance.

To attach an instance role using the console UI right click, go down to security and then modify IAM role.

Select that and we'll need to choose a new IAM role.

You have the option of creating one directly from this screen but we've already created the one that we want to apply.

So click in the drop down and select the role that you've just created.

In this case A4L instance role.

So select that and then click on save.

Now if we select the instance and then click on security you'll be able to confirm that it does have an IAM role attached to this instance.

So this is the instance role that this EC2 instance can now utilize.

So now we're going to interact with this instance again from the operating system.

Now if it's been a few minutes since you've last used instance connect you might find when you go back it appears to have frozen up.

If that's the case that's no problem just close down these tabs that you've got connected to that instance.

Right click on the instance again, select connect, make sure the username is EC2-user and then click on connect.

And this will reconnect you to that instance.

Now if you recall last time we were connected we attempted to run AWS S3LS and the command line tools informed us that we had no credentials configured.

Let's attempt that process again.

AWS space S3 space LS and press enter.

And now because we have the instance role associated with this EC2 instance the command line tools can use the temporary credentials that that role generates.

Now the way that this works and I'm going to demonstrate this using the curl utility these credentials are actually provided to the command line tools via the metadata.

So this is actually the metadata path that the command line tools use in order to get the security credentials.

So the temporary credentials that a role provides when it's assumed.

So if I use this command and press enter you'll see that it's actually using this role name.

So you'll see a list of any roles which are associated with this instance.

If we use the curl command again but this time on the end of security credentials we specify the name of the role that's attached to this instance and press enter.

Now we can see the credentials that command line tools are using.

So we have the access key ID the secret access key and the token and all of these have been generated by this EC2 instance assuming this role because these are temporary credentials.

They also have an expiry date.

So in my case here we can see that these credentials expire on the 7th of May 2022 at 552 47 UTC.

And that really is all I wanted to show you in this demo lesson about instance roles.

Essentially you just need to create an instance role and then attach it to an instance.

And once you do that instance is capable of assuming that role gaining access to temporary credentials and then any applications installed on that instance, including the command line utilities are capable of interacting with AWS using those credentials.

Now the process of renewing these credentials is automatic.

So as long as the application that's running on the instance periodically checks the metadata service, it will always have access to up to date and valid credentials.

The EC2 service once this expiry date closes in and once the expiry date is in the past, these credentials will be renewed and a new valid set of credentials will automatically be presented via the metadata service to any applications running on this EC2 instance.

Now just one more thing that I do want to show you before we finish up with this demo lesson.

And I have made sure that I've attached this link to the lesson.

This link shows the configuration settings and precedence that the command line utilities use in order to interact with AWS.

So whenever you use the command line interface, each of these is checked in order.

First, it looks at command line options.

Then it looks at environment variables to check whether any credentials are stored within environment variables.

Then it checks the command line interface credentials file.

So this is stored within the dot AWS folder within your home folder and then a file called credentials.

Next, it checks the CLI configuration file.

Next, it checks container credentials.

And then finally, it checks instance profile credentials.

And these are what we've just demonstrated.

Now, this does mean that if you manually configure any long term credentials for the CLI tools as part of using AWS Configure, then they will be used as a priority over an instance profile.

But you can use an instance profile and attach this to many different instances as a best practice way of providing them with access into AWS products and services.

So that's really critical to understand.

But at this point, that is everything that I wanted to cover in this demo lesson.

And all that remains is for us to tidy up the infrastructure that we've used as part of this demo.

So to tidy up this infrastructure, I want you to go back to the IAM console.

I want you to click on roles and I want you to delete the A4L instance role that you've just created.

So select it and then click on delete role.

Once you've deleted that role, go back to the EC2 console, click on instances, right click on public EC2, go to security, modify IAM role.

Now, even though you've deleted the IAM role, note how it's still listed.

That's because this is an instance profile.

This is showing the instance profile that gets created with the role, not the role itself.

So what we're going to do, and I just wanted to do this to demonstrate how this works, we're just going to select no IAM role and then click on save.

We'll need to confirm that.

So to do that, we need to type detach into this box and then confirm it by clicking detach.

That removes the instance role entirely from the instance.

And then we can finish up the tidy process by moving back to the cloud formation console.

Selecting the IAM role demo stack and then clicking on delete and confirming that deletion.

And that will put the account back in the same state as it was at the start of this demo lesson.

So this has been a very brief demo.

I just wanted to give you a little bit of experience of working with instance roles.

So that's EC2 instances combined with IAM roles in order to give an instance and any applications running on that instance, the ability to interact with AWS products and services.

And this is something that you're going to be using fairly often throughout the course, specifically when you're configuring any AWS services to interact with any other services on your behalf.

That's a common use case for using IAM roles and we'll be using instance roles extensively to allow our EC2 instances to interact with other AWS products and services.

But at this point, that is everything that I wanted to cover in this demo lesson.

So go ahead, complete the video and when you're ready, I'll look forward to you joining me in the next.

Welcome back and I've mentioned a few times now within the course that I am roles are the best practice way that AWS services can be granted permissions to other AWS services on your behalf.

Allowing a service to assume a role grants the service the permissions that that role has.

EC2 instance roles are roles that an instance can assume and anything running in that instance has the permissions that that role grants and there is some detail involved which matters so let's take a look at how this feature of EC2 works architecturally.

Instance role architecture isn't really all that complicated it starts off with an I am role and that role has a permissions policy attached to it so whoever assumes the role gets temporary credentials generated and those temporary credentials give the permissions that that permissions policy would grant.

Now an EC2 instance role allows the EC2 service to assume that role which means there's an EC2 instance itself can assume it and gain access to those credentials but we need some way of delivering those credentials into the EC2 instance so that applications running inside that instance can use the permissions that the role provides so there's an intermediate piece of architecture the instance profile and this is a wrapper around an I am role and the instance profile is the thing that allows the permissions to get inside the instance when you create an instance role in the console an instance profile is created with the same name but if you use the command line or cloud formation you need to create these two things separately when using the UI and you think you're attaching an instance role direct to an instance you're not you're attaching an instance profile of the same name it's the instance profile that's attached to an EC2 instance.

We know by now that when I am roles are assumed you're provided with temporary security credentials which expire but these credentials grant permissions based on the roles permissions policy will inside an EC2 instance these credentials are delivered via the instance metadata.

An application running inside the instance can access these credentials and use them to access AWS resources such as S3.

One of the great things about this architecture is that the credentials available inside the metadata they're always valid EC2 and the secure token service liaise with each other to ensure that the credentials are always renewed before they expire as long as your application inside the EC2 instance keeps checking the metadata it will never be in a position where it has expired credentials.

So to summarize when you use EC2 instance roles the credentials are delivered via the instance metadata specifically inside the metadata there's an IAM tree in there there's a security credentials part and then in there is the role name and if you access this you'll get access to these temporary security credentials and they're always rotated they're always valid as long as that instance role remains attached to the instance anything running in the instance will always have access to these valid credentials applications running in the instance of course need to be careful about caching these credentials and just check the metadata before the credentials expire or do it periodically.

You should always use roles where possible I'm going to keep stressing that throughout the course it's important for the exam roles are always preferable than storing long-term credentials so access keys into an EC2 instance it's never a good idea to store long-term credentials such as access keys anywhere which aren't securely stored so for example on your local machine.

In fact the AWS tooling such as the CLI tools will use instance role credentials automatically so as long as the instance role is attached to the EC2 instance any command line tools running inside that instance can automatically make use of those credentials.

So at this point that's everything I wanted to cover thanks for watching go ahead and complete this video and when you're ready join me in the next lesson.

Welcome back and in this brief demonstration you'll have the opportunity to create an EC2 instance with WordPress bootstrapped in ready and waiting to be configured.

But this time you'll be using an enhanced CloudFormation template which uses CFN init and creation policies rather than the simple user data that you used in the previous demonstration.

To get started just make sure you are logged in to the general AWS account as the I am admin user and as always make sure you've got the northern Virginia region selected.

Now attached to this lesson are two one click deployment links.

Go ahead and use the first one which is the VPC link.

Everything should be pre-populated.

All you'll need to do is scroll down to the bottom, check the acknowledgement box and click on create stack.

Once it's moved into a create complete status you can resume and we'll carry on with the demo.

I'll assume that that's now in a create complete status and now we're going to apply another CloudFormation template.

This is the template that we'll be using.

It's just an enhancement of the one that you used in the previous lesson.

This time instead of using a set of procedural instructions, so a script that are passed into the user data, this uses the CFN init system and creation policies.

So let's have a look at exactly what that means.

If I scroll down and locate the EC2 instance logical resource, then here we've got this creation policy.

This means that CloudFormation is going to create a hold point.

It's not going to allow this resource to move into a create complete status until it receives a signal.

And it's going to wait 15 minutes for this signal.

So a timeout of 15 minutes.

Now scrolling down and looking at the user data, the only things we do in a procedural way, we use the CFN init command to begin the desired state configuration.

That will either succeed or not.

And based on that we use the CFN signal command to pass that success or failure state back to the CloudFormation stack.

And that's what uses this creation policy.

So the creation policy will wait for a signal and it's this command which provides that signal, either a success signal or a failure signal.

Now what we're interested in specifically for this demo lesson is this CFN init command.

So this is the thing that pulls the desired state configuration from the metadata of this logical resource.

I'll talk all about that in a second.

But it pulls that down by being given the stack ID and it uses this substitution command.

So instead of this being passed into the instance, what's actually passed instead of this variable name, so the stack ID variable name, is the actual stack ID.

And then likewise, instead of this variable name, aws colon region is passed to the actual region that this template is being applied into.

So that's what the substitution function does.

It replaces any variable or parameter names with the values of those variables or parameters.

So the CFN init process is then able to consult the CloudFormation stack and retrieve the configuration information.

That's all stored in the metadata section of this logical resource.

Now I just want to draw your attention to this double hyphen config sets wordpress underscore install.

This tells us what set of instructions we want CFN init to run.

So if I just expand the metadata section here, we've got one or more config sets defined.

In this case, we've only got the one which is wordpress underscore install.

And this config set runs five individual items, one after the other.

And these are called config keys.

So install CFN, software install, configure instance, install wordpress and configure wordpress.

Now these reference the config keys defined below.

So you'll see that the same name install CFN, software install, configure instance, install wordpress and configure wordpress.

You'll recognize a lot of the commands used because they're the same commands that install and configure wordpress.

So in the software install config key, we're using the DNF package manager to install various software packages that we need for this installation, such as WGet, MariaDB, the Apache web server and various other utilities.

Then another part is services and we're specifying that we want these services to be enabled and to be running.

So this means that the service will be set to start up on instance boot and it will make sure that it's running right now.

The next config key is configure instance.

The files component of this can create files with a certain content.

So we're creating a file called etc update-motd.d/40-cow.

This is the part that we had to do manually before and this is the thing that adds the cow say banner.

Then we're running some more procedural commands to set the database root password and to update this banner.

Then we've got install wordpress, which uses a sources option to expand whatever is specified here into this directory.

So this automatically handles the download and the unjzip and untarring of this archive into this folder and it can even do that with authentication if needed.

We're creating another file this time to perform the configuration of wordpress and another file this time to create the database for wordpress.

Then finally we've got the configure wordpress which fixes up the permissions and creates these databases.

So this is doing the same thing as the procedural example in the previous demo.

Instead of running all of these commands one by one, this is just using desired state.

Now there is one more thing that I wanted to point out right at the top.

This is the part that configures CFN init to keep watching the logical resource configuration inside the cloud formation stack.

And if it notices that the metadata for EC2 instance inside the stack changes, then it will run CFN init again.

Remember how in the theory lesson I mentioned that this process could cope with stack updates.

So it doesn't only run once like user data does.

Well, this is how it does that.

This configures this automatic update that keeps an eye on the cloud formation stack and reruns CFN init whenever any changes occur.

This is well beyond what you need for the associate exam.

I just want you to be aware of what this is and how it works.

Essentially we're setting up a process called CFN hop and making it watch the cloud formation stack for any configuration changes.

And then we're setting it up so that the CFN hop process is enabled and running so that it can watch the resource configuration constantly.

So that's it for this template.

What we'll do now is apply it.

So go ahead and click on the second one click deployment link attached to this lesson.

It should be called A4LEC2CFN init.

So click that link.

All you'll need to do is scroll down to the bottom and then click on create stack.

Now this time remember we're using a creation policy.

So cloud formation is not going to move this logical ID and to create complete when EC2 signals that the launch process is completed.

Instead it's going to wait until the instance itself signals the successful completion of the CFN init process.

So because we're using this creation policy it's going to hold until the instance operating system using CFN-signal provide a signal to cloud formation to say yep everything's okay and at that point the logical resource will move into create complete.

So that's going to take a couple of minutes.

The EC2 instance will need to actually launch itself and pass its status checks and then the CFN init process will run, perform all of the configuration required and then assuming the status code of that is okay then CFN-signal will take that status code and respond to the cloud formation stack with a successful completion and then the process will move on then cloud formation will mark the particular resources complete and the stack is complete.

Now that will take a few minutes so just keep hitting refresh and you should see the status update after two to three minutes but go ahead and pause the video and resume it once your stack moves into the create complete status.

And there we go at this point the stack has moved into the create complete status and I just want to draw your attention to this line.

You won't have seen this before.

This is the line where our EC2 instance has run the CFN init process successfully and then the CFN signal command has taken that success signal and delivered it to the cloud formation stack.

So this is the signal that cloud formation was waiting for before moving this resource into a create complete status and that's what's needed before the stack itself could move into a create complete status.

So now we explicitly know that the configuration of this instance has actually been completed.

So we're not relying on EC2 telling us that the instance status is now running with two out of two checks.

Instead the operating system itself the CFN init process that's completed successfully and the CFN signal process has explicitly indicated to cloud formation that that whole process has been completed.

So if we move across to the EC2 console we should be able to connect to the instance exactly as we've done before.

Look for the running instance and select it.

Copy the public IP version 4 IP address and open that in a new tab.

All being well you should see the familiar WordPress installation screen.

If you're right click on that instance and put connect.

Go to instance connect and hit connect that will connect you into the instance and you should be greeted by the cow themed login banner.

This time if we use curl to show us the contents of user data this time it's only a small number of lines because the only thing that runs is the CFN init process and the CFN signal process.

Notice though how all of these variable names have been replaced with their values so the stack IDs and the region.

So this is how it knows to communicate with the right stack in the right region inside cloud formation.

If we do a CD space forward slash var forward slash log and then do a listing we've still got these original two files so cloud hyphen init dot log and cloud hyphen init hyphen output dot log.

So these are primarily associated with the user data output.

But now we've also got these new log files so CFN hyphen init hyphen CMD dot log and that is an output of the CFN init process.

So if we cat that so shudu space cat space and then the name of that log file this will show us an output of the CFN init process itself.

So we can see each of the individual config keys running and what individual operations are being performed inside each of those keys.

So it's a more complex but a more powerful process.

And at this point that's everything I wanted to cover.

It was just to give you practical exposure to an alternative to raw user data and that was CFN hyphen init.

It's a much more powerful system especially when combined with cloud formation creation policies which allow us to pause the progress of a cloud formation stack waiting for the resource itself to explicitly say yes I finished off all of my bootstrapping process you're good to carry on and that's done using the CFN hyphen signal command.

Now at this point let's just clean up the account move back to cloud formation.

Once you there go ahead and delete the EC2 CFN init stack wait for that process to complete and once you've done that go ahead and delete the A4L VPC stack and that will return the AWS account into the state that you had it at the start of this demo.

At that point thanks for doing this demo I hope it was useful.

You can go ahead and complete this video now and when you're ready you can join me in the next.

Welcome back and in this demo lesson you're going to get the experience of bootstrapping an EC2 instance using user data.

So this is the ability to run a script during the provisioning process for an EC2 instance and automatically add a certain configuration to that instance during the build process.

So this is an alternative to creating a custom AMI.

Earlier in the course you created an Amazon machine image with the WordPress installation and configuration baked in.

Now that's really quick and simple but it does limit your ability to make changes to that configuration.

So the configuration is baked into the AMI and so you're limited as to what you can change during launch time.

With boot strapping you have the ability to perform all the steps in the form of a script during the provisioning process and so it can be a lot more flexible.

Now to get started we need to create the Animals for Life VPC within our general AWS account.

So this is the management account of the organization.

So make sure that you're logged into the IAM admin user of this account and as always make sure you have the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment link so go ahead and open that.

This is going to take you to the quick create stack page and everything should be pre-populated.

The stack name should be bootstrap everything else has appropriate default so just scroll down to the bottom, check the capabilities acknowledgement box and then go ahead and click on create stack.

Now this will create the Animals for Life VPC which contains the public subnets that we'll be launching our instance into and so we're going to need this to be in a create complete state before we move on.

So go ahead and pause the video and once your stack changes from create in progress to create complete then we good to continue.

Okay so now that that stack has moved into a create complete state we good to continue.

Now also attached to this lesson is another link which is the user data that we're going to use for this demo lesson so go ahead and open that link.

This is the user data that we're going to use to bootstrap the EC2 instance so what I want you to do is to download this file to your local machine and then open it in a code editor or alternatively just copy all the text on screen now and paste that into a code editor.

So I've gone ahead and opened that file in my text editor and if you look through all of the different commands contained within this user data .txt file then you should recognize some of them.

These are basically the commands that we ran earlier in the course when we manually installed word press and when we created the Amazon machine image.

So we're essentially installing the MariaDB database server, the Apache web server, Wget and Cowsay.

We're installing PHP and its associated libraries.

We're making sure that both the database and the web server are set to automatically start when the instance reboots and are explicitly started when this script is run.

We're setting the root password of the MariaDB database server.

We're downloading the latest copy of the WordPress installation archive.

We're extracting it and we're moving the files into the correct locations.

Then we're configuring WordPress by copying the sample configuration file into the final and proper file name so wp-config.php and then we're performing a search and replace on those placeholders and replacing them with our actual chosen values for the database name, the database user and the database password.

And then after that we're fixing up the permissions on the web root folder with the WordPress installation files inside so we're making sure that the ownership is correct and then we're fixing up the permissions with a slightly improved version of what we've used previously.

Then we're creating our DB.setup script in the same way that we did when we were manually installing WordPress.

We're logging into the database using the MySQL command line utility, authenticating as the root user with the root password and then running this script and this creates the WordPress database, the user sets the password and gives that user permissions on the database.

And then finally we're configuring the Cowsay utility so we're setting up the message of the day file we're outputting our animals for life custom greeting and then we're forcing a refresh of the login banner.

So these are all of the steps that you've previously done manually so I hope it's still fresh in your memory just how annoying that manual installation was.

Okay so at this point this user data is ready to go and I want to demonstrate to you how you can use this to bootstrap an EC2 instance.

So let's go ahead and move back to the AWS console.

Once we're at the AWS console this CloudFormation 1 click deployment has created the Animals for Life VPC.

So what we're going to do is to click on the services drop down and then move to the EC2 console and go ahead and click on launch instance followed by launch instance again.

So first things first the instance is going to be called a4l for animals for life - manual WordPress so go ahead and enter that in the box at the top then scroll down select Amazon Linux and then make sure Amazon Linux 2023 is selected in the drop down and then make sure that you've got 64-bit x86 selected.

I want you to pick whichever type is free tier eligible within your account and region in my case it's t2.micro but you should pick the one that's free tier eligible.

Under key pair go ahead and pick proceed without a key pair then scroll down to network settings and click on edit and there are a few items on this page that we need to explicitly configure.

The first is we need to select the Animals for Life VPC next to network so select a4l -vpc1 next to subnet I want you to go ahead and pick sn -web -a so that's the web or public subnet within availability zone a then make sure auto assign public IP is set to enable we'll be using an existing security group so check that box and then in the drop down so click the drop down and select the bootstrap -instance security group so bootstrap was the name of the cloud formation stack that we created using the one-click deployment we won't be making any changes to the storage configuration and next we need to scroll down to an option that we've not used before we're going to enter some user data so scroll all the way down and under advanced details expand this if it isn't already and you're looking for the user data box what we're going to do is paste in the user data that you just downloaded so in my case this is the user data.txt which I downloaded so I'm going to go ahead and select all of the information in this user data.txt making sure I get everything including the last line and I'm going to copy that into my clipboard now back at the AWS console we need to paste that in to the user data box now by default EC2 accepts user data as base64 encoded data so we need to provide it with base64 encoded data and we're not we're just giving it a normal text file so in this case the user interface can actually do this conversion for us so if what you're pasting in is not base64 encoded and what we're pasting in isn't then we don't need to do anything else if we're pasting in data which is already base64 encoded we need to check this box below the user data box we don't need to worry about that because we're not pasting in anything with base64 encoding so we can just paste in our user data directly into this box and this will be run during the instance launch process so this is where our automatic configuration comes from this is what will bootstrap the EC2 instance okay so that's everything we need to configure so go ahead and click on launch instance now at this point while this is launching I want you to keep in mind that in the previous demo examples in this course we manually launched an instance and then once the instance was in a running state we had to connect into it download WordPress install WordPress and then configure WordPress along with all of the other associated dependencies that WordPress requires so that was a fairly time-intensive process that was open to errors in the AMI example we followed that same process but at the end we created the Amazon machine image so keep that in mind and compare it to what your experience is in this demo lesson so now we've launched the instance and it's now in a running state and we've provided some user data to this instance so I want you to leave it a couple of minutes after it's showing in a running state just give it a brief while to perform that additional configuration after a few minutes go ahead and right click on that instance and select connect we're going to be using EC2 instance connect so make sure that's selected make sure the user is set to EC2 - user and then just click connect now what you should see if we've given this enough time is our custom animals for life login banner and that means that the bootstrapping process has completed think about this for a minute as part of the launch process EC2 has provisioned us an EC2 instance and it's also run a relatively complex installation and configuration script that we've supplied in the form of user data and that's downloaded and installed WordPress and configured our custom login banner if we go back to EC2 select instances and then if we copy the public IP address into our clipboard so copy the actual IP address do not click on this link because this will open it using HTTPS which we haven't configured if you take that IP address and open that in a new tab you'll see the installation dialogue for WordPress and that's because the bootstrapping process using the user data has done all the configuration process that previously we've had to do manually now if we go back to the instance I want to demonstrate architecturally and operationally exactly how this works what we can do is use the curl utility to review the instance metadata now because we're using Amazon Linux 2023 we need to do this slightly differently we need to use version 2 of the metadata service so first we need to run this command to get a token which we can use to authenticate to the metadata service so run this next we can run this command which gets us the metadata of the instance and this uses the 169254 169254 address or as I like to call it 169.254 repeating now if we use this with meta hyphen data on the end then we get the metadata service but as we know user data is a component of the metadata service so instead of using forward slash latest forward slash metadata we can replace metadata with user data and this will allow us to see the user data supplied to the instance and don't worry all of these commands will be attached to the lesson so you should recognize this this is the user data that we passed into the instance so this is performed a download a configuration and an installation of Apache the database server and WordPress as well as our custom login banner so that's how the user data gets into the EC2 instance and there's a service running on the EC2 instance which takes this data and automatically performs these configuration steps essentially this is run as a script on the operating system now something else we can do is to move into the forward slash VAR forward slash log folder and this is a folder which contains many of the system logs and if we do an LS space hyphen LA we'll see a collection of logs within this folder there are two logs in particular that are really useful for diagnosing bootstrapping related problems these logs are cloud hyphen init dot log and cloud hyphen init hyphen output dot log and both of these are used for slightly different reasons so what I want to do is to output one of these logs and show you the content so we're going to output using shudu first to get admin permissions and then cat and we're going to use the cloud hyphen init hyphen output dot log and I'm going to press enter and that's going to show you the contents of this file and you'll be able to see using this log file exactly what's been executed on this EC2 instance so you'll be able to see all of the actual commands and the output from those commands as they've been executed on this EC2 instance so you'll be able to see all of the WordPress related downloads and copies the replacements of the database usernames and passwords the permissions fix section the database creation user creation and then permissions on that database as well as the command that actually executes those and then right at the bottom is where we configure our custom login banner so this is how you can see exactly what's been run on this EC2 instance and if you ever encounter any issues with any of the demo lessons within this course or any of my courses then you can use this file to determine exactly what's happened on the EC2 instance as part of the bootstrapping process okay so this is the end of part one of this lesson it was getting a little bit on the long side and so I wanted to add a break it's an opportunity just to take a rest or grab a coffee part two will be continuing immediately from the end of part one so go ahead complete the video and when you're ready join me in part two.

Welcome back and in this demo lesson you're going to be creating an ECS cluster with the Fargate cluster mode and using the container of CATS container that we created together earlier in this section of the course, you're going to deploy this container into your Fargate cluster.

So you're going to get some practical experience of how to deploy a real container into a Fargate cluster.

Now you won't need any cloud formation templates applied to perform this demo because we're going to use the default VPC.

All that you'll need is to be logged in as the IAM admin user inside the management account of the organization and just make sure that you're in the Northern Virginia region.

Once you've confirmed that then just click in Find Services and type ECS and then click to move to the ECS console.

Once you're at the ECS console, step one is to create a Fargate cluster.

So that's the cluster that our container is going to run inside.

So click on clusters, then create cluster.

You'll need to give the cluster a name.

You can put anything you want here, but I recommend using the same as me and I'll be putting all the CATS.

Now Fargate mode requires a VPC.

I'm going to be suggesting that we use the default VPC because that's already configured, remember, to give public IP addresses to anything deployed into the public subnets.

So just to keep it simple and avoid any extra configuration, we'll use the default VPC.

Now it should automatically select all of the subnets within the default VPC, in my case all six.

If yours doesn't, just make sure you select all of the available subnets from this dropdown, but it should do this by default.

Then scroll down and just note how AWS Fargate is already selected and that's the default.

If you wanted to, you could check to use Amazon EC2 instances or external instances using ECS anywhere, but for this demo, we won't be doing that.

Instead, we'll leave everything else as default, scroll down to the bottom and click create.

If this is the first time you're doing this in an AWS account, it's possible that you'll get the error that's shown on screen now.

If you do get this error, then what I would suggest is to wait a few minutes, then go back to the main ECS console, go to cluster again and then create the all the cats cluster again.

So follow exactly the same steps, call the cluster all the cats, make sure that the animals for live default VPC is selected and all those subnets are present, and then click on create.

You should find that the second time that you run this creation process, it works okay.

Now this generally happens because there's an approval process that needs to happen behind the scenes.

So if this is the first time that you're using ECS within this AWS account, then you might get this error.

It's nothing to worry about, just rerun the process and it should create fine the second time.

Once you've followed that process through again, or if it works the first time, then just go ahead and click on the all the cats cluster.

So this is the Fargate based cluster.

It's in an active state, so we're good to deploy things into this cluster.

And we can see that we've got no active services.

If I click on tasks, we can see we've got no active tasks.

There's a tab here, metrics where you can see cloud watch metrics about this cluster.

And again, because this is newly created and it doesn't have any activity, all of this is going to be blank.

For now, that's fine.

What we need to do for this demonstration is create a task definition that will deploy our container, our container of cats container into this Fargate cluster.

To do that, click on task definitions and create a new task definition.

You'll need to pick a name for your task definition.

Go ahead and put container of cats.

And then inside this task definition, the first thing to do set the details of the container for this task.

So under container details under name, go ahead and put container of cats web.

So this is going to be the web container for the container of cats task.

Then next to the name under image URI, you need to point this at the docker image that's going to be used for this container.

So I'm going to go ahead and paste in the URI for my docker image.

So this is the docker image that I created earlier in the course within the EC2 docker demo.

You might have also created your own container image.

You can feel free to use my container image or you can use yours.

If you want to keep things simple, you should go ahead and use mine.

Yours should be the same anyway.

Now just to be careful, this isn't a URL.

This is a URI to point at my docker image.

So it consists of three parts.

First we have docker.io, which is the docker hub.

Then we have my username, so acantral.

And then we have the repository name, which is container of cats.

So if you want to use your own docker image, you need to change both the username and the repository name.

Again, to keep things simple, feel free to use my docker image.

Then scrolling down, we need to make sure that the port mappings are correct.

It should show what's on screen now, so container port 80, TCP.

And then the port name should be the same or similar to what's on screen now.

Don't worry if it's slightly different and the application protocol should be HTTP.

This is controlling the port mapping from the container through to the Fargate IP address.

And I'll talk more about this IP address later on in this demo.

Everything else looks good, so scroll down to the bottom and click on next.

We need to specify some environment details.

So under operating system/architecture, it needs to be linux/x86_64.

Under task size for memory, go ahead and select 1GB and then under CPU, 0.5 vCPU.

That should be enough resources for this simple docker application.

Scroll down and under monitoring and logging, uncheck use log collection.

We won't be needing it for this demo lesson.

That's everything we need to do.

Go ahead and click on next.

This is just an overview of everything that we've configured, so you can scroll down to the bottom and click on create.

And at this point, the task definition has been created successfully.

And this is where you can see all of the details of the task definition.

If you want to see the raw JSON for the task definition itself, you don't need this for the exam, but this is actually what a task definition looks like.

So it contains all of this different information.

What it has got is one or more container definitions.

So this is just JSON.

This is a list of container definitions.

We've only got the one.

And if you're looking at this, you can see where we set the port mapping.

So we're mapping port 80.

You can see where it's got the image URL, which is where it pulls the docker image from.

This is exactly what a normal task and container definition look like.

They can be significantly more complex, but this format is consistent across all task definitions.

Okay, so now it's time to launch a task.

It's time to take the container and task definitions that we've defined and actually run up a container inside ECS using those definitions.

So to do that, click on clusters and then select the all the cats cluster.

Click on tasks and then click on run a new task.

Now, first we need to pick the compute options and we're going to select launch type.

So check that box.

If appropriate for the certification that you're studying for, I'll be talking about the differences between these two in a different lesson.

Once you've clicked on launch type, make sure Fargate is selected in the launch type drop down and latest is selected under platform version.

Then scroll down and we're going to be creating a task.

So make sure that task is selected.

Scroll down again and under family, make sure container of cats is selected.

And then under revision, select latest.

We want to make sure the latest version is used and we'll leave desired tasks at one and task group blank.

Scroll down and expand networking.

Make sure the default VPC is selected and then make sure again that all of the subnets inside the default VPC are present under subnets.

The default is that all of them should be in my case six.

Now the way that this task is going to work is that when the task is run within Fargate, an elastic network interface is going to be created within the default VPC.

And that elastic network interface is going to have a security group.

So we need to make sure that the security group is appropriate and allows us to access our containerized application.

So check the box to say create a new security group and then for security group name and description, use container of cats -sg.

We need to make sure that the rule on this security group is appropriate.

So under type select HTTP and then under source change this to anywhere.

And this will mean that anyone can access this containerized application.

Finally make sure that public IP is turned on.

This is really important because this is how we'll access our containerized application.

Everything else looks good.

We can scroll down to the bottom and click on create.

Now give that a couple of seconds.

It should initially show last status.

So the last status should be set to provisioning and the desired state should be set to running.

So we need to wait for this task provisioning to complete.

So just keep hitting refresh.

You'll see it first change into pending.

Now at this point we need this task to be in a running state before we can continue.

So go ahead and pause the video and wait for both of these states.

So last status and desired status both of those need to be running before we continue.

So pause the video, wait for both of those to change and then once they have you can resume and will continue.

After another refresh the last status should now be running and in green and the desired state should also be running.

So at that point we're good to go.

We can click on the task link below.

We can scroll down and our task has been allocated a private IP version for address in the default VPC and also a public IP version for address also in the default VPC.

So if we copy this public IP into our clipboard and then open a new tab and browse to this IP we'll see our very corporate professional web application.

If it fits, I sits in a container in a container.

So we've taken a Docker image that we created earlier in this section of the course.

We've created a Fargate cluster, created a task definition with a container definition inside and deployed our container image as a container to this Fargate cluster.

So it's a very simple example, but again this scales.

So you could deploy Docker containers which are a lot more complex in what functionality they offer.

In this case it's just an Apache web server loading up a web page but we could deploy any type of web application using the same steps that you've performed in this demo lesson.

So congratulations, you've learned all of the theory that you'll need for the exam and you've taken the steps to implement this theory in practice by deploying a Docker image as a container on an ECS Fargate cluster.

So great job.

At this point all that remains is to tidy up.

So go back to the AWS console.

Just stop this container.

Click on stop.

Click on task definitions and then go into this task definition.

Select this.

Click on actions, deregister and then click on deregister.

Click back on task definitions and make sure there's no results there.

That's good.

Click on clusters.

Click on all the cats.

Delete the cluster.

You'll need to type delete space all the cats and then click on delete to confirm.

And at that point the Fargate cluster has been deleted.

The running container has been stopped.

The task definitions been deleted and our account is back in the same state as when we started.

So at this point you've completed the demo.

You've done great and you've implemented some pretty complex theory.

So you should already have a head start on any exam questions which involve ECS.

We're going to be using ECS a lot more as we move through the course and we're going to be using it in some of the Animals for Life demos as we implement progressively more complex architectures later on in the course.

For now I just wanted to give you the basics but you've done really well if you've implemented this successfully without any issues.

So at this point go ahead, complete this video and when you're ready join me in the next.

Welcome back and in this demo lesson you're going to learn how to install the Docker engine inside an EC2 instance and then use that to create a Docker image.

Now this Docker image is going to be running a simple application and we'll be using this Docker image later in this section of the course to demonstrate the Elastic Container service.

So this is going to be a really useful demo where you're going to gain the experience of how to create a Docker image.

Now there are a few things that you need to do before we get started.

First as always make sure that you're logged in to the I am admin user of the general AWS account and you'll also need the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment link so go ahead and click that now.

This is going to deploy an EC2 instance with some files pre downloaded that you'll use during the demo lesson.

Now everything's pre-configured you just need to check this box at the bottom and click on create stack.

Now that's going to take a few minutes to create and we need this to be in a create complete state.

So go ahead and pause the video wait for your stack to move into create complete and then we're good to continue.

So now this stack is in a create complete state and we're good to continue.

Now if you're following along with this demo within your own environment there's another link attached to this lesson called the lesson commands document and that will include all of the commands that you'll need to type as you move through the demo.

Now I'm a fan of typing all commands in manually because I personally think that it helps you learn but if you are the type of person who has a habit of making mistakes when typing along commands out then you can copy and paste from this document to avoid any typos.

Now one final thing before we finish at the end of this demo lesson you'll have the opportunity to upload the Docker image that you create to Docker Hub.

If you're going to do that then you should pre sign up for a Docker Hub account if you don't already have one and the link for this is included attached to this lesson.

If you already have a Docker Hub account then you're good to continue.

Now at this point what we need to do is to click on the resources tab of this stack and locate the public EC2 resource.

Now this is a normal EC2 instance that's been provisioned on your behalf and it has some files which have been pre downloaded to it.

So just go ahead and click on the physical ID next to public EC2 and that will move you to the EC2 console.

Now this machine is set up and ready to connect to and I've configured it so that we can connect to it using Session Manager and this avoids the need to use SSH keys.

So to do that just right-click and then select connect.

You need to pick Session Manager from the tabs across the top here and then just click on connect.

Now that will take a few minutes but once connected you should see this prompt.

So it should say SH- and then a version number and then dollar.

Now the first thing that we need to do as part of this demo lesson is to install the Docker engine.

The Docker engine is the thing that allows Docker containers to run on this EC2 instance.

So we need to install the Docker engine package and we'll do that using this command.

So we're using shudu to get admin permissions then the package manager DNF then install then Docker.

So go ahead and run that and that will begin the installation of Docker.

It might take a few moments to complete it might have to download some prerequisites and you might have to answer that you're okay with the install.

So press Y for yes and then press enter.

Now we need to wait a few moments for this install process to complete and once it has completed then we need to start the Docker service and we do that using this command.

So shudu again to get admin permissions and then service and then the Docker service and then start.

So type that and press enter and that starts the Docker service.

Now I'm going to type clear and then press enter to make this easier to see and now we need to test that we can interact with the Docker engine.

So the most simple way to do that is to type Docker space and then PS and press enter.

Now you're going to get an error.

This error is because not every user of this EC2 instance has the permissions to interact with the Docker engine.

We need to grant permissions for this user or any other users of this EC2 instance to be able to interact with the Docker engine and we're going to do that by adding these users to a group and we do that using this command.

So shudu for admin permissions and then user mod -a -g for group and then the Docker group and then EC2 -user.

Now that will allow a local user of this system, specifically EC2 -user, to be able to interact with the Docker engine.

Okay so I've cleared the screen to make it slightly easier to see now that we've added EC2 -user the ability to interact with Docker.

So the next thing is we need to log out and log back in of this instance.

So I'm going to go ahead and type exit just to disconnect from session manager and then click on close and then I'm going to reconnect to this instance and you need to do the same.

So connect back in to this EC2 instance.

Now once you're connected back into this EC2 instance we need to run another command which moves us into EC2 user so it basically logs us in as EC2 -user.

So that's this command and the result of this would be the same as if you directly logged in to EC2 -user.

Now the reason we're doing it this way is because we're using session manager so that we don't need a local SSH client or to worry about SSH keys.

We can directly log in via the console UI we just then need to switch to EC2 -user.

So run this command and press enter and we're now logged into the instance using EC2 -user and to test everything's okay we need to use a command with the Docker engine and that command is Docker space ps and if everything's okay you shouldn't see any output beyond this list of headers.

What we've essentially done is told the Docker engine to give us a list of any running containers and even though we don't have any it's not erred it's simply displayed this empty list and that means everything's okay.

So good job.

Now what I've done to speed things up if you just run an LS and press enter the instance has been configured to download the sample application that we're going to be using and that's what the file container.zip is within this folder.

I've configured the instance to automatically extract that zip file which has created the folder container.

So at this point I want you to go ahead and type cd space container and press enter and that's going to move you inside this container folder.

Then I want you to clear the screen by typing clear and press enter and then type ls space -l and press enter.

Now this is the web application which I've configured to be automatically downloaded to the EC2 instance.

It's a simple web page we've got index.html which is the index we have a number of images which this index.html contains and then we have a docker file.

Now this docker file is the thing that the docker engine will use to create our docker image.

I want to spend a couple of moments just stepping you through exactly what's within this docker file.

So I'm going to move across to my text editor and this is the docker file that's been automatically downloaded to your EC2 instance.

Each of these lines is a directive to the docker engine to perform a specific task and remember we're using this to create a docker image.

This first line tells the docker engine that we want to use version 8 of the Red Hat Universal base image as the base component for our docker image.

This next line sets the maintainer label it's essentially a brief description of what the image is and who's maintaining it in this case it's just a placeholder of animals for life.

This next line runs a command specifically the yum command to install some software specifically the Apache web server.

This next command copy copies files from the local directory when you use the docker command to create an image so it's copying that index.html file from this local folder that I've just been talking about and it's going to put it inside the docker image in this path so it's going to copy index.html to /var/www/html and this is where an Apache web server expects this index.html to be located.

This next command is going to do the same process for all of the jpegs in this folder so we've got a total of six jpegs and they're going to be copied into this folder inside the docker image.

This line sets the entry point and this essentially determines what is first run when this docker image is used to create a docker container.

In this example it's going to run the Apache web server and finally this expose command can be used for a docker image to tell the docker engine which services should be exposed.

Now this doesn't actually perform any configuration it simply tells the docker engine what port is exposed in this case port 80 which is HTTP.

Now this docker file is going to be used when we run the next command which is to create a docker image.

So essentially this file is the same docker file that's been downloaded to your EC2 instance and that's what we're going to run next.

So this is the next command within the lesson commands document and this command builds a container image.

What we're essentially doing is giving it the location of the docker file.

This dot at the end contains the working directory so it's here where we're going to find the docker file and any associated files that that docker file uses.

So we're going to run this command and this is going to create our docker image.

So let's go ahead and run this command.

It's going to download version 8 of UBI which it will use as a starting point and then it's going to run through every line in the docker file performing each of the directives and each of those directives is going to create another layer within the docker image.

Remember from the theory lesson each line within the docker file generally creates a new file system layer so a new layer of a docker image and that's how docker images are efficient because you can reuse those layers.

Now in this case this has been successful.

We've successfully built a docker image with this ID so it's giving it a unique ID and it's tagged this docker image with this tag colon latest.

So this means that we have a docker image that's now stored on this EC2 instance.

Now I'll go ahead and clear the screen to make it easier to see and let's go ahead and run the next command which is within the lesson commands document and this is going to show us a list of images that are on this EC2 instance but we're going to filter based on the name container of cats and this will show us the docker image which we've just created.

So the next thing that we need to do is to use the docker run command which is going to take the image that we've just created and use it to create a running container and it's that container that we're going to be able to interact with.

So this is the command that we're going to use it's the next one within the lesson commands document.

It's docker run and then it's telling it to map port 80 on the container with port 80 on the EC2 instance and it's telling it to use the container of cats image and if we run that command docker is going to take the docker image that we've got on this EC2 instance run it to create a running container and we should be able to interact with that container.

So if you go back to the AWS console if we click on instances so look for a4l-public EC2 that's in the running state.

I'm just going to go ahead and select this instance so that we can see the information and we need the public IP address of this instance.

Go ahead and click on this icon to copy the public IP address into your clipboard and then open that in a new tab.

Now be sure not to use this link to the right because that's got a tendency to open the HTTPS version.

We just need to use the IP address directly.

So copy that into your clipboard open a new tab and then open that IP address and now we can see the amazing application if it fits i sits in a container in a container and this amazing looking enterprise application is what's contained in the docker image that you just created and it's now running inside a container based off that image.

So that's great everything's working as expected and that's running locally on the EC2 instance.

Now in the demo lesson for the elastic container service that's coming up later in this section of the course you have two options.

You can either use my docker image which is this image that I've just created or you can use your own docker image.

If you're going to use my docker image then you can skip this next step.

You don't need a docker hub account and you don't need to upload your image.

If you want to use your own image then you do need to follow these next few steps and I need to follow them anyway because I need to upload this image to docker hub so that you can potentially use it rather than your own image.

So I'm going to move back to the session manager tab and I'm going to control C to exit out of this running container and I'm going to type clear to clear the screen and make it easier to see.

Now to upload this to docker hub first you need to log in to docker hub using your credentials and you can do that using this command.

So it's docker space login space double hyphen username equals and then your username.

So if you're doing this in your own environment you need to delete this placeholder and type your username.

I'm going to type my username because I'll be uploading this image to my docker hub.

So this is my docker hub username and then press enter and it's going to ask for the corresponding password to this username.

So I'm going to paste in my password if you're logging into your docker hub you should use your password.

Once you've pasted in the password go ahead and press enter and that will log you in to docker hub.

Now you don't have to worry about the security message because whilst your docker hub password is going to be stored on the EC2 instance shortly we're going to terminate this instance which will remove all traces of this password from this machine.

Okay so again we're going to upload our docker image to docker hub so let's run this command again and you'll see because we're just using the docker images command we can see the base image as well as our image.

So we can see red hat UBI 8.

We want the container of cats latest though so what you need to do is copy down the image ID of the container of cats image.

So this is the top line in my case container of cats latest and then the image ID.

So then we need to run this command so docker space tag and then the image ID that you've just copied into your clipboard and then a space and then your docker hub username.

In my case it's actrl with 1L if you're following along you need to use your own username and then forward slash and then the name of the image that you want this to be stored as on docker hub so I'm going to use container of cats.

So that's the command you need to use so docker tag and then your image ID for container of cats and then your username forward slash container of cats and press enter and that's everything we need to do to prepare to upload this image to docker hub.

So the last command that we need to run is the command to actually upload the image to docker hub and that command is docker space push so we're going to push the image to docker hub then we need to specify the docker hub username so again this is my username but if you're doing this in your environment it needs to be your username and then forward slash and then the image name in my case container of cats and then colon latest and once you've got all that go ahead and press enter and that's going to push the docker image that you've just created up to your docker hub account and once it's up there it means that we can deploy from that docker image to other EC2 instances and even ECS and we're going to do that in a later demo in this section of the course.

Now that's everything that you need to do in this demo lesson you've essentially installed and configured the docker engine you've used a docker file to create a docker image from some local assets you've tested that docker image by running a container using that image and then you've uploaded that image to docker hub and as I mentioned before we're going to use that in a future demo lesson in this section of the course.

Now the only thing that remains to do is to clear up the infrastructure that we've used in this demo lesson so go ahead and close down all of these extra tabs and go back to the cloud formation console this is the stack that's been created by the one click deployment link so all you need to do is select this stack it should be called EC2 docker and then click on delete and confirm that deletion and that will return the account into the same state as it was at the start of this demo lesson.

Now that is everything you need to do in this demo lesson I hope it's been useful and I hope you've enjoyed it so go ahead and complete the video and when you're ready I look forward to you joining me in the next.

Welcome back and in this very brief demo lesson, I just want to demonstrate a very specific feature of EC2 known as termination protection.

Now you don't have to follow along with this in your own environment, but if you are, you should still have the infrastructure created from the previous demo lesson.

And also if you are following along, you need to be logged in as the I am admin user to the general AWS account.

So the management account of the organization and have the Northern Virginia region selected.

Now again, this is going to be very brief.

So it's probably not worth doing in your own environment unless you really want to.

Now what I want to demonstrate is termination protection.

So I'm going to go ahead and move to the EC2 console where I still have an EC2 instance running created in the previous demo lesson.

Now normally if I right click on this instance, I'm given the ability to stop the instance, to reboot the instance or to terminate the instance.

And this is assuming that the instance is currently in a running state.

Now if I go to terminate instance, straight away I'm presented with a dialogue where I need to confirm that I want to terminate this instance.

But it's easy to imagine that somebody who's less experienced with AWS can go ahead and terminate that and then click on terminate to confirm the process without giving it much thought.

And that can result in data loss, which isn't ideal.

What you can do to add another layer of protection is to right click on the instance, go to instance settings, and then change termination protection.

If you click that option, you get this dialogue where you can enable termination protection.

So I'm going to do that, I'm going to enable termination protection because this is an essential website for animals for life.

So I'm going to enable it and click on save.

And now that instance is protected against termination.

If I right click on this instance now and go to terminate instance and then click on terminate, I get a dialogue that I'm unable to terminate the instance.

The instance and then the instance ID may not be terminated, modify its disable API termination instance attribute and then try again.

So this instance is now protected against accidental termination.

Now this presents a number of advantages.

One, it protects against accidental termination, but it also adds a specific permission that is required in order to terminate an instance.

So you need the permission to disable this termination protection in addition to the permissions to be able to terminate an instance.

So you have the option of role separation.

You can either require people to have both the permissions to disable termination protection and permissions to terminate, or you can give those permissions to separate groups of people.

So you might have senior administrators who are the only ones allowed to remove this protection, and junior or normal administrators who have the ability to terminate instances, and that essentially establishes a process where a senior administrator is required to disable the protection before instances can be terminated.

It adds another approval step to this process, and it can be really useful in environments which contain business critical EC2 instances.

So you might not have this for development and test environments, but for anything in production, this might be a standard feature.

If you're provisioning instances automatically using cloud formation or other forms of automation, this is something that you can enable in an automated way as instances are launching.

So this is a really useful feature to be aware of.

And for the SysOps exam, it's essential that you understand when and where you'd use this feature.

And for both the SysOps and the developer exams, you should pay attention to this, disable API termination.

You might be required to know which attribute needs to be modified in order to allow terminations.

So really for both of the exams, just make sure that you're aware of exactly how this process works end to end, specifically the error message that you might get if this attribute is enabled and you attempt to terminate an instance.

At this point though, that is everything that I wanted to cover about this feature.

So right click on the instance, go to instance settings, change the termination protection and disable it, and then click on save.

One other feature which I want to introduce quickly, if we right click on the instance, go to instance settings, and then change shutdown behavior, you're able to specify whether an instance should move into a stop state when shut down, or whether you want it to move into a terminate state.

Now logically, the default is stop, but if you are running an environment where you don't want to consider the state of an instance to be valuable, then potentially you might want it to terminate when it shuts down.

You might not want to have an account with lots of stopped instances.

You might want the default behavior to be terminate, but this is a relatively niche feature, and in most cases, you do want the shutdown behavior to be stop rather than terminate, but it's here where you can change that default behavior.

Now at this point, that is everything I wanted to cover.

If you were following along with this in your own environment, you do need to clear up the infrastructure.

So click on the services dropdown, move to cloud formation, select the status checks and protect stack, and then click on delete and confirm that by clicking delete stack.

And once this stack finishes deleting all of the infrastructure that's been used during this demo and the previous one will be cleared from the AWS account.

If you've just been watching, you don't need to worry about any of this process, but at this point, we're done with this demo lesson.

So go ahead, complete the video, and once you're ready, I'll look forward to you joining me in the next.

Welcome back and in this demo lesson either you're going to get the experience or you can watch me interacting with an Amazon machine image.

So we created an Amazon machine image or AMI in a previous demo lesson and if you recall it was customized for animals for life.

It had an install of WordPress and it had the Kause application installed and a custom login banner.

Now this is a really simple example of an AMI but I want to step you through some of the options that you have when dealing with AMIs.

So if we go to the EC2 console and if you are following along with this in your own environment do make sure that you're logged in as the IAM admin user of the general AWS account, so the management account of the organization and you have the Northern Virginia region selected.

The reason for being so specific about the region is that AMIs are regional entities so you create an AMI in a particular region.

So if I go and select AMIs under images within the EC2 console I'll see the animals for life AMI that I created in a previous demo lesson.

Now if I go ahead and change the region maybe from Northern Virginia which is US-East-1 to US-East- Ohio which is US-East-2 if I make that change what we'll see is we'll go back to the same area of the console only now we won't see any AMIs that's because an AMI is tied to the region in which it's created.

Every AMI belongs in one region and it has a unique AMI ID.

So let's move back to Northern Virginia.

Now we are able to copy AMIs between regions this allows us to make one AMI and use it for a global infrastructure platform so we can right-click and select copy AMI then select the destination region and then for this example let's say that I did want to copy it to Ohio then I would select that in the drop-down it would allow me to change the name if I wanted or I could keep it the same for description it would show that it's been copied from this AMI ID in this region and then it would have the existing description at the end.

So at this point I'm going to go ahead and click copy AMI and that process has now started so if I close down this dialogue and then change it from US East 1 to US East 2 so select that now we have a pending AMI and this is the AMI that's being copied from the US - East - one region into this region if we go ahead and click on snapshots under elastic block store then we're going to see the snapshot or snapshots which belong to this AMI.

Now depending on how busy AWS is it can take a few minutes for the snapshots to appear on this screen just go ahead and keep refreshing until they appear.

In our case we only have the one which is the boot volume that's used for our custom AMI.

Now the time taken to copy a snapshot between regions depends on many factors what the source and destination region are and the distance between the two the size of the snapshot and the amount of data it contains and it can take anywhere from a few minutes to much much longer so this is not an immediate process.

Once the snapshot copy completes then the AMI copy process will complete and that AMI is then available in the destination region but an important thing that I want to keep stressing throughout this course is that this copied AMI is a completely different AMI.

AMIs are regional don't fall for any exam questions which attempt to have you use one AMI for several regions.

If we're copying this animals for life AMI from one region to another region in effect we're creating two different AMIs.

So take note of this AMI ID in this region and if we switch back to the original source region so US - East - 1 note how this AMI has a different ID so they are different AMIs completely different AMIs you're creating a new one as part of the copy process.

So while the data is going to be the same conceptually they are completely separate objects and that's critical for you to understand both for production usage and when answering any exam questions.

Now while that's copying I want to demonstrate the other important thing which I wanted to show you in this demo lesson and that's permissions of AMIs.

So if I right-click on this AMI and edit AMI permissions by default an AMI is private.

Being private means that it's only accessible within the AWS account which has created the AMI and so only identities within that account that you grant permissions are able to access it and use it.

Now you can change the permission of the AMI you could set it to be public and if you set it to public it means that any AWS account can access this AMI and so you need to be really careful if you select this option because you don't want any sensitive information contained in that snapshot to be leaked to external AWS accounts.

A much safer way is if you do want to share the AMI with anyone else then you can select private but explicitly add other AWS accounts to be able to interact with this AMI.

So I could click in this box and then for example if I clicked on services and I just moved to the AWS organization service I'll open that in a new tab and let's say that I chose to share this AMI with my production account so I selected my production account ID and then I could add this into this box which would grant my production AWS account the ability to access this AMI.

Now no tell there's also this checkbox and this adds create volume permissions to the snapshots associated with this AMI so this is something that you need to keep in mind.

Generally if you are sharing an AMI to another account inside your organization then you can afford to be relatively liberal with permissions so generally if you're sharing this internally I would definitely check this box and that gives full permissions on the AMI as well as the snapshots so that anyone can create volumes from those snapshots as well as accessing the AMI.

So these are all things that you need to consider.

Generally it's much preferred to explicitly grant an AWS account permissions on an AMI rather than making that AMI public.

If you do make it public you need to be really sure that you haven't leaked any sensitive information, specifically access keys.

While you do need to be careful of that as well if you're explicitly sharing it with accounts, generally if you're sharing it with accounts then you're going to be sharing it with trusted entities.

You need to be very very careful if ever you're using this public option and I'll make sure I include a link attached to this lesson which steps through all of the best practice steps that you need to follow if you're sharing an AMI publicly.

There are a number of really common steps that you can use to minimize lots of common security issues and that's something you should definitely do if you're sharing an AMI.

Now if you want to do you could also share an AMI with an organizational unit or organization and you can do that using this option.

This makes it easier if you want to share an AMI with all AWS accounts within your organization.

At this point though I'm not going to do that we don't need to do that in this demo.

What we're going to do now though is move back to US-East-2.

That's everything I wanted to cover in this demo lesson.

Now this AMI is available we can right click and select D register and move back to US-East-1 and now that we've done this demo lesson we can do the same process with this AMI.

So we can right click select D register and that will remove that AMI.

Click on snapshots this is the snapshot created by this AMI so we need to delete this as well right click delete that snapshot confirm that and we'll need to do the same process in the region that we copied the AMI and the snapshots to.

So select US-East-2 it should be the only snapshot in the region make sure it is the correct one right click delete confirm that deletion and now you've cleared up all of the extra things created within this demo lesson.

Now that's everything that I wanted to cover I just wanted to give you an overview of how to work with AMIs from the console UI from a copying and sharing perspective.

Go ahead and complete this video and when you're ready I look forward to you joining me in the next.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

So the first step is to shut down this instance.

So we don't want to create an AMI from a running instance because that can cause consistency issues.

So we're going to close down this tab.

We're going to return to instances, right-click, and we're going to stop the instance.

We need to acknowledge this and then we need to wait for the instance to change into the stopped state.

It will start with stopping.

We'll need to refresh it a few times.

There we can see it's now in a stopped state and to create the AMI, we need to right-click on that instance, go down to Image and Templates, and select Create Image.

So this is going to create an AMI.

And first we need to give the AMI a name.

So let's go ahead and use Animals for Life template WordPress.

And we'll use the same for Description.

Now what this process is going to do is it's going to create a snapshot of any of the EBS volumes, which this instance is using.

It's going to create a block device mapping, which maps those snapshots onto a particular device ID.

And it's going to use the same device ID as this instance is using.

So it's going to set up the storage in the same way.

It's going to record that storage inside the AMI so that it's identical to the instance we're creating the AMI from.

So you'll see here that it's using EBS.

It's got the original device ID.

The volume type is set to the same as the volume that our instance is using, and the size is set to 8.

Now you can adjust the size during this process as well as being able to add volumes.

But generally when you're creating an AMI, you're creating the AMI in the same configuration as this original instance.

Now I don't recommend creating an AMI from a running instance because it can cause consistency issues.

If you create an AMI from a running instance, it's possible that it will need to perform an instance reboot.

You can force that not to occur, so create an AMI without rebooting.

But again, that's even less ideal.

The most optimal way for creating an AMI is to stop the instance and then create the AMI from that stopped instance, which will have fully consistent storage.

So now that that's set, just scroll down to the bottom and go ahead and click on Create Image.

Now that process will take some time.

If we just scroll down, look under Elastic Block Store and click on Snapshots.

You'll see that initially it's creating a snapshot of the boot volume of our original EC2 instance.

So that's the first step.

So in creating the AMI, what needs to happen is a snapshot of any of the EBS volumes attached to that EC2 instance.

So that needs to complete first.

Initially it's going to be an appending state.

We'll need to give that a few moments to complete.

If we move to AMIs, we'll see that the AMI is also creating it too.

It is in appending state and it's waiting for that snapshot to complete.

Now creating a snapshot is storing a full copy of any of the data on the original EBS volume.

And the time taken to create a snapshot can vary.

The initial snapshot always takes much longer because it has to take that full copy of data.

And obviously depending on the size of the original volume and how much data is being used, will influence how long a snapshot takes to create.

So the more data, the larger the volume, the longer the snapshot will take.

After a few more refreshes, the snapshot moves into a completed status and if we move across to AMIs under images, after a few moments this too will change away from appending status.

So let's just refresh it.

After a few moments, the AMI is now also in an available state and we're good to be able to use this to launch additional EC2 instances.

So just to summarize, we've launched the original EC2 instance, we've downloaded, installed and configured WordPress, configured that custom banner.

We've shut down the EC2 instance and generated an AMI from that instance.

And now we have this AMI in a state where we can use it to create additional instances.

So we're going to do that.

We're going to launch an additional instance using this AMI.

While we're doing this, I want you to consider exactly how much quicker this process now is.

So what I'm going to do is to launch an EC2 instance from this AMI and note that this instance will have all of the configuration that we had to do manually, automatically included.

So right click on this AMI and select launch.

Now this will step you through the launch process for an EC2 instance.

You won't have to select an AMI because obviously you are now explicitly using the one that you've just created.

You'll be asked to select all of the normal configuration options.

So first let's put a name for this instance.

So we'll use the name "instance" from AMI.

Then we'll scroll down.

As I mentioned moments ago, we don't have to specify an AMI because we're explicitly launching this instance from an AMI.

Scroll down.

You'll need to specify an instance type just as normal.

We'll use a free tier eligible instance.

This is likely to be T2 or T3.micro.

Below that, go ahead and click and select Proceed without a key pair not recommended.

Scroll down.

We'll need to enter some networking settings.

So click on Edit next to Network Settings.

Click in VPC and select A4L-VPC1.

Click in Subnet and make sure that SN-Web-A is selected.

Make sure the box is below a both set to enable for the auto assign IP settings.

Under Firewall, click on Select Existing Security Group.

Click in the Security Groups drop down and select AMI-Demo-Instance Security Group.

And that will have some random at the end.

That's absolutely fine.

Select that.

Scroll down.

And notice that the storage is configured exactly the same as the instance which you generated this AMI from.

Everything else looks good.

So we can go ahead and click on Launch Instance.

So this is launching an instance using our custom created AMI.

So let's close down this dialog and we'll see the instance initially in a pending state.

Remember, this is launching from our custom AMI.

So it won't just have the base Amazon Linux 2 operating system.

Now it's going to have that base operating system plus all of the custom configuration that we did before creating the AMI.

So rather than having to perform that same WordPress download installation configuration and the banner configuration each and every time, now we've baked that in to the AMI.

So now when we launch one instance, 10 instances, or 100 instances from this AMI, all of them are going to have this configuration baked in.

So let's give this a few minutes to launch.

Once it's launched, we'll select it, right click, select Connect, and then connect into it using EC2, Instance Connect.

Now one thing you will need to change because we're using a custom AMI, AWS can't necessarily detect the correct username to use.

And so you might see sometimes it says root.

Just go ahead and change this to EC2-user and then go ahead and click Connect.

And if everything goes well, you'll be connected into the instance and you'll see our custom Cowsay banner.

So all that configuration is now baked in and it's automatically included whenever we use that AMI to launch an instance.

If we go back to the AWS console and select instances, make sure we still have the instance from AMI selected and then locate its public IP version for address.

Don't use this link because that will use HTTPS instead, copy the IP address into your clipboard and open that in a new tab.

Again, all being well, you should see the WordPress installation dialogue and that's because we've baked in the installation and the configuration into this AMI.

So we've massively reduced the ongoing efforts required to launch an animals for life standard build configuration.

If we use this AMI to launch hundreds or thousands of instances each and every time we're saving all the time and the effort required to perform this configuration and using an AMI is just one way that we can automate the build process of EC2 instances within AWS.

And over the remainder of the course, I'm going to be demonstrating the other ways that you can use as well as comparing and contrasting the advantages and disadvantages of each of those methods.

Now that's everything that I wanted to cover in this demo lesson.

You've learned how to create an AMI and how to use it to save significant effort on an ongoing basis.

So let's clear up all of the infrastructure that we've used in this lesson.

So move back to the AWS console, close down this tab, go back to instances, and we need to manually terminate the instance that we created from our custom AMI.

So right click and then go to terminate instance.

You'll need to confirm that.

That will start the process of termination.

Now we're not going to delete the AMI or snapshots because there's a demo coming up later in this section of the course where you're going to get the experience of copying and sharing an AMI between AWS regions.

So we're going to need to leave this in place.

So we're not going to delete the AMI or the snapshots created within this lesson.

Verify that that instance has been terminated and once it has, click on services, go to cloud formation, select the AMI demo stack, select delete and then confirm that deletion.

And that will remove all of the infrastructure that we've created within this demo lesson.

And at this point, that's everything that I wanted you to do in this demo.

So go ahead, complete this video.

And when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this demo lesson you'll be creating an AMI from a pre-configured EC2 instance.

So you'll be provisioning an EC2 instance, configuring it with a popular web application stack and then creating an AMI of that pre-configured web application.

Now you know in the previous demo where I said that you would be implementing the WordPress manual install once?

Well I might have misled you slightly but this will be the last manual install of WordPress in the course, I promise.

What we're going to do together in this demo lesson is create an Amazon Linux AMI for the animals for life business but one which includes some custom configuration and an install of WordPress ready and waiting to be initially configured.

So this is a fairly common use case so let's jump in and get started.

Now in order to perform this demo you're going to need some infrastructure, make sure you're logged into the general AWS account, so the management account of the organization and as always make sure that you have the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment link, go ahead and click that link.

This will open the quick create stack screen, it should automatically be populated with the AMI demo as the stack name, just scroll down to the bottom, check this capabilities acknowledgement box and then click on create stack.

We're going to need this stack to be in a create complete state so go ahead and pause the video and we can resume once the stack moves into create complete.

Okay so that stacks now moved into a create complete state, we're good to continue with the demo.

Now you're going to be using some command line commands within an EC2 instance as part of creating an Amazon machine image so also attached to this lesson is the lessons command document which contains all of those commands so go ahead and open that document.

Now you might recognize these as the same commands that you used when you were performing a manual WordPress installation and that's the case we're running the same manual installation process as part of setting up our animals for life AMI so you're going to need all of these commands but as you've already experienced them in the previous demo lesson I'm going to run through them a lot quicker in this demo lesson so go back to the AWS console and we need to move to the EC2 area of the console so click on the services drop down, type EC2 into this search box and then open that in a new tab.

Once you there go ahead and click on running instances, close down any dialogues about any console changes we want to maximize the amount of screen space that we have, we're going to connect to this A4L public EC2 instance this is the instance that we're going to use to create our AMI so we're going to set the instance up manually how we want it to be and then we're going to use it to generate an AMI so we need to connect to this instance so right click select connect we're going to use EC2 instance connect to do the work within our browser so make sure the username is EC2-user and then connect to this instance then once connected we're going to run through the commands to install WordPress really quickly we're going to start again by setting the variables that will use throughout the installation so you can just go ahead and copy and paste those straight in and press enter now we're going to run through all of the next set of commands really quickly because you use them in the previous demo lesson so first we're going to go ahead and install the MariaDB server Apache and the Wget utility while that's installing copy all of the commands from step 3 so these are commands which enable and start Apache and MariaDB go ahead and paste all of those four in and press enter so now Apache and MariaDB are both set to start when the instance boots as well as being set to currently started I'll just clear the screen to make this easier to see next we're going to set the DB root password again that's this command using the contents of the variable that you set at the start next we download WordPress once it's downloaded we move into the web root folder we extract the download we copy the files from within the WordPress folder that we've just extracted into the current folder which is the web root once we've done that we remove the WordPress folder itself and then we tidy up by deleting the download I'm going to clear the screen we copy the template configuration file into its final file name so wp-config.php then we're going to replace the placeholders in that file we're going to start with the database name using the variable that you set at the start next we're going to use the database user which you also set at the start and finally the database password and then we're going to set the ownership on all of these files to be the Apache user and the Apache group clear the screen next we need to create the DB setup script that are demonstrated in the previous demo so we need to run a collection of commands the first to enter the create database command the next one to enter the create user command and set that password the next one to grant permissions on the database to that user then flush the permissions then we need to run that script using the MySQL command line interface that runs all of those commands and performs all of those operations and then we tidy up by deleting that file now at this point we've done the exact same process that we did in the previous demo we've installed and set up WordPress and if everything's working okay we can go back to the AWS console click on instances select the running a4l-public ec2 instance copy down its IP address again make sure you copy that down don't click this link and then open that in a new tab if everything's working as expected you should see the WordPress installation dialogue now this time because we're creating an AMI we don't want to perform the installation we want to make sure that when anyone uses this AMI they're also greeted with this installation so we're going to leave this at this point we're not going to perform the installation instead we're going to go back to the ec2 instance now because this ec2 instance is for the animals for life business we want to customize it and make sure that everybody knows that this is an animals for life ec2 instance now to do that we're going to install an animal themed utility called cow say I'm going to clear the screen to make it easier to see and then just to demonstrate exactly what cow say does I'm going to run a cow say oh hi and if all goes well we see a cow using ASCII art saying the oh hi message that we just typed so we're going to use this to create a message of the day welcome when anyone connects to this ec2 instance to do that we're going to create a file inside the configuration folder of this ec2 instance so we're going to use shudu nano and we're going to create this file so forward slash etc forward slash update hyphen motd dot d forward slash 40 hyphen cow so we're going to create that file this is the file that's going to be used to generate the output when anyone logs in to this ec2 instance so we're going to copy in these two lines and then press enter so this means when anyone logs into the ec2 instance they're going to get an animal themed welcome so use control o to save that file and control x to exit clear the screen to make it easier to see we're going to make sure that file that we've just edited has the correct permissions then we're going to force an update of the message of the day so this is going to be what's displayed when anyone logs into this instance and then finally now that we've completed this configuration we're going to reboot this ec2 instance so we're going to use this command to reboot it and just to illustrate how this works I'm going to close down that tab and return to the ec2 console give this a few moments to restart that should have rebooted by now so we're going to select it right click go to connect again use ec2 instance connect assuming everything's working now when we connect to the instance we'll see an animal themed login banner so this is just a nice way that we can ensure that anyone logging into this instance understands that a he uses the Amazon Linux 2 AMI and be that it belongs to animals for life so we've created this instance using the Amazon Linux 2 AMI we've performed the WordPress installation and initial configuration we've customized the banner and now we're going to use this as our template instance to create our AMI that can then be used to launch other instances okay so this is the end of part one of this lesson it was getting a little bit on the long side and so I wanted to add a break it's an opportunity just to take a rest or grab a coffee part 2 will be continuing immediately from the end of part one so go ahead complete the video and when you're ready join me in part two

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

So this is the folder containing the WordPress installation files.

Now there's one particular file that's really important, and that's the configuration file.

So there's a file called WP-config-sample, and this is actually the file that contains a template of the configuration items for WordPress.

So what we need to do is to take this template and change the file name to be the proper file name, so wp-config.php.

So we're going to create a copy of this file with the correct name.

And to do that, we run this command.

So we're copying the template or the sample file to its real file name, so wp-config.php.

And this is the name that WordPress expects when it initially loads its configuration information.

So run that command, and that now means that we have a live config file.

Now this command isn't in the instructions, but if I just take a moment to open up this file, you don't need to do this.

I'm just demonstrating what's in this file for your benefit.

But if I run a sudo nano, and then wp, and then hyphen-config, and then php, this is how the file looks.

So this has got all the configuration information in.

So it stores the database name, the database user, the database host, and lots of other information.

Now notice how it has some placeholders.

So this is where we would need to replace the placeholders with the actual configuration information.

So the database name itself, the host name, the database username, the database password, all that information would need to be replaced.

Now we're not going to type this in manually, so I'm going to control X to exit out of this, and then clear the screen again to make it easy to see.

We're going to use the Linux utility sed, or S-E-D.

And this is a utility which can perform a search and replace within a text file.

It's actually much more complex and capable than that.

It can perform many different manipulation operations.

But for this demonstration, we're going to use it as a simple search and replace.

Now we're going to do this a number of times.

First, we're going to run this command, which is going to replace this placeholder.

Remember, this is one of the placeholders inside the configuration file that I've just demonstrated, wp-config.

We're going to replace the placeholder here with the contents of the variable name, dbname, that we set at the start of this demo.

So this is going to replace the placeholder with our actual database name.

So I'm going to enter that so you can do the same.

We're going to run the sed command again, but this time it's going to replace the username placeholder with the dbuser variable that we set at the start of this demo.

So use that command as well.

And then lastly, it will do the same for the database password.

So type or copy and paste this command and press enter.

And that now means that this wp-config has the actual configuration information inside.

And just to demonstrate that, you don't need to do this part.

I'll just do it to demonstrate.

If I edit this file again, you'll see that all of these placeholders have actually been replaced with actual values.

So I'm going to control X out of that and then clear the screen.

And that concludes the configuration for the WordPress application.

So now it's ready.

Now it knows how to communicate with the database.

What we need to do to finish off the configuration though is just to make sure that the web server has access to all of the files within this folder.

And to do that, we use this command.

So we're making sure that we use the shown command or chown and set the ownership of all of the files in this folder and any subfolders to be the Apache user and the Apache group.

And the Apache user and Apache group belong to the web server.

So this just makes sure that the web server is able to access and control all of the files in the web root folder.

So run that command and press enter.

And that concludes the installation part of the WordPress application.

There's one final thing that we need to do and that's to create the database that WordPress will use.

So I'm going to clear the screen to make it easy to see.

Now what we're going to do in order to configure the database is we're going to make a database setup script.

We're going to put this script inside the forward slash TMP folder and we're going to call it DB.setup.

So what we need to do is enter the commands into this file that will create the database.

After the database is created, it needs to create a database user and then it needs to grant that user permissions on that database.

Now again, instead of manually entering this, we're going to use those variable names that were created at the start of the demo.

So we're going to run a number of commands.

These are all in the lessons commands document.

The first one is this.

So this echoes this text and because it has a variable name in, this variable name will be replaced by the actual contents of the variable.

Then it's going to take this text with the replacement of the contents of this variable and it's going to enter that into this file.

So forward slash TMP, forward slash DB setup.

So run that and that command is going to create the WordPress database.

Then we're going to use this command and this is the same so it echoes this text but it replaces these variable names with the contents of the variables.

This is going to create our WordPress database user.

It's going to set its password and then it's going to append this text to the DB setup file that we're creating.

Now all of these are actually database commands that we're going to execute within the MariaDB database.

So enter that to add that line to DB.setup.

Then we have another line which uses the same architecture as the ones above it.

It echoes the text.

It replaces these variable names with the contents and then outputs that to this DB.setup file and this command grants our database user permissions to our WordPress database.

And then the last command is this one which just flushes the privileges and again we're going to add this to our DB.setup script.

So now I'm just going to cat the contents of this file so you can just see exactly what it looks like.

So cat and then space forward slash TMP, forward slash DB.setup.

So as you'll see it's replaced all of these variable names with the actual contents.

So this is what the contents of this script actually looks like.

So these are commands which will be run by the MariaDB database platform.

To run those commands we use this.

So this is the MySQL command line interface.

So we're using MySQL to connect to the MariaDB database server.

We're using the username of root.

We're passing in the password and then using the contents of the DB root password variable.

And then once we authenticate the database we're passing in the contents of our DB.setup script.

And so this means that all of the lines of our DB.setup script will be run by the MariaDB database and this will create the WordPress database, the WordPress user and configure all of the required permissions.

So go ahead and press enter.

That command is run by the MariaDB platform and that means that our WordPress database has been successfully configured.

And then lastly just to keep things secure because we don't want to leave files laying around on the file system with authentication information inside.

We're just going to run this command to delete this DB.setup file.

Okay, so that concludes the setup process for WordPress.

It's been a fairly long intensive process but that now means that we have an installation of WordPress on this EC2 instance, a database which has been installed and configured.

So now what we can do is to go back to the AWS console, click on instances.

We need to select the A4L-PublicEC2 and then we need to locate its IP address.

Now make sure that you don't use this open address link because this will attempt to open the IP address using HTTPS and we don't have that configured on this WordPress instance.

Instead, just copy the IP address into your clipboard and then open that in a new tab.

If everything's successful, you should see the WordPress installation dialog and just to verify this is working successfully, let's follow this process through.

So pick English, United States for the language.

For the blog title, just put all the cats and then admin as the username.

You can accept the default strong password.

Just copy that into your clipboard so we can use it to log in in a second and then just go ahead and enter your email.

It doesn't have to be a correct one.

So I normally use test@test.com and then go ahead and click on install WordPress.

You should see a success dialog.

Go ahead and click on login.

Username will be admin, the password that you just copied into your clipboard and then click on login.

And there you go.

We've got a working WordPress installation.

We're not going to configure it in any detail but if you want to just check out that it works properly, go ahead and click on this all the cats at the top and then visit site and you'll be able to see a generic WordPress blog.

And that means you've completed the installation of the WordPress application and the database using a monolithic architecture on a single EC2 instance.

So this has been a slow process.

It's been manual and it's a process which is wide open for mistakes to be made at every point throughout that process.

Can you imagine doing this twice?

What about 10 times?

What about a hundred times?

It gets pretty annoying pretty quickly.

In reality, this is never done manually.

We use automation or infrastructure as code systems such as cloud formation.

And as we move through the course, you're going to get experience of using all of these different methods.

Now that we're close to finishing up the basics of VPC and EC2 within the course, things will start to get much more efficient quickly because I'm going to start showing you how to use many of the automation and infrastructure as code services within AWS.

And these are really awesome to use.

And you'll see just how much power is granted to an architect, a developer, or an engineer by using these services.

For now though, that is the end of this demo lesson.

Now what we're going to do is to clear up our account.

So we need to go ahead and clear all of this infrastructure that we've used throughout this demo lesson.

To do that, just move back to the AWS console.

If you still have the cloud formation tab open and move back to that tab, otherwise click on services and then click on cloud formation.

If you don't see it anywhere, you can use this box to search for it, select the word, press stack, select delete, and then confirm that deletion.

And that will delete the stack, clear up all of the infrastructure that we've used throughout this demo lesson and the account will now be in the same state as it was at the start of this lesson.

So from this point onward in the course, we're going to start using automation.

Now there is a lesson coming up in a little while in this section of the course, where you're going to create an Amazon machine image which is going to contain a pre-baked copy of the WordPress application.

So as part of that lesson, you are going to be required to perform one more manual installation of WordPress, but that's going to be part of automating the installation.

So you'll start to get some experience of how to actually perform automated installations and how to design architectures which have WordPress as a component.

At this point though, that's everything I wanted to cover.

So go ahead, complete this video, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson we're going to be doing something which I really hate doing and that's using WordPress in a course as an example.

Joking aside though WordPress is used in a lot of courses as a very simple example of an application stack.

The problem is that most courses don't take this any further.

But in this course I want to use it as one example of how an application stack can be evolved to take advantage of AWS products and services.

What we're going to be using WordPress for in this demo is to give you experience of how a manual installation of a typical application stack works in EC2.

We're going to be doing this so you can get the experience of how not to do things.

My personal belief is that to fully understand the advantages that automation features within AWS provide, you need to understand what a manual installation is like and what problems you can experience doing that manual installation.

As we move through the course we can compare this to various different automated ways of installing software within AWS.

So you're going to get the experience of bad practices, good practices and the experience to be able to compare and contrast between the two.

By the end of this demonstration you're going to have a working WordPress site but it won't have any high availability because it's running on a single EC2 instance.

It's going to be architecturally monolithic with everything running on the one single instance.

In this case that means both the application and the database.

The design is fairly straightforward.

It's just the Animals for Life VPC.

We're going to be deploying the WordPress application into a single subnet, the WebA public subnet.

So this subnet is going to have a single EC2 instance deployed into it and then you're going to be doing a manual install onto this instance and the end result is a working WordPress installation.

At this point it's time to get started and implement this architecture.

So let's go ahead and switch over to our AWS console.

To get started with this demo lesson you're going to need to do a few preparation steps.

First just make sure that you're logged in to the general AWS account, so the management account of the organization and as always make sure you have the Northern Virginia region selected.

Now attached to this lesson is a one-click deployment for the base infrastructure that we're going to use.

So go ahead and open the one-click deployment link that's attached to this lesson.

That link is going to take you to the Quick Create Stack screen.

Everything should be pre-populated.

The stack name should be WordPress.

All you need to do is scroll down towards the bottom, check this capabilities box and then click on Create Stack.

And this stack is going to need to be in a Create Complete state before we move on with the demo lesson.

So go ahead and pause this video, wait for the stack to change to Create Complete and then we're good to continue.

Also attached to this lesson is a Lessons Command document which lists all of the commands that you'll be using within the EC2 instance throughout this demo lesson.

So go ahead and open that as well.

So that should look something like this and these are all of the commands that we're going to be using.

So these are the commands that perform a manual WordPress installation.

Now that that stack's completed and we've got the Lesson Commands document open, the next step is to move across to the EC2 console because we're going to actually install WordPress manually.

So click on the Services drop-down and then locate EC2 in this All Services part of the screen.

If you've recently visited it, it should be in the Recently Visited section under Favorites or you can go ahead and type EC2 in the search box and then open that in a new tab.

And then click on Instances running and you should see one single instance which is called A4L-PublicEC2.

Go ahead and right-click on this instance.

This is the instance we'll be installing WordPress within.

So right-click, select Connect.

We're going to be using our browser to connect to this instance so we'll be using Instance Connect just verify that the username is EC2-user and then go ahead and connect to this instance.

Now again, I fully understand that a manual installation of WordPress might seem like a waste of time but I genuinely believe that you need to understand all the problems that come from manually installing software in order to understand the benefits which automation provides.

It's not just about saving time and effort.

It's also about error reduction and the ability to keep things consistent.

Now I always like to start my installations or my scripts by setting variables which will store the configuration values that everything from that point forward will use.

So we're going to create four variables.

One for the database name, one for the database user, one for the database password and then one for the root or admin password of the database server.

So let's start off by using the pre-populated values from the Lessened Commands documents.

So that's all of those variables set and we can confirm that those are working by typing echo and then a space and then a dollar and then the name of one of those variables.

So for example, dbname and press Enter and that will show us the value stored within that variable.

So now we can use these later points of the installation.

So at this point I'm going to clear the screen to keep it easy to see and stage two at this installation process is to install some system software.

So there are a few things that we need to install in order to allow a WordPress installation.

We'll install those using the DNF package manager.

We need to give it admin privileges which is why we use shudu and then the packages that we're going to install are the database server which is Maria db-server the Apache web server which is HTTPD and then a utility called Wget which we're going to use to download further components of the installation.

So go ahead and type or copy and paste that command and press Enter and that installation process will take a few moments and it will go through installing that software and any of the prerequisites.

They're done so I'll clear the screen to keep this easy to read.

Now that all those packages are installed we need to start both the web server and the database server and ensure that both of them are started if ever the machine is restarted.

So to do that we need to enable and start those services.

So enabling and starting means that both of the services are both started right now and they'll start if the machine reboots.

So first we'll use this command.

So we're using admin privileges again, systemctl which allows us to start and stop system processes and then we use enable and then HTTPD which is the web server.

So type and press enter and that ensures that the web server is enabled.

We need to run the same command again but this time specifying MariaDB to ensure that the database server is enabled.

So type or copy and paste and press enter.

So that means both of those processes will start if ever the instance is rebooted and now we need to manually start both of those so they're running and we can interact with them.

So we need to use the same structure of command but instead of enable we need to start both of these processes.

So first the web server and then the database server.

So that means the CC2 instance now has a running web and database server both of which are required for WordPress.

So I'll clear the screen to keep this easy to read.

Next we're going to move to stage 4 and stage 4 is that we need to set the root password of the database server.

So this is the username and password that will be used to perform all of the initial configuration of the database server.

Now we're going to use this command and you'll note that for password we're actually specifying one of the variables that we configured at the start of this demo.

So we're using the DB root password variable that we configured right at the start.

So go ahead and copy and paste or type that in and press enter and that sets the password for the root user of this database platform.

The next step which is step 5 is to install the WordPress application files.

Now to do that we need to install these files inside what's known as the web root.

So whenever you browse to a web server either using an IP address or a DNS name if you don't specify a path so if you just use the server name for example netflix.com then it loads those initial files from a folder known as the web root.

Now on this particular server the web root is stored in /varr/www/html so we need to download WordPress into that folder.

Now we're going to use this command Wget and that's one of the packages that we installed at the start of this lesson.

So we're giving it admin privileges and we're using Wget to download latest.tar.gz from wordpress.org and then we're putting it inside this web root.

So /varr/www/html.

So go ahead and copy and paste or type that in and press enter.

That'll take a few moments depending on the speed of the WordPress servers and that will store latest.tar.gz in that web root folder.

Next we need to move into that folder so cd space /varr/www/html and press enter.

We need to use a Linux utility called tar to extract that file.

So sudo and then tar and then the command line options -zxvf and then the name of the file so latest.tar.gz So copy and paste or type that in and press enter and that will extract the WordPress download into this folder.

So now if we do an ls -la you'll see that we have a WordPress folder and inside that folder are all of the application files.

Now we actually don't want them inside a WordPress folder.

We want them directly inside the web root.

So the next thing we're going to do is this command and this is going to copy all of the files from inside this WordPress folder to . and . represents the current folder.

So it's going to copy everything inside WordPress into the current working directory which is the web root directory.

So enter that and that copies all of those files.

And now if we do another listing you'll see that we have all of the WordPress application files inside the web root.

And then lastly for the installation part we need to tidy up the mess that we've made.

So we need to delete this WordPress folder and the download file that we just created.

So to do that we'll run an rm -r and then WordPress to delete that folder.

And then we'll delete the download with sudo rm and then a space and then the name of the file.

So latest.tar.gz.

And that means that we have a nice clean folder.

So I'll clear the screen to make it easy to see.

And then I'll just do another listing.

Okay so this is the end of part one of this lesson.

It was getting a little bit on the long side and so I wanted to add a break.

It's an opportunity just to take a rest or grab a coffee.

Part two will be continuing immediately from the end of part one.

So go ahead complete the video and when you're ready join me in part two.

Welcome back and in this video we're going to interact with instant store volumes.

Now this part of the demo does come at a cost.

This isn't inside the free tier because we're going to be launching some instances which are fairly large and are not included in the free tier.

The demo has a cost of approximately 13 cents per hour and so you should only do this part of the demo if you're willing to accept that cost.

If you don't want to accept those costs then you can go ahead and watch me perform these within my test environment.

So to do this we're going to go ahead and click on instances and we're going to launch an instance manually.

So I'm going to click on launch instances.

We're going to name the instance, Instance Store Test so put that in the name box.

Then scroll down, pick Amazon Linux, make sure Amazon Linux 2023 is selected and the architecture needs to be 64 bit x86.

Scroll down and then in the instance type box click and we need to find a different type of instance.

This is going to be one that supports instance store volumes.

So scroll down and we're looking for m5dn.large.

This is a type of instance which includes one instance store volume.

So select that then scroll down a little bit more and under key pair click in the box and select proceed without a key pair not recommended.

Scroll down again and under network settings click on edit.

Click in the VPC drop down and select a4l-vpc1.

Under subnet make sure sn-web-a is selected.

Make sure enabled is selected for both of the auto assign public IP drop downs.

Then we're going to select an existing security group click the drop down select the EBS demo instance security group.

It will have some random after it but that's okay.

Then scroll down and under storage we're going to leave all of the defaults.

What you are able to do though is to click on show details next to instance store volumes.

This will show you the instance store volumes which are included with this instance.

You can see that we have one instance store volume it's 75 GB in size and it has a slightly different device name.

So dev nvme0n1.

Now all of that looks good so we're just going to go ahead and click on launch instance.

Then click on view all instances and initially it will be an appending state and eventually it will move into a running state.

Then we should probably wait for the status check column to change from initializing to 2 out of 2.

Go ahead and pause the video and wait for this status check to change to be fully green.

It should show 2 out of 2 status checks.

That's now in a running state with 2 out of 2 checks so we can go ahead and connect to this instance.

Before we do though just go ahead and select the instance and just note the instances public IP version 4 address.

Now this address is really useful because it will change if the EC2 instance moves between EC2 hosts.

So it's a really easy way that we can verify whether this instance has moved between EC2 hosts.

So just go ahead and note down the IP address of the instance that you have if you're performing this in your own environment.

We're going to go ahead and connect to this instance though so right click, select connect, we'll be choosing instance connect, go ahead and connect to the instance.

Now many of these commands that we'll be using should by now be familiar.

Just refer back to the lessons command document if you're unsure because we'll be using all of the same commands.

First we need to list all of the block devices which are attached to this instance and we can do that with LSBLK.

This time it looks a little bit different because we're using instance store rather than EBS additional volumes.

So in this particular case I want you to look for the 8G volume so this is the root volume.

This represents the boot or root volume of the instance.

Remember that this particular instance type came with a 75GB instance store volume so we can easily identify it's this one.

Now to check that we can verify whether there's a file system on this instance store volume.

If we run this command, so the same command we've used previously so shudu file -s and then the id of this volume so dev nvme1n1, you'll see it reports data.

And if you recall from the previous parts of this demo series this indicates that there isn't a file system on this volume.

We're going to create one and to do that we use this command again it's the same command that we've used previously just with the new volume id.

So press enter to create a file system on this raw block device this instance store volume and then we can run this command again to verify that it now has a file system.

To mount it we can follow the same process that we did in the earlier stages of this demo series.

We'll need to create a directory for this volume to be mounted into this time we'll call it forward slash instance store.

So create that folder and then we're going to mount this device into that folder so shudu mount then the device id and then the mount point or the folder that we've previously created.

So press enter and that means that this block device this instance store volume is now mounted into this folder.

And if we run a df space -k and press enter you can see that it's now mounted.

Now we're going to move into that folder by typing cd space forward slash instance store and to keep things efficient we're going to create a file called instance store dot txt.

And rather than using an editor we'll just use shudu touch and then the name of the file and this will create an empty file.

If we do an LS space -la and press enter you can see that that file exists.

So now that we have this file stored on a file system which is running on this instance store volume let's go ahead and reboot this instance.

Now we need to be careful we're not going to stop and start the instance we're going to restart the instance.

Restarting is different than stop and start.

So to do that we're going to close this tab move back to the ec2 console so click on instances right click on instance store test and select reboot instance and then confirm that.

Note what this IP address is before you initiate the reboot operation and then just give this a few minutes to reboot.

Then right click and select connect.

Using instance connect go ahead and connect back to the instance.

And again if it appears to hang at this point then you can just wait for a few moments and then connect again.

But in this case I've left it long enough and I'm connected back into the instance.

Now once I'm back in the instance if I run a df space -k and press enter note how that file system is not mounted after the reboot.

Now that's fine because we didn't configure the Linux operating system to mount this file system when the instance is restarted.

But what we can do is do an LS BLK again to list the block device.

We can see that it's still there and we can manually mount it back in the same folder as it was before the reboot.

To do that we run this command.

So it's mounting the same volume ID the same device ID into the same folder.

So go ahead and run that command and press enter.

Then if we use cd space forward slash and then instance store press enter and then do an LS space -la we can see that this file is still there.

Now the file is still there because instance store volumes do persist through the restart of an EC2 instance.

Restarting an EC2 instance does not move the instance from one EC2 host to another.

And because instance store volumes are directly attached to an EC2 host this means that the volume is still there after the machine has restarted.

Now we're going to do something different though.

Close this tab down.

Move back to instances.

Again pay special attention to this IP address.

Now we're going to right click and stop the instance.

So go ahead and do that and confirm it if you're doing this in your own environment.

Watch this public IP v4 address really carefully.

We'll need to wait for the instance to move into a stopped state which it has and if we select the instance note how the public IP version for address has been unallocated.

So this instance is now not running on an EC2 host.

Let's right click.

Go to start instance and start it up again.

Only to give that a few moments again.

It'll move into a running state but notice how the public IP version for address has changed.

This is a good indication that the instance has moved from one EC2 host to another.

So let's give this instance a few moments to start up.

And once it has right click, select connect and then go ahead and connect to the instance using instance connect.

Once connected go ahead and run an LS BLK and press enter and you'll see it appears to have the same instance store volume attached to this instance.

It's using the same ID and it's the same size.

But let's go ahead and verify the contents of this device using this command.

So shudu file space -s space and then the device ID of the instance store volume.

For press enter, now note how it shows data.

So even though we created a file system in the previous step after we've stopped and started the instance, it appears this instance store volume has no data.

Now the reason for that is when you restart an EC2 instance, it restarts on the same EC2 host.

But when you stop and start an EC2 instance, which is a distinctly different operation, the EC2 instance moves from one EC2 host to another.

And that means that it has access to completely different instance store volumes than it did on that previous host.

It means that all of the data, so the file system and the test file that we created on the instance store volume, before we stopped and started this instance, all of that is lost.

When you stop and start an EC2 instance or for any other reason, which means the instance moves from one host to another, all of the data is lost.

So instance store volumes are ephemeral.

They're not persistent and you can't rely on them to keep your data safe.

And it's really important that you understand that distinction.

If you're doing the developer or sysop streams, it's also important that you understand the difference between an instance restart, which keeps the same EC2 host, and a stop and start, which moves an instance from one host to another.

The format means you're likely to keep your data, but the latter means you're guaranteed to lose your data when using instance store volumes.

EBS on the other hand, as we've seen, is persistent and any data persists through the lifecycle of an EC2 instance.

Now with that being said, though, that's everything that I wanted to demonstrate within this series of demo lessons.

So let's go ahead and tidy up the infrastructure.

Close down this tab, click on instances.

If you follow this last part of the demo in your own environment, go ahead and right click on the instance store test instance and terminate that instance.

That will delete it along with any associated resources.

We'll need to wait for this instance to move into the terminated state.

So give that a few moments.

Once that's terminated, go ahead and click on services and then move back to the cloud formation console.

You'll see the stack that you created using the one click deploy at the start of this lesson.

Go ahead and select that stack, click on delete and then delete stack.

And that's going to put the account back in the same state as it was at the start of this lesson.

So it will remove all of the resources that have been created.

And at that point, that's the end of this demo series.

So what did you learn?

You learned that EBS volumes are created within one specific availability zone.

EBS volumes can be mounted to instances in that availability zone only and can be moved between instances while retaining their data.

You can create a snapshot from an EBS volume which is stored in S3 and that data is replicated within the region.

And then you can use snapshots to create volumes in different availability zones.

I told you how snapshots can be copied to other AWS regions either as part of data migration or disaster recovery and you learned that EBS is persistent.

You've also seen in this part of the demo series that instant store volumes can be used.

They are included with many instance types but if the instance moves between EC2 hosts so if an instance is stopped and then started or if an EC2 host has hardware problems then that EC2 instance will be moved between hosts and any data on any instant store volumes will be lost.

So that's everything that you needed to know in this demo lesson and you're going to learn much more about EC2 and EBS in other lessons throughout the course.

At this point though, thanks for watching and doing this demo.

I hope it was useful but go ahead complete this video and when you're ready I look forward to you joining me in the next.

Welcome back and we're going to use this demo lesson to get some experience of working with EBS and Instant Store volumes.

Now before we get started, this series of demo videos will be split into two main components.

The first component will be based around EBS and EBS snapshots and all of this will come under the free tier.

The second component will be based on Instant Store volumes and will be using larger instances which are not included within the free tier.

So I'm going to make you aware of when we move on to a part which could incur some costs and you can either do that within your own environment or watch me do it in the video.

If you do decide to do it in your own environment, just be aware that there will be a 13 cents per hour cost for the second component of this demo series and I'll make it very clear when we move into that component.

The second component is entirely optional but I just wanted to warn you of the potential cost in advance.

Now to get started with this demo, you're going to need to deploy some infrastructure.

To do that, make sure that you're logged in to the general account, so the management account of the organization and you've got the Northern Virginia region selected.

Now attached to this demo is a one click deployment link to deploy the infrastructure.

So go ahead and click on that link.

That's going to open this quick create stack screen and all you need to do is scroll down to the bottom, check this capabilities box and click on create stack.

Now you're going to need this to be in a create complete state before you continue with this demo.

So go ahead and pause the video, wait for that stack to move into the create complete status and then you can continue.

Okay, now that's finished and the stack is in a create complete state.

You're also going to be running some commands within EC2 instances as part of this demo.

Also attached to this lesson is a lesson commands document which contains all of those commands and you can use this to copy and paste which will avoid errors.

So go ahead and open that link in a separate browser window or separate browser tab.

It should look something like this and we're going to be using this throughout the lesson.

Now this cloud formation template has created a number of resources, but the three that we're concerned about are the three EC2 instances.

So instance one, instance two and instance three.

So the next thing to do is to move across to the EC2 console.

So click on the services drop down and then either locate EC2 under all services, find it in recently visited services or you can use the search box at the top type EC2 and then open that in a new tab.

Now the EC2 console is going through a number of changes so don't be alarmed if it looks slightly different or if you see any banners welcoming you to this new version.

Now if you click on instances running, you'll see a list of the three instances that we're going to be using within this demo lesson.

We have instance one - az a.

We have instance two - az a and then instance one - az b.

So these are three instances, two of which are in availability zone A and one which is in availability zone B.

Next I want you to scroll down and locate volumes under elastic block store and just click on volumes.

And what you'll see is three EBS volumes, each of which is eight GIB in size.

Now these are all currently in use.

You can see that in the state column and that's because all of these volumes are in use as the boot volumes for those three EC2 instances.

So on each of these volumes is the operating system running on those EC2 instances.

Now to give you some experience of working with EBS volumes, we're going to go ahead and create a volume.

So click on the create volume button.

The first thing you'll need to do when creating a volume is pick the type and there are a number of different types available.

We've got GP2 and GP3 which are the general purpose storage types.

We're going to use GP3 for this demo lesson.

You could also select one of the provisioned IOPS volumes.

So this is currently IO1 or IO2.

And with both of these volume types, you're able to define IOPS separately from the size of the volume.

So these are volume types that you can use for demanding storage scenarios where you need high-end performance or when you need especially high performance for smaller volume sizes.

Now IO1 was the first type of provisioned IOPS SSD introduced by AWS and more recently they've introduced IO2 and enhanced it which provides even higher levels of performance.

In addition to that we do have the non-SSD volume types.

So SC1 which is cold HDD, ST1 which is throughput optimized HDD and then of course the original magnetic type which is now legacy and AWS don't recommend this for any production usage.

For this demo lesson we're going to go ahead and select GP3.

So select that.

Next you're able to pick a size in GIB for the volume.

We're going to select a volume size of 10 GIB.

Now EBS volumes are created within a specific availability zone so you have to select the availability zone when you're creating the volume.

At this point I want you to go ahead and select US-EAST-1A.

When creating volume you're also able to specify a snapshot as the basis for that volume.

So if you want to restore a snapshot into this volume you can select that here.

At this stage in the demo we're going to be creating a blank EBS volume so we're not going to select anything in this box.

We're going to be talking about encryption later in this section of the course.

You are able to specify encryption settings for the volume when you create it but at this point we're not going to encrypt this volume.

We do want to add a tag so that we can easily identify the volume from all of the others so click on add tag.

For the key we're going to use name.

For the value we're going to put EBS test volume.

So once you've entered both of those go ahead and click on create volume and that will begin the process of creating the volume.

Just close down any dialogues and then just pay attention to the different states that this volume goes through.

It begins in a creating state.

This is where the storage is being provisioned and then made available by the EBS product.

If we click on refresh you'll see that it changes from creating to available and once it's in an available state this means that we can attach it to EC2 instances.

And that's what we're going to do so we're going to right click and select attach volume.

Now you're able to attach this volume to EC2 instances but crucially only those in the same availability zone.

EBS is an availability zone scoped service and so you can only attach EBS volumes to EC2 instances within that same availability zone.

So if we select the instance box you'll only see instances in that same availability zone.

Now at this point go ahead and select instance 1 in availability zone A.

Once you've selected it you'll see that the device field is populated and this is the device ID that the instance will see for this volume.

So this is how the volume is going to be exposed to the EC2 instance.

So if we want to interact with this instance inside the operating system this is the device that we'll use.

Now different operating systems might see this in slightly different ways.

So as this warning suggests certain Linux kernels might rename SDF to XVDF.

So we've got to be aware that when you do attach a volume to an EC2 instance you need to get used to how that's seen inside the operating system.

How we can identify it and how we can configure it within the operating system for use.

And I'm going to demonstrate that in the next part of this demo lesson.

So at this point just go ahead and click on attach and this will attach this volume to the EC2 instance.

Once that's attached to the instance and you see the state change to in use then just scroll up on the left hand side and select instances.

We're going to go ahead and connect to instance 1 in availability zone A.

This is the instance that we just attached that EBS volume to so we want to interact with this instance and see how we can see the EBS volume.

So right click on this instance and select connect and then you could either connect with an SSH client or use instance connect and to keep things simple we're going to connect from our browser so select the EC2 instance connect option make sure the user's name is set to EC2-user and then click on connect.

So now we connected to this EC2 instance and it's at this point that we'll start needing the commands that are listed inside the lesson commands document and again this is attached to this lesson.

So first we need to list all the block devices which are connected to this instance and we're going to use the LSBLK command.

Now if you're not comfortable with Linux don't worry just take this nice and slowly and understand at a high level all the commands that we're going to run.

So the first one is LSBLK and this is list block devices.

So if we run this we'll be able to see a list of all of the block devices connected to this EC2 instance.

You'll see the root device this is the device that's used to boot the instance it contains the instance operating system you'll see that it's 8 gig in size and then this is the EBS volume that we just attached to this instance.

You'll see that device ID so XVDF and you'll see that it's 10 gig in size.

Now what we need to do next is check whether there is a file system on this block device.

So this block device we've created it with EBS and then we've attached it to this instance.

Now we know that it's blank but it's always safe to check if there's any file system on a block device.

So to do that we run this command.

So we're going to check are there any file systems on this block device.

So press enter and if you see just data that indicates that there isn't any file system on this device and so we need to create one.

You can only mount file systems under Linux and so we need to create a file system on this raw block device this EBS volume.

So to do that we run this command.

So shoo-doo again is just giving us admin permissions on this instance.

MKFS is going to make a file system.

We specify the file system type with hyphen t and then XFS which is a type of file system and then we're telling it to create this file system on this raw block device which is the EBS volume that we just attached.

So press enter and that will create the file system on this EBS volume.

We can confirm that by rerunning this previous command and this time instead of data it will tell us that there is now an XFS file system on this block device.

So now we can see the difference.

Initially it just told us that there was data, so raw data on this volume and now it's indicating that there is a file system, the file system that we just created.

Now the way that Linux works is we mount a file system to a mount point which is a directory.

So we're going to create a directory using this command.

MKDIR makes a directory and we're going to call the directory forward slash EBS test.

So this creates it at the top level of the file system.

This signifies root which is the top level of the file system tree and we're going to make a folder inside here called EBS test.

So go ahead and enter that command and press enter and that creates that folder and then what we can do is to mount the file system that we just created on this EBS volume into that folder.

And to do that we use this command, mount.

So mount takes a device ID, so forward slash dev forward slash xvdf.

So this is the raw block device containing the file system we just created and it's going to mount it into this folder.

So type that command and press enter and now we have our EBS volume with our file system mounted into this folder.

And we can verify that by running a df space hyphen k.

And this will show us all of the file systems on this instance and the bottom line here is the one that we've just created and mounted.

At this point I'm just going to clear the screen to make it easier to see and what we're going to do is to move into this folder.

So cd which is change directory space forward slash EBS test and then press enter and that will move you into that folder.

Once we're in that folder we're going to create a test file.

So we're going to use this command so shudu nano which is a text editor and we're going to call the file amazing test file dot txt.

So type that command in and press enter and then go ahead and type a message.

It can be anything you just need to recognize it as your own message.

So I'm going to use cats are amazing and then some exclamation marks.

Then I'm going to press control o and enter to save that file and then control x to exit again clear the screen to make it easier to see.

And then I'm going to do an LS space hyphen LA and press enter just to list the contents of this folder.

So as you can see we've now got this amazing test file dot txt.

And if we cat the contents of this so cat amazing test file dot txt you'll see the unique message that you just typed in.

So at this point we've created this file within the folder and remember the folder is now the mount point for the file system that we created on this EBS volume.

So the next step that I want you to do is to reboot this EC2 instance.

To do that type sudo space and then reboot and press enter.

Now this will disconnect you from this session.

So you can go ahead and close down this tab and go back to the EC2 console.

Just go ahead and click on instances.

Okay, so this is the end of part one of this lesson.

It was getting a little bit on the long side and so I wanted to add a break.

It's an opportunity just to take a rest or grab a coffee.

Part two will be continuing immediately from the end of part one.

So go ahead complete the video and when you're ready join me in part two.

Welcome back and in this demo lesson you're going to evolve the infrastructure which you've been using throughout this section of the course.

In this demo lesson you're going to add private internet access capability using NAT gateways.

So you're going to be applying a cloud formation template which creates this base infrastructure.

It's going to be the animals for life VPC with infrastructure in each of three availability zones.

So there's a database subnet, an application subnet and a web subnet in availability zone A, B and C.

Now to this point what you've done is configured public subnet internet access and you've done that using an internet gateway together with routes on these public subnets.

In this demo lesson you're going to add NAT gateways into each availability zone so A, B and C and this will allow this private EC2 instance to have access to the internet.

Now you're going to be deploying NAT gateways into each availability zone so that each availability zone has its own isolated private subnet access to the internet.

It means that if any of the availability zones fail then each of the others will continue operating because these route tables which are attached to the private subnets they point at the NAT gateway within that availability zone.

So each availability zone A, B and C has its own corresponding NAT gateway which provides private internet access to all of the private subnets within that availability zone.

Now in order to implement this infrastructure you're going to be applying a one-click deployment and that's going to create everything that you see on screen now apart from these NAT gateways and the route table configurations.

So let's go ahead and move across to our AWS console and get started implementing this architecture.

Okay so now we're at the AWS console as always just make sure that you're logged in to the general AWS account as the I am admin user and you'll need to have the Northern Virginia region selected.

Now at the end of the previous demo lesson you should have deleted all of the infrastructure that you've created up until that point so the animals for live VPC as well as the Bastion host and the associated networking.

So you should have a relatively clean AWS account.

So what we're going to do first is use a one-click deployment to create the infrastructure that we'll need within this demo lesson.

So attached to this demo lesson is a one-click deployment link so go ahead and open that link.

That's going to take you to a quick create stack screen.

Everything should be pre-populated the stack name should be a4l just scroll down to the bottom check this capabilities box and then click on create stack.

Now this will start the creation process of this a4l stack and we will need this to be in a create complete state before we continue.

So go ahead pause the video wait for your stack to change into create complete and then we good to continue.

Okay so now this stacks moved into a create complete state then we good to continue.

So what we need to do before we start is make sure that all of our infrastructure has finished provisioning.

To do that just go ahead and click on the resources tab of this cloud formation stack and look for a4l internal test.

This is an EC2 instance a private EC2 instance so this doesn't have any public internet connectivity and we're going to use this to test on that gateway functionality.

So go ahead and click on this icon under physical ID and this is going to move you to the EC2 console and you'll be able to see this a4l - internal - test instance.

Now currently in my case it's showing as running but the status check is showing as initializing.

Now we'll need this instance to finish provisioning before we can continue with the demo.

What should happen is this status check should change from initializing to two out of two status checks and once you're at that point you should be able to right click and select connect and choose session manager and then have the option of connecting.

Now you'll see that I don't because this instance hasn't finished its provisioning process.

So what I want you to do is to go ahead and pause this video wait for your status checks to change to two out of two checks and then just go ahead and try to connect to this instance using session manager.

Only resume the video once you've been able to click on connect under the session manager tab and don't worry if this takes a few more minutes after the instance finishes provisioning before you can connect to session manager.

So go ahead and pause the video and when you can connect to the instance you're good to continue.

Okay so in my case it took about five minutes for this to change to two out of two checks past and then another five minutes before I could connect to this EC2 instance.

So I can right click on here and put connect.

I'll have the option now of picking session manager and then I can click on connect and this will connect me in to this private EC2 instance.

Now the reason why you're able to connect to this private instance is because we're using session manager and I'll explain exactly how this product works elsewhere in the course but essentially it allows us to connect into an EC2 instance with no public internet connectivity and it's using VPC interface endpoints to do that which I'll be explaining elsewhere in the course but what you should find when you're connected to this instance if you try to ping any internet IP address so let's go ahead and type ping and then a space 1.1.1.1.1 and press enter you'll note that we don't have any public internet connectivity and that's because this instance doesn't have a public IP version for address and it's not in a subnet with a route table which points at the internet gateway.

This EC2 instance has been deployed into the application a subnet which is a private subnet and it also doesn't have a public IP version for address.

So at this point what we need to do is go ahead and deploy our NAT gateways and these NAT gateways are what will provide this private EC2 instance with connectivity to the public IP version for internet so let's go ahead and do that.

Now to do that we need to be back at the main AWS console click in the services search box at the top type VPC and then right click and open that in a new tab.

Once you do that go ahead and move to that tab once you there click on NAT gateways and create a NAT gateway.

Okay so once you're here you'll need to specify a few things you'll need to give the NAT gateway a name you'll need to pick a public subnet for the NAT gateway to go into and then you'll need to give the NAT gateway an elastic IP address which is an IP address which doesn't change.

So first we'll set the name of the NAT gateway and we'll choose to use a4l for animals for life -vpc1 -natgw and then -a because this is going into availability zone A.

Next we'll need to pick the public subnet that the NAT gateway will be going into so click on the subnet drop down and then select the web a subnet which is the public subnet in availability zone a so sn -web -a.

Now we need to give this NAT gateway an elastic IP it doesn't currently have one so we need to click on allocate elastic IP which gives it an allocation.

Don't worry about the connectivity type we'll be covering that elsewhere in the course just scroll down to the bottom and create the NAT gateway.

Now this process will take some time and so we need to go ahead and create the two other NAT gateways.

So click on NAT gateways at the top and then we're going to create a second NAT gateway.

So go ahead and click on create NAT gateway again this time we'll call the NAT gateway a4l -vpc1 -natgw -b and this time we'll pick the web b subnet so sn -web -b allocated elastic IP again and click on create NAT gateway then we'll follow the same process a third time so click create NAT gateway use the same naming scheme but with -c pick the web c subnet from the list allocate an elastic IP and then scroll down and click on create NAT gateway and at this point we've got the three NAT gateways that are being created they're all in appending state if we go to elastic IPs we can see the three elastic IPs which have been allocated to the NAT gateways and we can scroll to the right or left and see details on these IPs and if we wanted we could release these IPs back to the account once we'd finish with them now at this point you need to go ahead and pause the video and resume it once all three of those NAT gateways have moved away from appending state we need them to be in an available state ready to go before we can continue with this demo so go ahead and pause and resume once all three have changed to an available state okay so all these are now in an available state so that means they're good to go they're providing service now if you scroll to the right in this list you're able to see additional information about these NAT gateways so you can see the elastic and private IP address the VPC and then the subnet that each of these NAT gateways are located in what we need to do now is configure the routing so that the private instances can communicate via the NAT gateways so right click on route tables and open in a new tab and we need to create a new route table for each of the availability zones so go ahead and click on create route table first we need to pick the VPC for this route table so click on the VPC drop down and then select the animals for live VPC so a for L hyphen VPC one once selected go ahead and name at the route table we're going to keep the naming scheme consistent so a for L hyphen VPC one hyphen RT for route table hyphen private a so enter that and click on create then close that dialogue down and create another route table this time we'll use the same naming scheme but of course this time it will be RT hyphen private B select the animals for life VPC and click on create close that down and then finally click on create route table again this time a for L hyphen VPC one hyphen RT hyphen private C again click on the VPC drop down and select the animals for life VPC and then click on create so that's going to leave us with three route tables one for each availability zone what we need to do now is create a default route within each of these route tables and that route is going to point at the NAT gateway in the same availability zone so select the route table private a and then click on the routes tab once you've selected the routes tab click on edit routes and we're going to add a new route it's going to be the IP version for default route of 0.0.0.0/0 and then click on target and pick NAT gateway and we're going to pick the NAT gateway in availability zone a and because we named them it makes it easy to select the relevant one from this list so go ahead and pick a for L hyphen VPC one hyphen NAT GW hyphen a so because this is the route table in availability zone a we need to pick the same NAT gateway so save that and close and now we'll be doing the same process for the route table in availability zone B make sure the routes tab is selected and click on edit routes click on add route again 0.0.0.0/0 and then for target pick NAT gateway and then pick the NAT gateway that's in availability zone B so NAT GW hyphen B once you've done that save the route table and then next select the route table in availability zone C so select RT hyphen private C make sure the routes tab is selected and click on edit routes again we'll be adding a route it will be the IP version for default route so 0.0.0.0/0 select a target go to NAT gateway and pick the NAT gateway in availability zone C so NAT GW hyphen C once you've done that save the route table and now our private EC2 instance should be able to ping 1.1.1.1 because we have the routing infrastructure in place so let's move back to our private instance and we can see that it's not actually working now the reason for this is that although we have created these routes we haven't actually associated these route tables with any of the subnets subnets in a VPC which don't have an explicit route table association are associated with the main route table now we need to explicitly associate each of these route tables with the subnets inside that same AZ so let's go ahead and pick RT hyphen private A we'll go through in order so select it click on the subnet associations tab and edit subnet associations and then you need to pick all of the private subnets in AZ A so that's the reserved subnet so reserved hyphen A the app subnet so app hyphen A and the DB subnet so DB hyphen A so all of these are the private subnets in availability zone A notice how all the public subnets are associated with this custom route table you created earlier but the ones we're setting up now are still associated with the main route table so we're going to resolve that now by associating this route table with those subnets so click on save and this will associate all of the private subnets in AZ A with the AZ A route table so now we're going to do the same process for AZ B and AZ C and we'll start with AZ B so select the private B route table click on subnet associations edit subnet associations so select application B database B and then reserved B and then scroll down and save the associations and then select the private C route table click on subnet associations edit subnet associations and then select reserved C database C and then application C and then scroll down and save those associations and now that we've associated these route tables with the subnets and now that we've added those default routes if we go back to session manager where we still have the connection open to the private EC2 instance we should see that the ping has started to work and that's because we now have a NAT gateway providing service to each of the private subnets in all of the three availability zones okay so that's everything you needed to cover in this demo lesson now it's time to clean up the account and return it to the same state as it was at the start of this demo lesson from this point on within the course you're going to be using automation and so we can remove all the configuration that we've done inside this demo lesson so the first thing we need to do is to reverse the route table changes that we've done so we need to go ahead and select the RT hyphen private a route table go ahead and select subnet associations and then edit the subnet associations and then just uncheck all of these subnets and this will return these to being associated with the main route table so scroll down and click on save do the same for RT hyphen private be so deselect all of these associations and click on save and then the same for RT hyphen private see so select it go to subnet associations and then edit them and remove all of these subnets and click on save next select all of these private route tables these are the ones that we created in this lesson so select them all click on the actions drop down and then delete route table and confirm by clicking delete route tables go to NAT gateways on the left and we need to select each of the NAT gateways in turn so a and then click on actions and delete NAT gateway type delete click delete then select be and do the same process actions delete NAT gateway type delete click delete and finally the same for see so select the C NAT gateway click on actions and delete NAT gateway you'll need to type delete to confirm click on delete now we're going to need all of these to be in a fully deleted state before we can continue so hit refresh and make sure that all three NAT gateways are deleted if yours aren't deleted if they're still listed in a deleting state then go ahead and pause the video and resume once all of these have changed to deleted at this point all of the NAT gateways have deleted so you can go ahead and click on elastic IPs and we need to release each of these IPs so select one of them and then click on actions and release elastic IP addresses and click release and do the same process for the other two click on release then finally actions release IP click on release once that's done move back to the cloud formation console select the stack which was created by the one click deployment at the start of the lesson and click on delete and then confirm that deletion and that will remove the cloud formation stack and any resources created as part of this demo and at that point once that finishes deleting the account has been returned into the same state as it was at the start of this demo lesson so I hope this demo lesson has been useful just to reiterate what you've done you've created three NAT gateways for a region resilient design you've created three route tables one in each availability zone added a default IP version for route pointing at the corresponding NAT gateway and associated each of those route tables with the private subnets in those availability zones so you've implemented a regionally resilient NAT gateway architecture so that's a great job that's a pretty complex demo but it's going to be functionality that will be really useful if you're using AWS in the real world or if you have to answer any exam questions on NAT gateways with that being said at this point you have cleared up the account you've deleted all the resources so go ahead complete this video and when you're ready I'll see you in the next.

Hello there, folks.

Thanks once again for joining.

Now that we've got a little bit of an understanding of what problem cloud is solving, let's actually go ahead and define it.

So what we'll talk about is technology on tap, a common phrase that you might have heard about when talking about cloud.

What is it and why would we say that?

Then what we're actually going to do is walk through the NIST definition of cloud.

So there are five key properties that the National Institute of Standards and Technology does use to determine whether or not something is cloud.

So we'll walk through that.

So we've got a good understanding of what cloud is and what cloud is not.

So first things first, technology on tap.

Why would we refer to cloud as technology on tap?

Well, let's have a think about the taps we do know about.

When you want access to water, if you're lucky enough to have access to a nice and easy supply of water, all you really need to do is turn on your tap and get access to as little or as much water as you want.

You can turn that on and off as you require.

Now, we know that that's easy for us.

All we have to worry about is the tap and paying the bill for the amount of water that we consume.

But what we don't really have to worry about is everything that goes in behind the scenes.

So the treatment of the water to bring it up to drinking standards, the actual storage of that treated water, and then the transportation of that through the piping network to actually get to our tap.

All of that is managed for us.

We don't need to really worry about what happens behind the scenes.

All we do is focus on that tap.

We turn it on if we want more.

We turn it off when we are finished.

We only pay for what we consume.

So you might be able to see where I'm going with this.

This is exactly what we are talking about with cloud.

With cloud, however, it's not water that we're getting access to, it is technology.

So if we want access to technology, we use the cloud.

We push some buttons, we click on an interface, we use whatever tool we require, and we get access to those servers, that storage, that database, whatever it might be that we require in the cloud.

Now again, behind the scenes, we don't have to worry about the data centers that host all of this technology, all of these services that we want access to.

We don't worry about the physical infrastructure, the hosting infrastructure, the storage, all the different bits and pieces that actually get that technology to us, we don't need to worry about.

And how does it get to us?

How is it available all across the globe?

Well, we don't need to worry about that connectivity and delivery as well.

All of this behind the scenes when we use cloud is managed for us.

All we have to worry about is turning on or off services as we require.

And this is why you can hear cloud being referred to as technology on tap, because it is very similar to the water utility service.

Utility service is another name you might hear cloud being referred to, because it's like water or electricity.

Cloud are like these utility services where you don't have to worry about all the infrastructure behind the scenes.

You just worry about the thing that you want access to.

And really importantly, you only have to pay for what you use.

You turn it on if you need it, you turn it on if you don't, you create things when you need them, delete them when you don't, and you only pay for those services when you have them, even though they are constantly available at your fingertips.

Now, compare this to the scenario we walked through earlier.

Traditionally, we would have to buy all of the infrastructure, have it sitting there idly, even if we weren't using it, we would still have had to pay for it, set it up, power it and keep it all running.

So this is a high level of what we are talking about with cloud.

Easy access to servers when you need them, turn them off when you don't, don't worry about all that infrastructure behind the scenes.

But that's a high level definition.

So let's now walk through what the NIST use as the key properties to define cloud.

One of the first properties you can use to understand whether something is or is not cloud is understanding whether or not it provides you on demand self service access, where you can easily go ahead and get that technology without even having to talk to humans.

So what do I really mean by that?

Well, let's say you're a cloud administrator, you want to go ahead and access some resources in the cloud.

Now, if you do want access to some services, some data, some storage and application, whatever it might be, while you're probably going to have some sort of admin interface that you can use, whether that's a command line tool or some sort of graphical user interface, you can easily use that to turn on any of the services that you need, web applications, data, storage, compute and much, much more.

And you don't have to go ahead, talk to another human, procure all of the infrastructure that runs behind the scenes.

You use your tool, it is self service, it is on demand, create it when you want it, delete it when you don't.

So that's on demand self service access and one of the key properties of the cloud.

Next, what I want to talk to you about is broad network access.

Now, this is where we're just saying, if something is cloud, it should be easy for you to access through standard capabilities.

So for example, if we are the cloud administrator, it's pretty common when you're working with technology to expect that you would have command line tools, web based tools and so on.

But even when we're not talking about cloud administrators and we're actually talking about the end users, maybe for example, accessing storage, it should be easy for them to do so through standard tools as well, such as a desktop application, a web browser or something similar.

Or maybe you've gone ahead and deployed a reporting solution in the cloud, like we spoke of in the previous lesson.

Well, you would commonly expect for that sort of solution that maybe there's also a mobile application to go and access all of that reporting data.

The key point here is that if you are using cloud, it is expected that all of the common standard sorts of accessibility options are available to you, public access, private access, desktop applications, mobile applications and so on.

So if that's what cloud is and how we access it, where actually is it?

That's a really important part of the definition of cloud.

And that's where we're referring to resource pooling, this idea that you don't really know exactly where the cloud is that you are going to access.

So let's say for example, you've got your Aussie Mart company.

If they want to deploy their solution to be available across the globe, well, it should be pretty easy for them to actually go ahead and do that.

Now, we don't know necessarily where that is.

We can get access to it.

We might say, I want my solution available in Australia East for example, or Europe or India or maybe central US for example.

All of these refer to general locations where we want to deploy our services.

When you use cloud, you are not going to go ahead and say, I want one server and I want it deployed to the data center at 123 data center street.

Okay, you don't know the physical address exactly or at least you shouldn't really have to.

All you need to know about is generally where you are going to go and deploy that.

Now, you will also see that for most cloud providers, you've got that global access in terms of all the different locations you can deploy to.

And really importantly, in terms of all of these pooled resources, understand that it's not just for you to use.

There will be other customers all across the globe who are using that as well.

So when you're using cloud, there are lots of resources.

They might be in lots of different physical locations and lots of different physical infrastructure and in use by lots of different customers.

And you don't really need to worry about that or know too much about it.

Another really important property of the cloud is something referred to as rapid elasticity.

Now elasticity is the idea that you can easily get access to more or less resources.

And when you work with cloud, you're actually going to commonly hear this being referred to as scaling out and in rather than just scaling up and down.

So what do I mean by that?

Well, let's say we've got our users that need to access our Aussie Mart store.

We might decide to use cloud to host our Aussie Mart web application.

And perhaps that's hosted on a server and a database.

Now, when that application gets really busy, for example, if we have lots of different users going to access it at the same time, we might want to scale out to meet demand.

That is to say, rather than having one server that hosts our web application, we might actually have three.

And if that demand for our application decreases, we might actually go ahead and decrease the underlying resources that power it as well.

What we are talking about here is scaling in and out by adding or decreasing the number of resources that host our application.

This is different from the traditional approach to scalability, where what we would normally do is just add CPU or add memory, for example.

We would increase the size of one individual resource that was hosting our solution.

So that's just elasticity at a high level and it's a really key property of cloud.

Now, we'll just say here that if you are worried about how that actually works behind the scenes in terms of how you host that application across duplicate resources, how you provide connectivity to that, that's all outside the scope of this beginners course, but it's definitely covered in other content as well.

So when you're using cloud, you get easy access to scale in and out and you should never feel like there are not enough resources to meet your demand.

To you, it should just feel like if you want a hundred servers, for example, then you can easily get a hundred servers.

All right, now the last property of cloud that I want to talk to you about is that of measuring service.

When we're talking about measuring service, what we're talking about is the idea that if you are using cloud to host your solutions, it should be really easy for you to go and say, I know what this is costing, I know where my resources are, how they are performing and whether there are any issues and I can control the types of resources and the configuration that I use that I'm going to deploy.

So for example, it should be easy for you to say, how much is it going to cost me for five gigabytes of storage?

What does my bill look like currently and what am I forecasted to be using over the remainder of the month?

Or maybe you want to say that certain services should not be allowed to be deployed across all regions.

Yes, cloud can be accessed across the globe, but maybe your organization only works in one part of a specific country and that's the only location you should be able to use.

These are the standard notions of measuring and controlling service and it's really common to all of the cloud providers.

All right, everybody.

So now you've got an understanding of what cloud is and how you can define it.

If you'd like to see more about this definition from the NIST, then be sure to check out the link that I've included for this lesson.

So thanks for joining me, folks.

I'll see you in the next lesson.

Hey there everybody, thanks for joining.

It's great to have you with me in this lesson where we're going to talk about why cloud matters.

Now to help answer that question, what I want to do firstly is talk to you about the traditional IT infrastructure.

How did we used to do things?

What sort of challenges and issues did we face?

And therefore we'll get a better understanding of what cloud is actually doing to help.

We can look at how things used to be and how things are now.

So what we're going to do throughout this lesson is walk through a little bit of a scenario with a fictitious company called Ozzymart.

So let's go ahead now, jump in and have a chat about the issues that they're currently facing.

Ozzymart is a fictitious company that works across the globe selling a range of different Australia related paraphernalia.

Maybe stuffed toys for kangaroos, koalas and that sort of thing.

Now they've currently got several different applications that they use that they provide access to for their users.

And currently the Ozzymart team do not use the cloud.

So when we have a look at the infrastructure hosting these applications, we'll learn that Ozzymart have a couple of servers, one server for each of the applications that they've got configured.

Now the Ozzymart IT team have had to have gone and set up these servers with windows, the applications and all the different data that they need for these applications to work.

And what it's also important to understand about the Ozzymart infrastructure is all of this is currently hosted on their on-premises customer managed infrastructure.

So yes, the Ozzymart team could have gone out and maybe used a data center provider.

But the key point here is that the Ozzymart IT team have had to set up servers, operating systems, applications and a range of other infrastructure to support all of this storage, networking, power, cooling.

Okay, these are the sorts of things that we have to manage traditionally before we were able to use cloud.

Now to help understand what sort of challenges that might introduce, let's walk through a scenario.

We're going to say that the Ozzymart CEO has gone and identified the need for reporting to be performed across these two applications.

And the CEO wants those reports to be up and ready by the end of this month.

Let's say that's only a week away.

So the CEO has instructed the finance manager and the finance manager has said, "Hey, awesome.

You know what?

I've found this great app out there on the internet called Reports For You.

We can buy it, download it and install it.

I'm going to go tell the IT team to get this up and running straight away."

So this might sound a little bit familiar to some of you who have worked in traditional IT where sometimes demands can come from the top of the organization and they filter down with really tight timelines.

So let's say for example, the finance manager is going to go along, talk to the IT team and say, "We need this Reports For You application set up by the end of month."

Now the IT team might be a little bit scared because, hey, when we look at the infrastructure we've got, it's supporting those two servers and applications okay, but maybe we don't have much more space.

Maybe we don't have enough storage.

Maybe we are using something like virtualization.

So we might not need to buy a brand new physical server and we can run up a virtual Windows server for the Reports For You application.

But there might just not be enough resources in general.

CPU, memory, storage, whatever it might be to be able to meet the demands of this Reports For You application.

But you've got a timeline.

So you go ahead, you get that server up and running.

You install the applications, the operating system data, all there as quickly as you can to meet these timelines that you've been given by the finance manager.

Now maybe it's not the best server that you've ever built.

It might be a little bit rushed and a little bit squished, but you've managed to get that server up and running with the Reports For You application and you've been able to meet those timelines and provide access to your users.

Now let's say that you've given access to your users for this Reports For You application.

Now let's say when they start that monthly reporting job, the Reports For You application needs to talk to the data across your other two applications, the Aussie Mart Store and the Aussie Mart Comply application.

And it's going to use that data to perform the reporting that the CEO has requested.

So you kick off this report job on a Friday.

You hope that it's going to be complete on a Saturday, but maybe it's not.

You check again on a Sunday and things are starting to get a little bit scary.

And uh-oh, Monday rolls around, the Reports For You report is still running.

It has not yet complete.

And that might not be so great because you don't have a lot of resources on-premises.

And now all of your applications are starting to perform really poorly.

So that Reports For You application is still running.

It's still trying to read data from those other two applications.

And maybe they're getting really, really slow and let's hope not, but maybe the applications even go off entirely.

Now those users are going to become pretty angry.

You're going to get a lot of calls to the help desk saying that things are offline.

And you're probably going to have the finance manager and every other manager reaching out to you saying, this needs to be fixed now.

So let's say you managed to push through, perhaps through the rest of Monday, and that report finally finishes.

You clearly need more resources to be able to run this report much more quickly at the end of each month so that you don't have angry users.

So what are you going to do to fix this for the next month when you need to run the report again?

Well, you might have a think about ordering some new software and hardware because you clearly don't have enough hardware on-premises right now.

You're going to have to wait some time for all of that to be delivered.

And then you're going to have to physically and store it, set it up, get it running, and make sure that you've got everything you need for reports for you to be running with more CPU and resources next time.

There's a lot of different work that you need to do.

This is one of the traditional IT challenges that we might face when the business has demands and expectations for things to happen quickly.

And it's not really necessarily the CEO or the finance manager's fault.

They are focused on what the business needs.

And when you work in the technology teams, you need to do what you can to support them so that the business can succeed.

So how might we do that a little bit differently with cloud?

Well, with cloud, we could sign up for a cloud provider, we could turn on and off servers as needed, and we could scale up and scale down, scale in and scale out resources, all to meet those demands on a monthly basis.

So that could be a lot less work to do and it could certainly provide you the ability to respond much more quickly to the demands that come from the business.

And rather than having to go out and buy all of this new infrastructure that you are only going to use once a month, well, as we're going to learn throughout this course, one of the many benefits of cloud is that you can turn things on and off really quickly and only pay for what you need.

So what might this look like with cloud?

Well, with cloud, what we might do is no longer have that on-premises rushed server that we were using for reports for you.

Instead of that, we can go out to a public cloud provider like AWS, GCP or hopefully Azure, and you can set up those servers once again using a range of different features, products that are all available through the various public cloud providers.

Now, yes, in this scenario, we are still talking about setting up a server.

So that is going to take you some time to configure Windows, set up the application, all of the data and configuration that you require, but at least you don't need to worry about the actual physical infrastructure that is supporting that server.

You don't have to go out, talk to your procurement team, talk to a different providers, wait for different physical infrastructure to be delivered and licensing and software and other assets.

With cloud, as we will learn, you can really quickly get online and up and running.

And also, if we had that need to ensure that the reports for you application was running with lots of different resources at the end of the month, it's much easier when we use cloud to just go and turn some servers on and then maybe turn them off at the end of the month when they are no longer acquired.

This is the sort of thing that we are talking about with cloud.

We're only really just touching on the service about what cloud can do and what cloud actually is.

But my hope is that through this lesson, you can understand how cloud changes things.

Cloud allows us to work with technology in a much different way than we traditionally would work with our on-premises infrastructure.

Another example that shows how cloud is different is that rather than using the reports for you application, what we might in fact actually choose to do is go to a public cloud provider and go to someone that actually has a equivalent reports for you solution that's entirely built in the cloud ready to go.

In this way, not only do we no longer have to manage the underlying physical infrastructure, we don't actually have to manage the application software installation, configuration, and all of that service setup.

With something like a reporting software that's built in the cloud, we would just provide access to our users and only have to pay on a per user basis.

So if you've used something like zoom for meetings or Dropbox for data sharing, that's the sort of solution we're talking about.

So if we consider this scenario for Aussie Mart, we have a think about the benefits that they might access when they use the cloud.

Well, we can much more quickly get access to resources to respond to demand.

If we need to have a lot of different compute capacity working at the end of the month with cloud, like you'll learn, we can easily get access to that.

If we wanted to add lots of users, we could do that much more simply as well.

And something that the finance manager might really be happy about in this scenario is that we aren't going to go back and suggest to them that we need to buy a whole heap of new physical infrastructure right now.

When we think about traditionally how Aussie Mart would have worked with this scenario, they would have to go and buy some new physical servers, resources, storage, networking, whatever that might be, to meet the needs of this reports for you application.

And really, they're probably going to have to strike a balance between having enough infrastructure to ensure that the reports for you application completes its job quickly and not buying too much infrastructure that's just going to be sitting there unused whilst the reports for you application is not working.

And really importantly, when we go to cloud, we see this difference as not having to buy lots of physical infrastructure upfront as being referred to as capital expenditure versus operational expenditure.

Really, what we're just saying here is rather than spending a whole big lump sum all at once to get what you need, you can just pay on a monthly basis for what you need when you need it.

And finally, one of the other benefits that you'll also see is that we're getting a reduction in the amount of different tasks that we have to complete in terms of IT administration, set up of operating systems, management of physical infrastructure, what the procurement team has to manage, and so on.

Again, right now we're just talking really high level about a fictitious scenario for Aussie Mart to help you to understand the types of things and the types of benefits that we can get access to for cloud.

So hopefully if you're embarking on a cloud journey, you're gonna have a happy finance manager, CEO, and other team members that you're working with as well.

Okay, everybody, so that's a wrap to this lesson on why cloud matters.

As I've said, we're really only just scratching the surface.

This is just to introduce you to a scenario that can help you to understand the types of benefits we get access to with cloud.

As we move throughout this course, we'll progressively dive deeper in terms of what cloud is, how you define it, the features you get access to, and other common concepts and terms.

So thanks for joining me, I'll see you there.

Welcome back and in this brief demo lesson I want to give you some experience of working with both EC2 instance connect as well as connecting with a local SSH client.

Now these are both methods which are used for connecting to EC2 instances both with public IP version 4 addressing and IP version 6 addressing.

Now to get started we're going to need some infrastructure so make sure that you're logged in as the IAM admin user into the general AWS account which is the management account of the organization and as always you'll need the northern Virginia region selected.

Now in this demonstration you are going to be connecting to an EC2 instance using both instance connect and a local SSH client and to use a local SSH client you need a key pair.

So to create that let's move across to the EC2 console, scroll down on the left and select key pairs.

Now you might already have key pairs created from earlier in the course.

If you have one created which is called A4L which stands for Animals for Life then that's fine.

If you don't we're going to go ahead and create that one.

So click on create key pair and then under name we're going to use A4L.

Now if you're using Windows 10 or Mac OS or Linux then you can select the PEM file format.

If you're using Windows 8 or prior then you might need to use the putty application and to do that you need to select PPK.

But for this demonstration I'm going to assume that you're using the PEM format.

So again this is valid on Linux, Mac OS or any recent versions of Microsoft Windows.

So select PEM and then click on create key pair and when you do it's going to present you with a download.

It's going to want you to save this key pair to your local machine so go ahead and do that.

Once you've done that from the AWS console attached to this lesson is a one-click deployment link.

So I want you to go ahead and click that link.

That's going to move you to a quick create stack screen.

Everything should be pre-populated.

The stack name should be EC2 instance connect versus SSH.

The key name box should already be pre-populated with A4L which is a key that you just created or one which you already had.

Just move down to the very bottom, check the capabilities box and then click on create stack.

Now you're going to need this to be in a create complete state before you continue with the demo lesson.

So pause the video, wait for your stack to change to create complete and then you're good to continue.

Okay so this stacks now in a create complete status and we're good to continue.

Now if we click on the resources tab you'll see that this has created the standard animals for life VPC and then it's also created a public EC2 instance.

So this is an EC2 instance with a public IP version 4 address that we can use to connect to.

So that's what we're going to do.

So click on services and then select EC2 to move to the EC2 console.

Once you're there click on instances running and you should have a single EC2 instance A4L-publicEC2.

Now the two different ways which I want to demonstrate connecting to this instance in this demo lesson are using a local SSH client and key based authentication and then using the EC2 instance connect method.

And I want to show you how those differ and give you a few hints and tips which might come in useful for production usage and for the exams.

So if we just go ahead and select this instance and then click on the security tab you'll see that we have this single security group which is associated to this instance.

Now make sure the inbound rules is expanded and just have a look at what network traffic is allowed by this security group.

So the first line allows port 80 TCP which is HTTP and it allows that to connect to the instance from any source IP address specifically IP version 4.

We can tell it's IP version 4 because it's 0.0.0.0/0 which represents any IP version 4 address.

Next we allow port 22 using TCP and again using the IP version 4 any IP match and this is the entry which allows SSH to connect into this instance using IP version 4.

And then lastly we have a corresponding line which allows SSH using IP version 6.

So we're allowing any IP address to connect using SSH to this EC2 instance.

And so connecting to it using SSH is relatively simple.

We can right click on this instance and select connect and then choose SSH client and AWS provides us with all of the relevant information.

Now note how under step number three we have this line which is chmod space 400 space a4l.pm.

I want to demonstrate what happens if we attempt to connect without changing the permissions on this key file.

So to do that right at the bottom is an example command to connect to this instance.

So just copy that into your clipboard.

Then I want you to move to your command prompt or terminal.

In my case I'm running macOS so I'm using a terminal application.

Then you'll need to move to the folder where you have the PEM file stored or where you just downloaded it in one of the previous steps.

I'm going to paste in that command which I just copied onto my clipboard.

This is going to use the a4l.pm file as the identity information and then it's going to connect to the instance using the EC2-user local Linux user.

And this is the host name that it's going to connect to.

So this is my EC2 instance.

Now I'm going to press enter and attempt that connection.

First it will ask me to verify the authenticity of this server.

So this is an added security method.

This is getting the fingerprint of this EC2 instance.

And it means that if we independently have a copy of this fingerprint, say from the administrator of the server that we're connecting to, then we can verify that we're connecting to that same server.

Because it's possible that somebody could exploit DNS and replace a legitimate DNS name with one which points at a non-legitimate server.

So that's important.

You can't always rely on a DNS name.

DNS names can be adjusted to point at different IP addresses.

So this fingerprint is a method that you can use to verify that you're actually connecting to the machine or the instance which you think you are.

Now in this case, because we've just created this EC2 instance, we can be relatively certain that it is valid.

So we're just going to go ahead and type yes and press enter.

And then it will try to connect to this instance.

Now immediately in my case, I got an error.

And this error is going to be similar if you're using macOS or Linux.

If you're using Windows, then there is a chance that you will get this error or won't.

And if you do get it, it might look slightly different.

But look for the keyword of permissions.

If you see that you have a permissions problem with your key, then that's the same error as I'm showing on my screen now.

Basically what this means is that the SSH client likes it when the permissions on these keys are restricted, restricted to only the user that they belong to.

Now in my case, the permissions on this file are 644.

And this represents my user, my group, and then everybody.

So this means this key is accessible to other users on my local system.

And that's far too open to be safe when using local SSH.

Now in Windows, you might have a similar situation where other users of your local machine have read permissions on this file.

What this error is telling us to do is to correct those permissions.

So if we go back to the AWS console, this is the command that we need to run to correct those permissions.

So copy that into your clipboard, move back to your terminal, paste that in, and press enter.

And that will correct those permissions.

Now under Windows, the process is that you need to edit the permissions of that file.

So right click properties and then edit the security.

And you need to remove any user access to that file other than your local user.

And that's the same process that we've just done here, only in Windows it's GUI based.

And under Mac OS or Linux, you use CHmod.

So now that we've adjusted those permissions, if I use the up arrow to go back to the previous command and press enter, I'm able to connect to the CC2 instance.

And that's using the SSH client.

To use the SSH client, you need to have network connectivity to the CC2 instance.

And you need to have a valid SSH key pair.

So you need the key stored on your local machine.

Now this can present scalability issues because if you need to have a large team having access to this instance, then everybody in that team need a copy of this key.

And so that does present admin problems if you're doing it at scale.

Now in addition to this, because you're connecting using an SSH client from your local machine, you need to make sure that the security group of this instance allows connections from your local machines.

So in this case, it allows connections from any source IP address into this instance.

And so that's valid for my IP address.

You need to make sure that the security group on whichever instance you're attempting to connect to allows your IP address as a minimum.

Now another method that you can use to connect to EC2 is EC2 instance connect.

Now to use that, we right click, we select connect, and we have a number of options at the top.

One of these is the SSH client that we've just used.

Another one is EC2 instance connect.

So if we select this option, we're able to connect to this instance.

It shows us the instance ID, it shows us the public IP address, and it shows us the user to connect into this instance with.

Now AWS attempt to automatically determine the correct user to use.

So when you launch an instance using one of the default AMIs, then it tends to pick correctly.

However, if you generate your own custom AMI, it often doesn't guess correctly.

And so you need to make sure that you're using the correct username when connecting using this method.

But once you've got the correct username, you can just go ahead and click on connect, and then it will open a connection to that instance using your web browser.

It'll take a few moments to connect, but once it has connected, you'll be placed at the terminal of this EC2 instance in exactly the same way as you were when using your local SSH.

Now one difference you might have noticed is at no point where you prompted to provide a key.

When you're using EC2 instance connect, you're using AWS permissions to connect into this instance.

So because we're logged in using an admin user, we have those permissions, but you do need relevant permissions added to the identity of whoever is using instance connect to be able to connect into the instance.

So this is managed using identity policies on the user, the group or the role, which is attempting to access this instance.

Now one important element of this, which I want to demonstrate, if we go back to instances and we select the instance, click on security, and then click on the security group, which is associated with this instance.

Scroll down, click on edit inbound rules, and then I want you to locate the inbound rule for IP version 4 SSH, SSH TCP 22, and then it's using this catchall, so 0.0.0.0/0, which represents any IP version 4 address.

So go ahead and click on the cross to remove that, and then on that same line in the source area, click on this drop down and change it to my IP.

So this is my IP address, yours will be different, but then we're going to go ahead and save that rule.

Now just close down the tab that you've got connected to instance connect, move back to the terminal, and type exit to disconnect from that instance, and then just rerun the previous command.

So connect back to that instance using your local SSH client.

You'll find that it does reconnect because logically enough, this connection is coming from your local IP address, and you've changed the security group to allow connections from that address, so it makes sense that this connection still works.

Moving back to the console though, let's go to the EC2 dashboard, go to running instances, right click on this instance, go to connect, select EC2 instance connect, and then click on connect and just observe what happens.

Now you might have spent a few minutes waiting for this to connect, and you'll note that it doesn't connect.

Now this might seem strange at this point because you're connecting from a web browser, which is running on your local machine.

So it makes sense that if you can connect from your local SSH client, which is also running on your local machine, you should be able to connect using EC2 instance connect.

Now this might seem logical, but the crucial thing about EC2 instance connect is that it's not actually originating connections from your local machine.

What's happening is that you're making a connection through to AWS, and then once your connection arrives at AWS, the EC2 instance connect service is then connecting to the EC2 instance.

Now what you've just done is you've edited the security group of this instance to only allow your local IP address to connect, and this means that the EC2 instance connect service can no longer connect to this instance.

So what you need in order to allow the EC2 instance connect service to work is you either need to allow every source IP address, so 0.0.0.0.0/0, but of course that's bad practice for production usage.

It's much more secure if you go to this URL, and I'll make sure that I include this attached to this lesson.

This is a list of all of the different IP ranges which AWS use for their services.

Now because I have this open in Firefox, it might look a little bit different.

If I just go to raw data, that might look the same as your browser.

If you're using Firefox, you have the ability to open this as a JSON document.

Both of them show the same data, but when it's JSON, you have the ability to collapse these individual components.

But the main point about this document is that this contains a list of all of the different IP addresses which are used in each different region for each different service.

So if we wanted to allow EC2 instance connect for a particular region, then we might search for instance, locate any of these items which have EC2 instance connect as the service, and then just move through them looking for the one which matches the region that we're using.

Now in my case, I'm using US East One, so I'd scroll through all of these IP address ranges looking for US East One.

There we go, I've located it.

It's using this IP address range.

So I might copy this into my clipboard, move back to the EC2 console, select the instance, click on security, select the security group of this instance, scroll down, edit the inbound rules, remove the entry for my IP address, paste in the entry for the EC2 instance connect service, and then save that rule.

And now what you'll find if you move back to your terminal and try to interact with this instance, you might be able to initially because the connection is still established, but if you exit and then attempt to reconnect, this time you'll see that you won't be able to connect because now your local IP address is no longer allowed to connect to this instance.

However, if you move back to the AWS console, go to the dashboard and then instance is running, right click on the instance and put connect, select instance connect and then click on connect.

Now you'll be allowed to connect using EC2 instance connect.

And the reason for that just to reiterate is that you've just edited the security group of this EC2 instance and you've allowed the IP address range of the EC2 instance connect service.

So now you can connect to this instance and you could do so at scale using AWS permissions.

So I just wanted to demonstrate how both of those connection methods work, both instance connect and using a local SSH client.

That's everything I wanted to cover.

So just go ahead and move back to the CloudFormation console, select this stack that you created using the one click deployment, click on delete and then confirm that process.

And that will clear up all of the infrastructure that you've used in this demo lesson.

At this point though, that's everything I wanted to cover.

So go ahead, complete this video and when you're ready, I'll look forward to you joining me in the next.

Welcome back.

This is part two of this lesson.

We're going to continue immediately from the end of part one.

So let's get started.

So focusing specifically on the animals for life scenario.

So what we're going to do in the upcoming demo lesson, to implement a truly resilient architecture for net services in a VPC, you need a net gateway in a public subnet inside each availability zone that the VPC uses.

So just like on the diagram that you've gone through now.

And then as a minimum, you need private route tables in each availability zone.

In this example, AZA, AZB, and then AZC.

Each of these would need to have their own route table, which would have a default IP version for route, which points at the net gateway in the same availability zone.

That way, if any availability zone fails, the others could continue operating without issues.

Now, this is important.

I've seen it in a few of some questions.

Where it suggests that one net gateway is enough, that a net gateway is truly regionally resilient.

This is false.

A net gateway is highly available in the availability zone that it's in.

So if hardware fails or it needs to scale to cope with load, it can do so in that AZ.

But if the whole AZ fails, there is no failover.

You provision a net gateway into a specific availability zone, not the region.

It's not like the internet gateway, which by default is region resilient.

For a net gateway, you have to deploy one into each AZ that you use if you need that region resilience.

Now, my apologies in advance for the small text.

It's far easier to have this all on screen at once.

I mentioned at the start of the lesson that net used to be provided by net instances, and these are just for the net process running on an EC2 instance.

Now, I don't expect this to feature on the exam at this point.

But if you ever need to use a net instance, by default, EC2 filters all traffic that it sends or receives.

It essentially drops any data that is on its network card when that network card is not either the source or the destination.

So if an instance is running as a net instance, then it will be receiving some data which the source address will be of other resources in that VPC.

And the destination will be a host on the internet.

So it will neither be the source nor the destination.

So by default, that traffic will be dropped.

And if you need to allow an EC2 instance to function as a net instance, then you need to disable a feature called source and destination checks.

This can be disabled via the console UI, the CLI, or the API.

The only reason I mention this is I have seen this question in the exam before, and if you do implement this in a real-world production-style scenario, you need to be aware that this feature exists.

I don't want you wasting your time trying to diagnose this feature.

So if you just right-click on an instance in the console, you'll be able to see an option to disable source and destination checks.

And that is required if you want to use an EC2 instance as a net instance.

Now, at the highest level, architecturally, net instances and net dayways are kind of the same.

They both need a public ID address.

They both need to run in a public subnet, and they both need a functional internet gateway.

But at this point, it's not really preferred to use EC2 running as a net instance.

It's much easier to use a net gateway, and it's recommended by AWS in most situations.

But there are a few key scenarios where you might want to consider using an EC2-based net instance.

So let's just step through some of the criteria that you might be looking at when deploying net services.

If you value availability, bandwidth, low levels of maintenance, and high performance, then you should use net gateways.

That goes for both real-world production usage, as well as being default for answering any exam questions.

A net gateway offers high-end performance, its scales, its custom design, perform network address translation.

A net instance in comparison is limited by the capabilities of the instances running on, and that instance is also general purpose, so it won't offer the same level of custom design performance as a net gateway.

Now, availability is another important consideration, and that instance is a single EC2 instance running inside an availability zone.

It will fail if the EC2 hardware fails.

It will fail if its storage fails or if its network fails, and it will fail if the AZ itself fails entirely.

A net gateway has some benefits over a net instance.

So inside one availability zone, it's highly available, so it can automatically recover, it can automatically scale.

So it removes almost all of the risks of outage versus a net instance.

But it will still fail entirely if the AZ fails entirely.

You still need provision, multiple net gateways, spread across all the AZs that you intend to use, if you want to ensure complete availability.

For maximum availability, a net gateway in every AZ you use.

This is critical to remember for the exam.

Now, if cost is your primary choice, if you're a financially challenged business, or if the VPC that you're deploying net services into is just a test VPC or something that's incredibly low volume, then a net instance can be cheaper.

It can also be significantly cheaper at high volumes of data.

You've got a couple of options.

You can use a very small EC2 instance, even ones that are free tier eligible to reduce costs, and the instances can also be fixed in size, meaning they offer predictable costs.

A net gateway will scale automatically, and you'll build for both the net gateway and the amount of data transferred, which increases as the gateway scales.

A net gateway is also not free tier eligible.

Now, this is really important because when we deploy these in the next demo lesson, it's one of those services that I need to warn you will come at a cost, so you need to be aware of that fact.

You will be charged for a net gateway regardless of how small the usage.

Net instances also offer other niche advantages because they're just EC2 instances.

You can connect to them just like you would any other EC2 instance.

You can multi-purpose them so you can use them for other things, such as passing hosts.

You can also use them for port forwarding, so you can have the port on the instance externally that could be connected to over the public internet, and have this forwarded-on for an instance inside the VPC.

Maybe port 8 if a web, or port 443 for secure web.

You can be completely flexible when you use net instances.

With a net gateway, this isn't possible because you don't have access to manage it.

It's a managed service.

Now, this comes up all the time in the exam, so try and get it really clear in your memory, and that gateway cannot be used as a passing host.

It cannot do port forwarding because you cannot connect to its operating system.

Now, finally, this is again one focus on the exam.

Net instances are just EC2 instances, so you can filter traffic using the network ACLs on the subnet instances in, or security groups directly associated with that instance.

Net gateways don't support security groups.

You can only use knuckles with net gateways.

This one comes up all the time in the exam, so it's worth noting down and maybe making a flashcard with.

Now, a few more things before we finish up.

What about IP version 6?

The focus of net is to allow private IP version 4 addresses to be used to connect in an outgoing only way to the AWS public zone and public internet.

Inside AWS, all IP version 6 addresses are publicly routable, so this means that you do not require net when using IP version 6.

The internet gateway works directly with IP version 6 addresses, so if you choose to make an instance in a private subnet, have a default IP version 6 route to the internet gateway, it will become a public instance.

As long as you don't have any knuckles or any security groups, any IP version 6 IP address in AWS can communicate directly with the AWS public zone and the public internet.

So the internet gateway can work directly with IP version 6.

Net gateways do not work with IP version 6, they're not required and they don't function with IP version 6.

So for the exam, if you see any questions which mention IP version 6 and net gateways, you can exclude the answer.

Net gateways do not work with IP version 6 and you can repeat it because I really wanted to stick in your memory.

So with any subnet inside AWS, which has been configured for IP version 6, if you add the IP version 6 default route, which is colon colon 4 slash 0, if you add that route and you point that route at the internet gateway as a target, that will give that instance bi-directional connectivity to the public internet and it will allow it to reach the AWS public zone and public services.

One service that we'll be talking about later on in the course when I cover more advanced features of VPC is a different type of gateway, known as an egress-only internet gateway.

This is a specific type of internet gateway that works only with IP version 6 and you use it when you want to give an IP version 6 instance outgoing only access to the public internet and the AWS public zone.

So don't worry, we'll be covering that later in the course, but I want to get it really burned into your memory that you do not use net and you do not use net gateways with IP version 6.

It will not work.

Now to get you some experience of using net gateways, it's time for a demo.

In the demo lesson, I'm going to be stepping you through what you need to do to provision a completely resilient net gateway architecture.

So that's using net gateway in each availability zone as well as configuring the routing required to make it work.

It's going to be one of the final pieces to our multi-tier VPC and it will allow private instances to have full outgoing internet access.

Now I can't wait for us to complete this together.

It's going to be a really interesting demo, one that will be really useful if you're doing this in the real world or if you have to answer exam questions related to net or net gateway.

So go ahead, complete the video and when you're ready, join me in the demo.

Welcome back.

In this lesson, I'll be talking about Network Address Translation, or NAT, a process of giving a private resource outgoing only access to the internet.

And a NAT gateway is the AWS implementation that's available within WPC.

There's quite a bit of theory to cover, so let's get started.

So what is NAT?

Well, it stands for Network Address Translation.

This is one of those terms which means more than people think that it does.

In a strict sense, it's a set of different processes which can adjust ID packets by changing their source or destination IP addresses.

Now, you've seen a form of this already.

The internet gateway actually performs a type of NAT known as static NAT.

It's how a resource can be allocated with a public IP version for address, and then when the packets of data leave those resources and pass through the internet gateway, it adjusts the source IP address on the packet from the private address to the public, and then sends the packet on, and then when the packet returns, it adjusts the destination address from the public IP address to the original private address.

That's called static NAT, and that's how the internet gateway implements public IP version for addressing.

Now, what most people think of when they think of NAT is a subset of NAT called IP Masquerading.

And IP Masquerading hides a whole private side IP block behind a single public IP.

So rather than the one private IP to one public IP process that the internet gateway does, NAT is many private IPs to one single IP.

And this technique is popular because IP version 4 addresses are running out.

The public address space is rapidly becoming exhausted.

IP Masquerading, or what we'll refer to for the rest of this lesson as NAT, gives a whole private range of IP addresses outgoing only access to the public internet and the AWS public zone.

I've highlighted outgoing because that's the most important part, because many private IPs use a single public IP.

Incoming access doesn't work.

Private devices that use NAT can initiate outgoing connections to internet or AWS public space services, and those connections can receive response data, but you cannot initiate connections from the public internet to these private IP addresses when NAT is used.

It doesn't work that way.

Now, AWS has two ways that it can provide NAT services.

Historically, you could use an EC2 instance configured to provide NAT, but it's also a managed service, the NAT gateway, which you can provision in the VPC to provide the same functionality.

So let's look at how this works architecturally.

This is a simplified version of the Animals for Life architecture that we've been using so far.

On the left is an application tier subnet in blue, and it's using the IP range 10.16.32.0/20.

So this is a private only subnet.

Inside it are three instances, I01, which is using the IP 10.16.32.10, I02, which is using 32.20, and I03, which is using 32.30.

These IP addresses are private, so they're not publicly routable.

They cannot communicate with the public internet or the AWS public zone services.

These addresses cannot be routed across a public style network.

Now, if we wanted this to be allowed, if we wanted these instances to perform certain activities using public networking, for example, software updates, how would we do it?

Well, we could make the subnet's public in the same way that we've done with the public subnets or the web subnets, but we might not want to do that architecturally.

With this multi-tier architecture that we're implementing together, part of the design logic is to have tiers which aren't public and aren't accessible from the public internet.

Now, we could also host some kind of software update server inside the VPC, and some businesses choose to do that.

Some businesses run Windows update services, all Linux update services inside their private network, but that comes with an admin overhead.

NAT offers us a third option, and it works really well in this style of situation.

We provision a NAT gateway into a public subnet, and remember, the public subnet allows us to use public IP addresses.

The public subnet has a route table attached to it, which provides default IP version 4 routes pointing at the internet gateway.

So, because the NAT gateway is located in this public web subnet, it has a public IP which is routable across the public internet, so it's now able to send data out and get data back in return.

Now, the private subnet where the instances are located can also have its own route table, and this route table can be different than the public subnet route table.

So, we could configure it so that the route table that's on the application subnet has a default IP version 4 route, but this time, instead of pointing at the internet gateway, like the web subnet users, we configure this private route table so that it points at the NAT gateway.

This means when those instances are sending any data to any IP addresses that do not belong inside the VPC, by default, this default route will be used, and that traffic will get sent to the NAT gateway.

So, let's have a look at how this packet flow works.

Let's simulate the flow packets from one of the private instances and see what the NAT gateway actually does.

So, first, instance 1 generates some data.

Let's assume that it's looking for software updates.

So, this packet has a source IP address of instance 1's private IP and a destination of 1.3.3.7.

For this example, let's assume that that's a software update server.

Now, because we have this default route on the route table of the application subnet, that packet is routed through to the NAT gateway.

The NAT gateway makes a record of the data packet.

It stores the destination that the packet is for, the source address of the instance sending it, and other details which help it identify the specific communication in future.

Remember, multiple instances can be communicating at once, and for each instance, it could be having multiple conversations with different public internet hosts.

So, the NAT gateway needs to be able to uniquely identify those.

So, it records the IP addresses involved, the source and destination, the port numbers, everything it needs, into a translation table.

So, the NAT gateway maintains something called a translation table which records all of this information.

And then, it adjusts the packet to the one that's been sent by the instance, and it changes the source address of this IP packet to be its own source address.

Now, if this NAT appliance were anywhere for AWS, what it would do right now is adjust the packet with a public routable address. - Hi. - Let's do this directly.

But remember, all the inside of the IPC really has directly attached to it a public IP version 4 address.

That's what the internet gateway does.

So, the NAT gateway, because it's in the web subnet, it has a default route, and this default route points at the internet gateway.

And so, the packet is moved from the NAT gateway to the internet gateway by the IPC router.

At this point, the internet gateway knows that this packet is from the NAT gateway.

It knows that the NAT gateway has a public IP version 4 address associated with it, and so, it modifies the packet to have a source address of the NAT gateway's public address, and it sends it on its way.

The NAT gateway's job is to allow multiple private IP addresses to masquerade behind the IP address that it has.

That's where the term IP masquerading comes from.

That's why it's more accurate.

So, the NAT gateway takes all of the incoming packets from all of the instances that it's managing, and it records all the information about the communication.

It takes those packets, it changes the source address from being those instances to its own IP address, its own external-facing IP address.

If it was outside AWS, this would be a public address directly.

That's how your internet router works for your home network.

All of the devices internally on your network talk out using one external IP address, your home router uses NAT.

But because it's in AWS, it doesn't have directly attached a real public IP.

The internet gateway translates from its IP address to the associated public one.

So, that's how the flow works.

If you need to give an instance its own public IP version for address, then only the internet gateway is required.

If you want to give private instances outgoing access to the internet and the AWS public services such as S3, then you need both the NAT gateway to do this many-to-one translation and the internet gateway to translate from the IP of the NAT gateway to a real public IP version for address.

Now, let's quickly run through some of the key facts for the NAT gateway product that you'll be implementing in the next demo lesson.

First, and I hope this is logical for you by now, it needs to run from a public subnet because it needs to be able to be assigned a public IP version for IP address for itself.

So, to deploy a NAT gateway, you already need your VPC in a position where it has public subnets.

And for that, you need an internet gateway, subnets configured to allocate public IP version for addresses and default routes for those subnets pointing at the internet gateway.

Now, a NAT gateway actually uses a special type of public IP version for address that we haven't covered yet called an elastic IP.

For now, just know that these are IP version for addresses, which is static.

They don't change.

These IP addresses are allocated to your account in a region and they can be used for whatever you want until you reallocate them.

And NAT gateways use these elastic IPs, the one service which utilizes elastic IPs.

Now, they're talking about elastic IPs later on in the course.

Now, NAT gateways are an AZ resilient service.

If you read the AWS documentation, you might get the impression that they're fully resilient in a region like an internet gateway.

They're not, they're resilient in the AZ that they're in.

So they can recover from hardware failure inside an AZ.

But if an AZ entirely fails, then the NAT gateway will also fail.

For a fully region resilient service, so to mirror the high availability provided by an internet gateway, then you need to deploy one NAT gateway in each AZ that you're using in the VPC and then have a route table for private subnets in that availability zone, pointing at the NAT gateway also in that availability zone.

So for every availability zone that you use, you need one NAT gateway and one route table pointing at that NAT gateway.

Now, they aren't super expensive, but it can get costly if you have lots of availability zones, which is why it's important to always think about your VPC design.

Now, NAT gateways are a managed service.

You deploy them and AWS handle everything else.

They can scale to 45 gigabits per second in bandwidth and you can always deploy multiple NAT gateways and split your subnets across multiple provision products.

If you need more bandwidth, you can just deploy more NAT gateways.

For example, you could split heavy consumers across two different subnets in the same AZ, have two NAT gateways in the same AZ and just route each of those subnets to a different NAT gateway and that would quickly allow you to double your available bandwidth.

With NAT gateways, you'll build based on the number that you have.

So there's a standard hourly charge for running a NAT gateway and this is obviously subject to change in a different region, but it's currently about four cents per hour.

And note, this is actually an hourly charge.

So partial hours are billed as full hours.

And there's also a data processing charge.

So that's the same amount as the hourly charge around four cents currently per gigabyte of processed data.

So you've got this base charge that a NAT gateway consumes while running plus a charge based on the amount of data that you process.

So keep both of those things in mind for any NAT gateway related questions in the exam.

Don't focus on the actual values, just focus on the fact they have two charging elements.

Okay, so this is the end of part one of this lesson.

It's getting a little bit on the long side, and so I wanted to add a break.

It's an opportunity just to take a rest or grab a coffee.

Part two will be continuing immediately from the end of part one.

So go ahead, complete the video, and when you're ready, join me in part two.

Welcome back.

In this lesson I want to talk in detail about security groups within AWS.

These are the second type of security filtering feature commonly used within AWS, the other type being network access control lists which we've previously discussed.

So security groups and knuckles share many broad concepts but the way they operate is very different and it's essential that you understand those differences and the features offered by security groups for both the exam and real-world usage.

So let's just jump in and get started.

In the lesson on network access control lists I explained that they're stateless and by now you know what stateless and stateful mean.

Security groups are stateful, they detect response traffic automatically for a given request and this means that if you allow an inbound or outbound request then the response is automatically allowed.

You don't have to worry about configuring ephemeral ports, it's all handled by the product.

If you have a web server operating on TCP 443 and you want to allow access from the public internet then you'll add an inbound security group rule allowing inbound traffic on TCP 443 and the response which is using ephemeral ports is automatically allowed.

Now security groups do have a major limitation and that's that there is no explicit deny.

You can use them to allow traffic or you can use them to not allow traffic and this is known as an implicit deny.

So if you don't explicitly allow traffic then you're implicitly denying it but you can't and this is important you're unable to explicitly deny traffic using security groups and this means that they can't be used to block specific bad actors.

Imagine you allow all source IP addresses to connect to an instance on port 443 but then you discover a single bad actor is attempting to exploit your web server.

Well you can't use security groups to block that one specific IP address or that one specific range.

If you allow an IP or if you allow an IP range or even if you allow all IP addresses then security groups cannot be used to deny a subset of those and that's why typically you'll use network access control lists in conjunction with security groups where the knuckles are used to add explicit denies.

Now security groups operate above knuckles on the OSI7 layer stack which means that they have more features.

They support IP and side-based rules but they also allow referencing AWS logical resources.

This includes all the security groups and even itself within rules.

I'll be covering exactly how this works on the next few screens.

Just know at this stage that it enables some really advanced functionality.

An important thing to understand is that security groups are not attached to instances nor are they attached to subnet.

They're actually attached to specific elastic network interfaces known as ENIs.

Now even if you see the user interface present this as being able to attach a security group to an instance know that this isn't what happens.

When you attach a security group to an instance what it's actually doing is attaching the security group to the primary network interface of that instance.

So remember security groups are attached to network interfaces that's an important one to remember for the exam.

Now at this point let's step through some of the unique features of security groups and it's probably better to do this visually.

Let's start with a public subnet containing an easy to instance and this instance has an attached primary elastic network interface.

On the right side we have a customer Bob and Bob is accessing the instance using HDTBS so this means TCP but 443.

Conceptually think of security groups as something which surrounds network interfaces in this case the primary interface of the EC2 instance.

Now this is how a typical security group might look.

It has inbound and outbound rules just like a network ACL and this particular example is showing the inbound rules allowing TCP port 443 to connect from any source.

The security group applies to all traffic which enters or leaves the network interface and because they're stateful in this particular case because we've allowed TCP port 443 as the request portion of the communication the corresponding response part the connection from the instance back to Bob is automatically allowed.

Now lastly I'm going to repeat this point several times throughout this lesson.

Security groups cannot explicitly block traffic.

This means with this example if you're allowing 0.0.0.0.0 to access the instance on port TCP port 443 and this means the whole IP version for internet then you can't block anything specific.

Imagine Bob is actually a bad actor.

Well in this situation security groups cannot be used to add protection.

You can't add an explicit deny for Bob's IP address.

That's not something that security groups are capable of.

Okay so that's the basics.

Now let's look at some of the advanced bits of security group functionality.

Security groups are capable of using logical references.

Let's step through how this works with a similar example to the one you just saw.

We start with a VPC containing a public web subnet and a private application subnet.

Inside the web subnet is the Categoram application web instance and inside the app subnet is the back-end application instance.

Both of these are protected by security groups.

We have A4L-web and A4L-app.

Traffic wise we have Bob accessing the web instance over port TCP port 443 and because this is the entry point to the application which logically has other users than just Bob we're allowing TCP port 443 from any IP version for address and this means we have a security group with an inbound rule set which looks like this.

In addition to this front-end traffic the web instance also needs to connect with the application instance and for this example let's say this is using TCP port 1337.

Our application is that good.

So how best to allow this communication?

Well we could just add the IP address of the web instance into the security group of the application instance or if you wanted to allow our application to scale and change IPs then we could add the side arrangers of the subnets instead of IP addresses.

So that's possible but it's not taking advantage of the extra functionality which security groups provide.

What we could do is reference the web security group within the application security group.

So this is an example of the application security group.

Notice that it allows TCP port 1337 inbound but it references as the source a logical resource the security group.

Now using a logical resource reference in this way means that the source reference of the A4L-web security group this actually references anything which has this security group associated with it.

So in this example any instances which have the A4L-web security group attached to them can connect to any instances which have the A4L-web security group attached to them using TCP port 1337.

So in essence this references this.

So this logical reference within the application security group references the web security group and anything which has the web security group attached to it.

Now this means we don't have to worry about IP addresses or side arrangers and it also has another benefit.

It scales really well.

So as additional instances are added to the application subnet and web subnet and as those instances are attached to the relevant security groups they're impacted by this logical referencing allowing anything defined within the security group to apply to any new instances automatically.

Now this is critical to understand so when you reference a security group from another security group what you're actually doing is referencing any resources which have that security group associated with them.

So this substantially reduces the admin overhead when you have multi-tiered applications and it also simplifies security management which means it's prone to less errors.

Now logical references provide even more functionality.

They allow self referencing.

Let's take this as an example a private subnet inside AWS with an ever-changing number of application instances.

Right now it's three but it might be three, thirty or one.

What we can do is create a security group like this.

This one allows incoming communications on port TCP 1337 from the web security group but it also has this rule which is a self-referential rule allowing all traffic.

What this means is that if it's attached to all of the instances then anything with this security group attached can receive communication so all traffic from this security group and this effectively means anything that also has this security group attached to it.

So it allows communications to occur to instances which have it attached from instances which have it attached.

It handles any IP changes automatically which is useful in these instances within an auto scaling group which is provisioning and terminating instances based on load on the system.

It also allows for simplified management of any intra-app communications.

An example of this might be Microsoft the main controllers or managing application high availability within clusters.

So this is everything I wanted to cover about security groups within AWS.

So there's a lot of functionality and intelligence that you gain by using security groups versus network ACLs but it's important that you understand that while network ACLs do allow you to explicitly deny traffic security groups don't and so generally you would use network ACLs to explicitly block any bad actors and use security groups to allow traffic to your VPC based resources.

You do this because security groups are capable of this logical resource referencing and that means AWS logical resources in security groups or even itself to allow this free flow of communications within a security group.

At this point that is everything I wanted to cover in this lesson so go ahead and complete the video and when you're ready I'll look forward to you joining me in the next lesson.

Welcome back and by now you should understand the difference between stateless and stateful security protection.

In this lesson I want to talk about one security feature of AWS VPCs and a little bit more depth and that's network access control lists known as knuckles.

Now we do have a lot to cover so let's jump in and get started.

A network access control list we thought of as a traditional firewall available within AWS VPCs so let's look at a visual example.

A subnet within an AWS VPC which has two EC2 instances A and B.

The first thing to understand and this is core to how knuckles work within AWS is that they are associated with subnets.

Every subnet has an associated network ACL and this filters data as it crosses the boundary of that subnet.

In practice this means any data coming into the subnet is affected and data leaving the subnet is affected.

But and this is super important to remember connections between things within that subnet such as between instance A and instance B in this example are not affected by network ACLs.

Each network ACL contains a number of rules, two sets of rules to be precise.

We have inbound rules and outbound rules.

Now inbound rules only affect data entering the subnet and outbound rules affect data leaving the subnet.

Remember from the previous lesson this isn't always matching directly to request and response.

A request can be either inbound or outbound as can a response.

These inbound and outbound rules are focused only on the direction of traffic not whether it's request or response.

In fact and I'll cover this very soon knuckles are stateless which means they don't know if traffic is request or response.

It's all about direction.

Now rules match the destination IP or IP range, destination port or port range together with the protocol and they can explicitly allow or explicitly deny traffic.

Remember this one network ACLs offer both explicit allows and explicit denies.

Now rules are processed in order.

First a network ACL determines if the inbound or outbound rules apply.

Then it starts from the lowest rule number.

It evaluates traffic against each individual rule until it finds a match.

Then that traffic is either allowed or denied based on that rule and then processing stops.

Now this is critical to understand because it means that if you have a deny rule and an allow rule which match the same traffic but if the deny rule comes first then the allow rule might never be processed.

Lastly there's a catch all showed by the asterisk in the rule number and this is an implicit deny.

If nothing else matches then traffic will be denied.

So those are the basics.

Next let's move on to some more complex elements of network ACLs.

Now I just mentioned that network ACLs are stateless and this means that rules are required for both the request and the response part of every communication.

You need individual rules for those so one inbound and one outbound.

Take this example a multi-tiered application running in a VPC.

We've got a web server in the middle and an application server on the left.

On the right we have a user Bob using a laptop and he's accessing the website.

So he makes a connection using HTTPS which is TCP port 443 and this is the request as you know by now and this is also going to mean that a response is required using the ephemeral port range.

This ephemeral port is chosen at random from the available range decided by the operating system on Bob's laptop.

Now to allow for this initial communication if we're using network ACLs then we'll need to have one associated with the web subnet and it will need rules in the inbound and outbound sections of that network ACL.

Notice how on the inbound rule set we have rule number 110 which allows connections from anywhere and this is signified by 0.0.0.0 through this network ACL and this is allowed as long as it's using TCP port 443.

So this is what allows the request from Bob into the web server.

We also have on the outbound rule set rule number 120 and this allows outbound traffic to anywhere again 0.0.0.0 as long as the protocol is TCP using the port range of 1.0.2.4 to 65.5.3.5 and this is the ephemeral port range which I mentioned in the previous lesson.

Now this is not amazingly secure but with stateless firewalls this is the only way.

Now we also have the implicit denies and this is denoted by the rules with the star in the rule number and this means that anything which doesn't match rule 110 or 120 is denied.

Now it's also worth mentioning while I do have rule 110 and 120 number differently the rule numbers are unique on inbound and outbound so we could have the single rule number 110 on both rule sets and that would be okay.

It's just easier to illustrate this if I use unique rule numbers for each of the different rule sets.

Now let's move on and increase the complexity little.

So we have the same architecture we have Bob on the right, the web subnet in the middle and the application subnet on the left.

You know now that because network ACLs are stateless each communication requires one request rule and one response rule.

This becomes more complex when you have a multi-tiered architecture which operates across multiple subnets and let's step through this to illustrate why.

Let's say the pop initiates a connection to the web server we know about this already because I just covered it.

If we have a network ACL around the web subnet we'll need an inbound rule on the web network ACL.

There's also going to be response traffic so this is going to use the ephemeral port range and this is going to need an outbound rule on that same web network ACL so this should make sense so far.

But also the web server might need to communicate with the app server using some application TCP port.

Now this is actually crossing two subnet boundaries the web at subnet boundary and the application subnet boundary so it's going to need an outbound rule on the web at subnet knuckle and also an inbound rule on the application subnet knuckle.

Then we have the response for that as well from the app server through to the web server and this is going to be using ephemeral ports but this also crosses two subnet boundaries it leaves the application subnet which will need an outbound rule on that knuckle and it enters the web subnet which will also need an inbound rule on that network ACL and what if each of those servers need software updates it will get even more complex really quickly.

You always have to be aware of these rule pairs the application port request and the ephemeral response for every single communication in some cases you're going to have multi-tier architecture and this might mean the communications go through different subnets.

If you need software updates this will need more if you use network address translation or NAT you might need more rules still.

You'll need to worry about this if you use network ACLs within a vpc for traffic to a vpc or traffic from a vpc or traffic between subnets inside that vpc.

When a vpc is created it's created with a default network ACL and this contains inbound and outbound rule sets which have the default implicit deny but also a capsule allow and this means that the net effect is that all traffic is allowed so the default within a vpc is that knuckles have no effect they aren't used this is designed [Music] I need to be beginner friendly and reduce admin overhead.

AWS prefer using security groups which I'll be covering soon.

If you create your own custom network ACLs though that's a different story.

Custom knuckles are created for a specific vpc and initially they're associated with no subnets.

They only have one rule on both the inbound and outbound rule sets which is the default deny and the result is that if you associate this custom network ACL with any subnets all traffic will be denied so be careful with this it's radically different behavior than the default network ACL created with a vpc.

Now this point I just want to cover some finishing key points which you need to be aware of for any real-world usage and when you're answering exam questions.

So network access controlists remember they're known as knuckles they are stateless so they view request and response as different things so you need to add rules both for the request and for the response.

A knuckle only affects data which is crossing the subnet boundary so communications between instances in the same subnet is not affected by a network ACL on that subnet.

Now this can mean that if you do have data crossing between subnets then you need to make sure that each knuckle on both of those subnets has the appropriate inbound and outbound rules so you end up with a situation where one connection can in theory need two rules on each knuckle if that connection is crossing two different subnet boundaries.

Now knuckles are able to explicitly allow traffic and explicitly deny and the deny is important because as you'll see when I talk about security groups this is a capability that you need to network ACLs.

So network ACLs allow you to block specific IPs or specific IP ranges which are associated with bad actors so they're a really good security feature when you need to block any traffic attempting to exploit your systems.

Now network ACLs are not aware of any logical resources they only allow you to use IPs and cyber ranges ports and protocols you cannot reference logical resources within AWS and knuckles can also not be assigned two logical resources they're only assigned to subnets within VPCs within AWS.

Now knuckles are very often used together with security groups such as mentioned to add the capability to explicitly deny bad IPs or bad networks so generally you would use security groups to allow traffic and you use knuckles to deny traffic and I'll talk about exactly how this works in the next lesson.

Now each subnet within a VPC has one knuckle associated with it it's either going to be the default network ACL for that VPC or a custom one which you create and associate.

A single knuckle though can be associated with many different subnets so while a subnet can only have one network ACL one network ACL can be associated with many different subnets.

Now this point that is everything that I wanted to cover about network ACLs for this lesson so go ahead complete the video and when you're ready I'll look forward to you joining me in the next lesson.

Welcome back.

In this lesson, I want to introduce the term "service models", specifically "cloud service models".

If you've ever heard or seen the term something as a service or x-a-a-s, then this is generally a cloud service model, and that's what I want to cover in this lesson.

Before I start, there are a few terms I'd like to introduce, which will make the rest of this lesson make more sense as well as being helpful throughout the course.

If you already know these, then that's fine.

It will just be a refresher.

But if these are new, then it's important to make sure you understand all these concepts because they're things that underpin a lot of what makes the cloud special.

Now, when you deploy an application anywhere, it uses what's known as an infrastructure stack.

An infrastructure stack is a collection of things, which that application needs, all stack on to each other.

Starting at the bottom, everything runs inside a facility, which is a building with power, with aircon, with physical security.

Everything uses infrastructure, so storage and networking.

An application generally requires one or more physical service.

These servers run virtualization, which allows them to be carved up into virtual machines.

These virtual machines run operating systems.

They could potentially run containers.

An example of this is Docker.

Don't worry if you don't know what these are, I'll be covering them later in the course.

Every application is written in a language such as Python, JavaScript, C, C++, C#, and all of these have an environment that they need to run in.

This is called a runtime environment.

An application needs data to work on, which it creates or consumes.

And then at the very top is the application itself.

Now, all of this together is an infrastructure stack or an application stack.

If you use Netflix or Office 365 or Slack or Google or your online bank or this very training site, it has parts in each of these tiers.

Even the application that you're using right now to watch this training is running on an operating system, which is running itself on a laptop, a PC or a tablet, which is just hardware.

The hardware uses infrastructure, your internet connection, and this runs in facilities, so your house or a coffee shop.

With any implementation of this stack, there are parts of the stack that you manage and there are parts of the stack which are managed by the vendor.

So if you're working in a coffee shop, they'll have specific people to manage the building and the internet connection, and that's probably not you.

But it's more likely that you are responsible for your laptop and the operating system running on top of it.

Now, this is true for any system.

Some parts you manage, some parts some people else manages.

You don't manage any part of Netflix, for example.

Netflix is an entity, manage everything end to end.

But if you do work in IT, then maybe you do manage all of the IT infrastructure stack or some parts of it.

The last term that I want to introduce is what's known as the unit of consumption.

It's what you pay for and it's what you consume.

It's the part of the system where from that point upwards in the infrastructure stack, you are responsible for management.

For example, if you procure a virtual server, then your unit of consumption is the virtual machine.

A virtual machine is just an operating system and an allocation of resources.

So your unit of consumption is the operating system.

In AWS, if you create a virtual machine known as an instance, then you consume the operating system.

If you use Netflix, though, then you consume the service and that's it.

You have no involvement in anything else.

The unit of consumption is what makes each service model different.

So let's take a look.

With an on-premise system, so that's one which is running in a building that your business owns, your business has to buy all parts of the stack.

It has to manage them all, pay for the upkeep and running costs of all of them.

And it has to manage the staff costs and risks associated with every single part of that stack.

Now, because it owns and controls everything, while it's expensive and it does carry some risks, it's also very flexible.

In theory, you can create systems which are tailor-made for your business.

Now, before cloud computing became as popular as it is now, it was possible to use something called data center hosting.

Now, this is similar to on-premises architectures, but when you use data center hosting, you place your equipment inside a building which is owned and managed by a vendor.

This meant that the facilities were owned and controlled by that vendor.

You as a business consumed space in that facility.

Your unit of consumption was a rack space.

If you rented three racks from a data center provider, they provided the building, the security, the power, the air conditioning and the staffing to ensure the service you paid for was provided.

All of the service models we use today are just evolutions of this type of model where more and more parts of the stack are handed off to a vendor.

Now, the cost change, the risks that are involved change and the amount of flexibility you have changed, but it's all the same infrastructure stack just with different parts being controlled by different entities.

So let's look at this further.

The first cloud service model that I want to talk about is infrastructure as a service or IaaS.

With this model, the provider manages the facilities, the storage and networking, the physical server and the virtualization and you consume the operating system.

Remember, a virtual machine is just an operating system with a certain amount of resources assigned.

It means that you still have to manage the operating system and anything above the operating system so any containers, the runtime, the data and your applications.

So why use IaaS as a service model?

With IaaS, you generally pay per second, per minute per hour fee for the virtual machine.

You pay that fee when you use that virtual machine and you don't pay when you don't use it.

The costs associated with managing a building, procuring and maintaining infrastructure and hardware and installing and maintaining a virtualization layer are huge and they're all managed by the vendor.

The vendor needs to purchase things in advance, pay licenses, pay staff to keep things running and manage the risks of data loss, hardware failure and a wealth of other things.

Using IaaS means that you can ignore all of those and let the vendor manage them.

IaaS is one of the most popular cloud service models.

Now, you do lose a little bit of flexibility because you can only consume the virtual machine sizes and capabilities that the provider allows, but there is a substantial cost reduction because of that.

In AWS, a product called Elastic Compute Cloud or EC2 uses the IaaS service model.

So in summary, IaaS is a great compromise.

You do lose a little bit in terms of flexibility, but there are substantial costs and risk reductions.

Okay, so let's move on.

Another popular service model is Platform as a Service or Pass.

Now, this service model is aimed more at developers who have an application they just want to run and not worry about any of the infrastructure.

With Pass, your unit of consumption is the runtime of the runtime environment.

So if you run a Python application, you pay for a Python runtime environment.

You give the vendor some data and your application and you put it inside this runtime environment and that's it.

You manage your application and its data and you consume the runtime environment, which effectively means that the provider manages everything else, containers, operating system, virtualization, service, infrastructure and facilities.

Now, let's review one final service model before we finish this lesson.

The final service model is Software as a Service or SaaS.

And with SaaS, you consume the application.

You have no exposure to anything else.

You pay a monthly fee for consuming the application.

You get it as a service.

Now, examples of SaaS products include Netflix, Dropbox, Office 365, Flickr, even Google Mail.

Businesses consume SaaS products because they are standard known services.

Email is email.

One email service is much like another.

And so a business can save significant infrastructure costs by consuming their email service as a SaaS solution.

They don't have much control of exactly how the email services can be configured, but there are almost no risks or additional costs associated with procuring a SaaS service.

IaaS, SaaS and SaaS are examples of cloud service models.

Now, there are others such as Function as a Service, known as SaaS, Container as a Service, Database as a Service or DBAAS, and there are many more.

For this lesson, the important points to understand are that the infrastructure stack exists in every service and application that you use.

The part of the stack is managed by you.

The part of the stack is managed by the provider.

And for every model, there is part of the stack which you consume, your unit of consumption.

That's the part that you pay for and generally the part that delineates between where the vendor manages and where you manage.

Now, again, I know this has been a fairly theory heavy lesson, but I promise you it will be invaluable as you go through the course.

Thanks for listening.

Go ahead, complete this video.

And when you're ready, join me in the next.

In this lesson, I want to cover theoretical topic which is really important to me personally, and something that I think is really valuable to understand.

That is, what is multi- and hybrid Cloud, and how do they relate to private and public Cloud platforms?

Now, why this matters is because AWS Azure and the Google Cloud Platform, they're all offering private Cloud environments which can be used in conjunction with their public Clouds.

So to be able to pick when and where to use them effectively, you need to understand when something is multi-Cloud and when it's hybrid Cloud because these are very different things.

So let's jump in and get started.

In the previous lesson, I covered the formal definition of Cloud computing.

Now, I know this was a very dry theoretical lesson, but hopefully you've come out of that understanding what a Cloud environment is.

Now, public Cloud, simply put, is a Cloud environment that's available to the public.

Many vendors are currently offering public Cloud platforms including AWS, Microsoft Azure, and Google Cloud.

These are all examples of public Cloud platforms.

They're public Cloud because they meet the five essential characteristics of Cloud computing and that they're available to the general public.

So to be public Cloud, it needs to first classify as a Cloud environment and then it needs to be available to the general public.

Now, you can if you have very specific needs or if you want to implement something which is highly available, you can choose to use multiple public Cloud platforms in a single system.

Now, that's known as multi-Cloud.

So multi-Cloud is using multiple Cloud environments and the way that you implement this can impact how successful it is.

Now, keeping things simple, you could choose to implement a simple mirrored system.

One part of your system could be hosted inside AWS and the other in Azure.

This means that you've got Cloud provider level resilience.

If one of these vendors fails, you'll know that at least part of your system will remain fully functional and running in the other.

Now, with regards to multi-Cloud, I would personally stay away from any products or vendors who attempt to provide a so-called single management window or single pane of glass if you want to use the jargon when using multiple Cloud platforms.

It is possible to manage multiple Cloud platforms as one single environment, but while it is possible, it abstracts away from these individual environments, relying on the lowest common feature set.

And so you do lose a lot of what makes each vendor special and unique.

So in this example, I could pick AWS and Azure.

I could abstract away from that using a third-party tool.

And when I wanted to provision a virtual machine, that tool would select which Cloud vendor to use.

The problem with that is that it would have to assume a feature set which is available in both of them.

So if AWS had any features that weren't available in Azure or vice versa, this third-party tool could not utilize them while staying abstracted away.

So that's a really important thing to understand.

Generally, when I'm thinking about multi-Cloud environments, I'm looking at it from a highly available perspective.

So putting part of my infrastructure in one and part in another.

It's much simpler and generally much more effective.

Now, each of these three Cloud vendors also offers a solution which can be dedicated to your business and run from your business premises.

This is a so-called private Cloud.

Now, for AWS, this is called AWS Outposts.

For Azure, it's the Azure Stack.

And for Google, it's Anthos.

Now, I want to make a very special point of highlighting that there is a massive difference between having on-premises infrastructure, such as VMware, Hyper-V, or Zen Server, versus having a private Cloud.

A private Cloud still needs to meet the five essential characteristics of Cloud computing, which most traditional infrastructure platforms don't.

So private Cloud is Cloud computing, which meets these five characteristics, but which is dedicated to you as a business.

So with VMware, Hyper-V, or Zen Server implementation, they're not necessarily private Cloud.

A lot of these platforms do have private Cloud-like features, but in general, the only environments that I consider true private Cloud are Outposts, the Azure Stack, and Google Anthos.

Now, it is possible to use private Cloud in conjunction with public Cloud.

And this is called hybrid Cloud.

It's hybrid Cloud only if you use a private Cloud and a public Cloud, cooperating together as a single environment.

It's not hybrid Cloud if you just utilize a public environment such as AWS together with your on-premises equipment.

Now, to add confusion, you might hear people use the term hybrid environment.

And in my experience, people use hybrid environment to refer to the idea of public Cloud used together with existing on-premises infrastructure.

So I'm going to try throughout this course to have separate definitions.

If I use the terms hybrid environment or hybrid networking, then that's different.

That simply means connecting a public Cloud environment through to your on-premises or data-center-based traditional infrastructure.

So there's a difference between hybrid Cloud, which is a formal definition, and then hybrid environment or hybrid networking.

So try and separate those and understand what's meant by age.

With true hybrid Cloud, you get to use the same tooling, the same interfaces, the same processes to interact with both the public and private components.

So let's summarize this.

Public Cloud means to use a single public Cloud environment such as AWS, Azure, or Google Cloud.

Private Cloud is to use on-premises Cloud.

Now, this is important.

This is one of the most important distinctions to make.

For it to be private Cloud, you need to be using an on-premises real Cloud product.

It needs to meet those five essential characteristics.

Multi Cloud means using more than one public Cloud.

So an example of this might be AWS and Azure, or AWS, Azure and Google.

They're examples of a multi Cloud deployment.

So using multiple public Clouds in one deployment, that's a multi Cloud environment.

And I mentioned that earlier in the lesson, that can be as simple as deploying half of your infrastructure to one public Cloud and half to the other, or using a third party tool that abstracts away from a management perspective.

But I would not recommend any abstraction or any third party tools.

Generally, in my experience, the best multi Cloud environments are those which use part of your infrastructure in one Cloud environment and part in the other.

Hybrid Cloud means utilizing public and private Clouds, generally from the same vendor, together as one unified platform.

And then lastly, and probably personally one of the most important points to me, Hybrid Cloud is not utilizing a public Cloud like AWS and connecting it to your legacy on-premises environment.

That is a hybrid environment or a hybrid network.

Hybrid Cloud is a very specific thing.

And I'm stressing this because it is important now to be an effective solutions architect.

You need to have a really good distinction between what public Cloud, private Cloud, multi Cloud, hybrid Cloud and hybrid environments are.

Understand all of those separate definitions.

Now that's all I wanted to cover in this lesson.

I hope it wasn't too dry.

I really do want to make sure that you understand all of these terms on a really foundational level because I think they're really important to be an effective solutions architect.

So go ahead, complete this lesson and then when you're ready, I'll see you in the next.

In this lesson, I want to introduce Cloud Computing.

It's a phrase that you've most likely heard, and it's a term you probably think you understand pretty well.

Cloud Computing is overused, but unlike most technical jargon, Cloud Computing actually has a formal definition, a set of five characteristics that a system needs to have to be considered cloud, and that's what I want to talk about over the next few minutes in this lesson.

Understanding what makes Cloud 4 Cloud can help you understand what makes Cloud special and help you design cloud solutions.

So let's jump in and get started.

Now because the term Cloud is overused, if you ask 10 people what the term means, you'll likely get 10 different answers.

What's scary is that if those 10 individuals are technical people who work with Cloud day to day, often some of those answers will be wrong.

Because unlike you, these people haven't taken the time to fully understand the fundamentals of Cloud Computing.

To avoid ambiguity, I take my definition of Cloud from a document created by NIST, a NIST at the National Institute of Standards and Technology, which is part of the US Department of Commerce.

NIST creates standards documents, and one such document is named Special Publication 800-145, which I've linked in the lesson text.

The document defines the term Cloud.

It defines five things, five essential characteristics, which a system needs to meet in order to be cloud.

So AWS, Azure, and Google Cloud, they all need to meet all five of these characteristics at a minimum.

They might offer more, but these five are essential.

Now some of these characteristics are logical, and so they may surprise you.

So I've added a couple of things to the document, and I've added a couple of things to the document, and even though you and other business are probably sharing physical hardware, you would never know each other existed, and that's one of the benefits of Boolean.

But on to characteristic number four, which is rapid elasticity.

The NIST document defines this as capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly, outward, and inward, commensurate with demand.

To the consumer, the capabilities available for provisioning often appear to be unlimited, and can be appropriated in any quantity at any time.

Now I simplify this again into two points.

First, capabilities can be elastically provisioned and released to scale rapidly, outward and inward with demand, and in this case, capabilities are just resources.

And second, to the consumer, the capabilities available for provisioning often appear to be unlimited.

Now when most people think about scaling in terms of IT systems, they see a system increasing in size based on organic growth.

Elasticity is just an evolution of that.

A system can start off small, and when system load increases, the system size increases.

But, crucially, with elasticity, when system load decreases, the system can reduce in size.

It means that the cost of a system increases as demand increases, and the system scales, and decrease as demand drops.

Rapid elasticity is this process but automated, so the scaling can occur rapidly in real time with no human interaction.

Cloud vendors need to offer products and features, which monitor load, and allow automated provisioning and termination as load increases and decreases.

Now most businesses won't care about increased system costs.

If, for example, during sale periods, their profits increase, and because the system scales, along with that increased load and increased profits, the customers are kept happy.

Elasticity means that you don't have to, and indeed can't over provision, because over provisioning weighs money.

It also means that you can't under provision and experience performance issues for your customers.

It's how a company like Amazon.com or Netflix can easily handle holiday sales, or handle the load generated on the latest episode of Game of Thrones' release.

The second part is related to that.

A cloud environment shouldn't let you see capacity limits.

If you need 100 virtual machines or 1000, you should be able to get access to them immediately when required.

In the background, the provider is handling the capacity in a pooled way, but from your perspective, you should never really see any capacity limitations.

Now this is, in my opinion, the most important benefit of cloud, systems which scale in size in response to load.

So this is a really important one to make sure that a potential cloud environment offers in order to make sure that it is actually cloud.

Okay, let's move on to the final characteristic, and that's measured service.

Now this document defines this as cloud systems automatically control and optimize resource use by leveraging and metering capability at some level of abstraction appropriate to the type of service.

And it says that resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the service.

Now my simplified version of this is that resource usage can be monitored, controlled, reported, and built.

Traditional and non-cloud infrastructure work to using capex.

You pay for service and hardware in advance.

In the beginning, you had more capacity than you needed, so money was wasted.

Your demand grew over time, and eventually you purchased more service to cope with the demand.

If you did that too slowly, you had performance issues or failures.

With a true cloud environment, it offers on-demand billing.

Your usage is monitored on a constant basis.

You pay for that usage.

This might be a certain amount per second, a minute, an hour, or per day usage of a certain service, for example virtual machines.

Or it could be a certain cost for every gigabyte you store on a storage service for a given month.

You generally pay nothing in advance if it truly is a cloud platform.

If you consume a virtual server for a month, but then for 30 minutes at that month you use 100 virtual servers, then you should pay a small amount for the month and a much larger amount just for that 30 minutes.

Legacy vendors will generally want to feed or buy or lease a server.

If this is the case, they aren't cloud, and they probably don't support some of the massively flexible architectures the cloud allows you to build.

With that being said, that is everything I wanted to cover, so go ahead, complete this video, and when you're ready, I'll join you in the next.

Welcome back.

In a previous video I talked about YAML, which is a method of storing and passing data which is human readable.

In this video I want to cover JSON, which is the JavaScript object notation.

Let's jump in and take a quick look and note that many of the topics which I covered in the YAML video also apply here.

With conveying the same information, the format to do so is just different.

So unfortunately we have another mouthful of definition incoming.

So JSON, or the JavaScript object notation, is a lightweight data interchange format.

It's easy for humans to read and write and it's easy for machines to pass and generate.

That's what it says, but there are a few differences that you should be aware of before we move on.

JSON doesn't really care about indentation because everything is enclosed in something, so braces or brackets.

Because of this it can be much more forgiving regarding spacing and positioning.

And secondly because of that, JSON can appear initially harder to read.

But over time I've come to appreciate the way that JSON lays out the structure of its documents.

Now there are two main elements that you need to understand if you want to be competent with JSON.

First, an object or a JSON object.

And this is an unordered set of key value pairs enclosed by curly brackets.

Now from when you watched the YAML video, you should recognise this as a dictionary.

It's the same thing, but in JSON it's called an object.

The second main element in JSON is an array which is an ordered collection of values separated by commas and enclosed in square brackets.

Now from the YAML video you might recognise this as a list.

It's again the same thing, only in JSON it's called an array.

Now in both cases, arrays which are lists of values or objects which are collections of key value pairs, the value can be a string, an object, a number, an array, boolean, true or false, or finally null.

Now with these two high level constructs in mind, let's move on.

So this is an example of a simple JSON document.

Notice how even at the top level there are these curly brackets.

This shows that at the top level a JSON document is simply a JSON object, a collection of key value pairs separated by a colon.

In this example we have three keys.

We have cats, colours and finally, num of eyes.

And each key has a corresponding value in this example which is an array.

The top level key value pair has a value containing an array of cat names.

The middle has a value which is an array of the colour of the cats.

And then the last key value pair has a value which is a list of the number of eyes which each cat has.

Now JSON documents aren't limited to just arrays.

They can be much more complicated like this example.

Now this is a JSON document and every JSON document starts with a top level object, which is an unordered list of key value pairs surrounded by curly brackets.

This object has four key value pairs.

The keys are ruffle, truffles, penny and winky.

The value of each key is a JSON object, a collection of key value pairs.

So JSON objects can be nested within JSON objects, arrays can be ordered lists of JSON objects, which themselves can contain JSON objects.

And again, this lets you create complex structures which can be used by applications to pass or store data and configuration.

Now I'll admit it, I'm actually a fan of JSON.

I think it's actually easier to write and read than YAML.

Many people will disagree and that's fine.

With that being said though, that's everything that I wanted to cover in this video.

So go ahead and complete the video and when you're ready, I'll look forward to you joining me in the next.

Welcome to this video which will be a fairly high level introduction to YAML.

Now YAML stands for YAML 8 Markup Language and for any key observers that's a recursive acronym.

Now I want this video to be brief but I think it's important that you understand YAML's structure.

So let's jump in and get started.

YAML is a language which is human readable and designed for data serialization.

Now that's a mouthful but put simply it's a language for defining data or configuration which is designed to be human readable.

At a high level a YAML document is an unordered collection of key value pairs separated by a colon.

It's important that you understand this lack of order.

At this top level there is no requirement to order things in a certain way.

Although there may be conventions and standards none of that is imposed by YAML.

An example key value pair might be the key being cat1 and the value being raffle.

One of my cats in this example both the key and the value are just normal strings.

We could further populate our YAML file with a key of cat2 and a value of truffles and other cat of mine.

Or a key of cat3 and a value of penny and a key of cat4 and a value of winkey.

These are all strings.

Now YAML supports other types numbers such as one and two, floating point values such as 1.337, boolean so true or false and even null which represents nothing.

Now YAML also supports other types and one of those are lists known as arrays or other names depending on what if any programming languages that you're used to.

A list is essentially an ordered set of values and in YAML we can represent a list by having a key let's say Adrian's cats.

And then as a value we might have something that looks like this, a comma separated set of values inside swear brackets.

Now this is known as inline format where the list is placed where you expect the value to be after the key and the colon.

Now the same list can also be represented like this where you have the key and then a colon and then you go to a new line and each item in the list is represented by hyphen and then the value.

Now notice how for some of the values are actually enclosed in speech marks or quotation marks and so on.

This is optional.

All of these are valid.

Often though it's safe for you to enclose things as it allows you to be more precise and it avoids confusion.

Now in YAML indentation really matters.

Indentation is always done using spaces and the same level of indentation means that the things are within the same structure.

So we know that because all of these list items are indented by the same amount they're all part of the same list.

We know they're a list because of the hyphens.

So same indent always using hyphens means that they're all part of the same list, same structure.

Now these two styles are two methods for expressing the same thing.

A key called Adrian's cats whose value is a list.

This is the same structure.

It represents the same data.

Now there's one final thing which I want to cover with YAML and that's a dictionary.

A dictionary is just a data structure.

It's a collection of key value pairs which are unordered.

A YAML template has a top level dictionary.

It's a collection of key value pairs.

So let's look at an example.

Now this looks much more complicated but it's not if you just follow it through from the start.

So we start with a key value pair.

Adrian's cats at the top.

So the key is Adrian's cats and the value is a list.

And we can tell that it's a list because of the hyphens which are the same level of indentation.

But, and this is important, notice how for each list item we don't just have the hyphen and a value.

Instead we have the hyphen and for each one we have a collection of key value pairs.

So for the final list item at the bottom we have a dictionary containing a number of key value pairs.

The first has a key of name with a value of winky.

The second a key color with a value of white.

And then for this final list item a key, num of eyes and a value of one.

And each item in this list, each value is a dictionary.

A collection of one or more key value pairs.

So values can be strings, numbers, floats, booleans, lists or dictionaries or a combination of any of them.

Note how the color key value pair in the top list item, so the raffle dictionary at the top, its value is a list.

So this structure that's on screen now, we have Adrian's cats which are a value, has a list.

Each value in the list is a dictionary.

Each dictionary contains a name, key, with a value, a color key, with a value.

And then the third item in the list also has a num of eyes key and a value.

Now using YAML key value pairs, lists and dictionaries allows you to build complex data structures in a way which once you have practice is very human readable.

In this case, it's a database of somebody's cats.

Now YAML can be read into an application or written out by an application.

And YAML is commonly used for the storage and passing of configuration.

For now thanks for watching, go ahead, complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome to this video where I'm going to step through two concepts which I think should be mandatory knowledge for any solutions architect.

And for anyone else working in IT, these are also really useful.

First we have recovery point objective known as RPO and recovery time objective known as RTO.

Generally if you're a solutions architect helping a client, they will give you their required values for both of these.

In some cases you might need to work with key stakeholders within the business to determine appropriate values.

In either case if you get them wrong it can have a massive negative consequence to a business.

Let's jump in and get started.

I'm going to start by stepping through recovery point objective or RPO.

Recovery point objective or RPO is something that's generally expressed in minutes or hours.

And I'll illustrate this, let's say a given 24 hour period.

It starts on the left and midday, moves through midnight in the middle and finishes at 12 midday on the following day on the right.

I will need to consider an animal rescue business who have animals arriving to be fostered 24/7/365.

They have intake, vet exams and data restored within on-premises systems which need to be referred to constantly throughout the day.

At a certain point in time let's say 2am we have a server failure.

And for this example let's assume this is a single server which stores all the data for the organization and they have no redundancy.

Now this is a terrible situation but it's all too common for cash-strapped charities.

So remember, donate to your local animal rescue centre.

RPO is defined as the maximum amount of data and this is generally expressed in time that can be lost during a disaster recovery situation before that loss will exceed what the organization can tolerate.

If an organization tells you that they have an RPO of 6 hours, it means the organization cannot tolerate more than 6 hours of data loss when recovering from a disaster like this server failure.

Now different organizations will have different RPO values.

Banks logically will be able to tolerate although some know data loss because they deal with customer money.

Whereas an online store might be able to tolerate some data loss as they can in theory recreate orders in other ways.

Understanding how data can be lost during disaster recovery scenarios is key to understanding how to implement a given RPO requirement.

Let's consider this scenario that every 6 hours starting at 3pm on day 1 the business takes a full backup of the server which has failed.

So normally we have a backup at 3pm, one at 9pm, one at 3am and one at 9am.

So 4 backups every 24 hour period split by 6 hours.

In order to recover data from the failed server we need to restore a backup.

Ideally assuming that we have no failures it will be from the most recent backup.

Now successful backups are known as recovery points.

In the case of full backups each successful backup is one recovery point.

If you use full backups and incremental backups it's possible that to restore a single incremental backup, i.e. to use that one recovery point you'll need the most recent full backup and every incremental backup between that full and the most recent okay incremental backup.

So it's possible that a recovery point will need more than one backup.

With this scenario so the server failure at 2am the data loss will be the time between 2am and the most recent recovery point.

In this case 9pm at the previous day.

So this represents 5 hours of lost data.

If the failure occurred right after the 9pm backup had finished we'd have almost no data loss.

If the failure occurred one hour later at 3am we would have 6 hours of data loss.

Now the maximum loss of data for this type of scenario is the time between 2 successful backups.

In our case because backups occur every 6 hours then data loss could be a minimum of 0 if the server failure occurred right after the first backup finished or a maximum of 6 hours if the server failure occurred right before the next scheduled backup.

So when an organisation informs you that they have a requirement for an RPO of 6 hours they're telling you that they can only tolerate a maximum of 6 hours of data loss in a disaster scenario.

And as a general rule this means that you need to make sure that backups occur as often or more often than the RPO value provided by the organisation.

An RPO of 6 hours means at minimum a backup every 6 hours but to cope with random backup failure generally you'll want to make sure backups occur more frequently than required.

So in this example maybe once every 3 hours or maybe even once an hour.

Lower RPOs generally require more frequent backups which historically has resulted in higher cost for backup systems both in terms of media which also licensing, management overhead and other associated processes.

So RPO is a value which is generally given to you by an organisation or you might have to work with an organisation to identify an appropriate value and it states how much maximum loss of data in time the business can tolerate.

Different businesses will have different RPOs and sometimes even different RPOs for different systems within a single organisation.

A bank might have super low RPOs for its financial systems but it might tolerate a much higher one for its website.

If data changes less frequently the system is less important then higher RPO values are easier to tolerate for a business.

Now let's move on and cover recovery time objective or RTO.