Welcome back and in this lesson I want to cover IPsec fundamentals.

So I want to talk about what IPsec is, why it matters and how IPsec works at a fundamental level.

Now we have a lot of theory to cover so let's jump in and get started.

At a foundational level IPsec is a group of protocols which work together.

Their aim is to set up secure networking tunnels across insecure networks.

For example, connecting two secure networks or more specifically their routers called PIRS across the public internet.

Now you might use this if you're a business with multiple sites spread around geographically and want to connect them together.

Or if you have infrastructure in AWS or another cloud platform and want to connect to that infrastructure.

IPsec provides authentication so that only PIRS which are known to each other and can authenticate with each other can connect.

And any traffic which is carried by the IPsec protocols is encrypted which means to unlockers the secure data which has been carried is ciphertext.

It can't be viewed and it can't be altered without being detected.

Now architecturally it looks like this.

We have the public internet which is an insecure network full of goblins looking to steal your data.

Over this insecure network we create IPsec tunnels between PIRS.

Now these tunnels exist as they're required.

Within IPsec VPNs there's the concept of interesting traffic.

Now interesting traffic is simply traffic which matches certain rules.

And these could be based on network prefixes or match more complex traffic types.

Regardless of the rules if data matches any of those rules it's classified as interesting traffic.

And a VPN tunnel is created to carry traffic through to its destination.

Now if there's no interesting traffic then tunnels are eventually torn down only to be reestablished when the system next detects interesting traffic.

The key thing to understand is that even though those tunnels use the public internet for transit any data within the tunnels is encrypted while transiting over that insecure network.

It's protected.

Now to understand the nuance of what IPsec does we need to refresh a few key pieces of knowledge.

In my fundamental section I talked about the different types of encryption.

I mentioned symmetric and asymmetric encryption.

Now symmetric encryption is fast.

It's generally really easy to perform on any modern CPU and it has pretty low overhead.

But exchanging keys is a challenge.

The same keys are used to encrypt and decrypt.

So how can you get the key from one entity to another securely?

Do you transmit it in advance over a different medium or do you encrypt it?

If so you run into a catch-22 situation how do you securely transmit the encrypted key?

That's why asymmetric encryption is really valuable.

Now it's slower so we don't want to be using it all the time.

But it makes exchanging keys really simple because different keys are used for encryption and decryption.

Now a public key is used to encrypt data and only the corresponding private key can decrypt that data.

And this means that you can safely exchange the public key while keeping the private key private.

So the aim of most protocols which handle the encryption of data over the internet is to start with asymmetric encryption.

Use this to securely exchange symmetric keys and then use those for ongoing encryption.

Now I mentioned that because it will help you understand exactly how IPsec VPN works.

So let's go through it.

IPsec has two main phases.

If you work with VPNs you're going to hear a lot of talk about phase one or phase two.

It's going to make sense why these are needed by the end of this lesson.

But understand there are two phases in setting up a given VPN connection.

The first is known as Ike phase one.

Ike or internet key exchange as the name suggests is a protocol for how keys are exchanged in this context within a VPN.

There are two versions.

Ike version one and Ike version two.

Version one logically is older.

Version two is newer and comes with more features.

Now you don't need to know all the detail right now.

Just understand that the protocol is about exchanging keys.

Ike phase one is the slow and heavy part of the process.

It's where you initially authenticate using a pre-shared key.

So a password of sorts or a certificate.

It's where asymmetric encryption is used to agree on, create and share symmetric keys which are used in phase two.

The end of this phase is what's known as an Ike phase one tunnel or a security association known as an SA.

There's lots of jargon being thrown around and I'll be showing you how this all works visually in just a moment.

But at the end of phase one you have a phase one tunnel and the heavy work of moving towards symmetric keys which can be used for encryption has been completed.

The next step is Ike phase two which is faster and much more agile because much of the heavy lifting has been done in phase one.

Technically the phase one keys are used as a starting point for phase two.

Phase two is built on top of phase one and is concerned with agreeing encryption methods and the keys used for the bulk transfer of data.

The end result is an IPsec security association, a phase two tunnel which runs over phase one.

Now the reason why these different phases are split up is that it's possible for phase one to be established, then a phase two tunnel created, used and then torn down when no more interesting traffic occurs, but the phase one tunnel stays.

It means that establishing a new phase two tunnel is much faster and less work.

It's an elegant and well designed architecture.

So let's look at how this all works together visually.

So this is Ike phase one.

The architecture is a simple one.

Two business sites, site one on the left with the user Bob and site two on the right with the user Julie and in the middle the public internet.

The very first step of this process is that the routers, the two peers at either side of this architecture need to authenticate, essentially prove their identity which is done either using certificates or pre-shared keys.

Now it's important to understand that this isn't yet about encryption, it's about proving identity, proving that both sides agree that the other side should be part of this VPN.

No keys are exchanged, it's just about identity.

Once the identity has been confirmed then we move on to the next stage of Ike phase one.

In this stage we use a process called Diffie-Hellman Key Exchange.

Now again, I'm sorry about the jargon but try your best to remember Diffie-Hellman known as DH.

What happens is that each side creates a Diffie-Hellman private key.

This key is used to decrypt data and to sign things.

You should remember this from the encryption fundamentals lesson.

In addition, each side uses that private key and derives a corresponding public key.

Now the public key can be used to encrypt data that only that private key can decrypt.

So at this point each side has a private key as well as a corresponding public key.

At this point these public keys are exchanged.

So Bob has Julie's public key and Julie has Bob's public key.

Remember these public keys are not sensitive and can only be used normally to encrypt data for decryption by the corresponding private key.

The next stage of the process is actually really complicated mathematics but at a fundamental level each side takes its own private key and the public key of the other side and uses this to derive what's known as the Diffie-Hellman key.

The Diffie-Hellman key is the same at both sides but it's been independently generated.

Now again the maths is something that's well beyond this lesson but it's at the core of how this phase of VPN works.

And at this point it's used to exchange other key material and agreements.

This part you can think of as a negotiation.

The result is that each side again independently uses this DH key plus the exchanged key material to generate a final phase one symmetrical key.

This key is what's used to encrypt anything passing through the phase one tunnel known as the Ike Security Association.

Now if that process seems slow and heavy that's because it is.

It's both complex and in some ways simplistically elegant at the same time but it means that both sides have the same symmetric key without that ever having been passed between them.

And the phase ends with this security association in place and this can be used at phase two.

So let's talk about that next.

So in phase two we have a few things.

First a DH key on both sides and the same phase one symmetric key also on both sides and then finally the established phase one tunnel.

During this phase both of the peers are wanting to agree how the VPN itself will be constructed.

The previous phase was about allowing this exchanging keys and allowing the peers to communicate.

This phase so Ike phase two is about getting the VPN up and running being in a position to encrypt data.

So agreeing how when and what.

So the first part of this is that the symmetric key is used to encrypt and decrypt agreements and pass more key material between the peers.

The idea is that one peer is informing the other about the range of Cypher suites that it supports basically encryption methods which it can perform.

The other peer in this example the right one will then pick the best shared one.

So the best method which it also supports and it will let the left peer know and this becomes the agreed method of communication.

Next the DH key and the key material exchanged above is used to create a new key a symmetrical IP sec key.

This is a key which is designed for large scale data transfer.

It's an efficient and secure algorithm and the specific one is based on the negotiation which happened above in steps one and two of this phase.

So it's this key which is used for the encryption and decryption of interesting traffic across the VPN tunnel.

Across each phase one tunnel you actually have a pair of security associations one from right to left and one from left to right.

And these are the security associations which are used to transfer the data between networks at either side of a VPN.

Now there are actually two different types of VPN which you need to understand policy based VPNs and route based VPNs.

The difference is how they match interesting traffic.

Remember this is the traffic which gets sent over a VPN.

So with policy based VPNs there are rules created which match traffic and based on this rule traffic is sent over a pair of security associations.

One which is used for each direction of traffic.

It means that you can have different rules for different types of traffic something which is great for more rigorous security environments.

Now the other type of VPN are route based VPNs and these do target matching based on prefix.

For example send traffic for 192.168.0.0/24 over this VPN.

With this type of VPN you have a single pair of security associations for each network prefix.

This means all traffic types between those networks use the same pair of security associations.

Now this provides less functionality but it is much simpler to set up.

To illustrate the differences between route based and policy based VPNs it's probably worth looking visually at the phase one and phase two architectures.

Let's start with a simple route based VPN.

The phase one tunnel is established using a phase one tunnel key.

Now assuming that we're using a route based VPN then a single pair of security associations is created.

One in each direction using a single IPsec key.

So this means that we have a pair of security associations essentially a single phase two tunnel running over the phase one tunnel.

That phase two or IPsec tunnel which is how we talk about the pair of security associations can be dropped when there is no more interesting traffic and recreated again on top of the same phase one tunnel when new traffic is detected.

But the key thing to understand is that there's one phase one tunnel running one phase two tunnel based on routes.

Running a policy based VPN is different.

We still have the same phase one tunnel but over the top of this each policy match uses an essay pair with a unique IPsec key.

And this allows us to have for the same network different security settings for different types of traffic.

In this example infrastructure at the top CCTV in the middle and financial systems at the bottom.

So policy based VPNs are more difficult to configure but do provide much more flexibility when it comes to using different security settings for different types of traffic.

Now that at a very high level is how VPNs functions.

So the security architecture of how everything interacts with everything else elsewhere in my course you'll be learning how AWS use VPNs within their product set.

But for now that's everything that I wanted to cover.

So go ahead and complete this video and then when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I'm going to be talking about the border gateway protocol known as BGP.

Now BGP is a routing protocol and that means that it's a protocol which is used to control how data flows from point A through points B and C and arrives at the destination point D.

Now BGP is a complex topic that goes far beyond the scope of this exam but as a solutions architect you need to be aware of how it works at a high level because AWS products such as Direct Connect and Dynamic VPNs both utilize BGP.

So let's jump in and get started.

BGP as a system is made up of lots of self managing networks known as autonomous systems or AS.

Now an AS could be a large network, it could be a collection of routers but in either case they're controlled by one single entity.

From a BGP perspective it's viewed as a black box, an abstraction away from the detail which BGP doesn't need.

Now you might have an enterprise network with lots of routers and complex internal routing but all BGP needs to be aware of is your network as a whole.

So your autonomous systems are black boxes which abstract away from the detail and only concern themselves with network routing in and out of your autonomous system.

Now each autonomous system is allocated a number by IANA, the Internet Assigned Numbers Authority.

The ASNs are 16 bits in length and range from 0 through to 65,535.

Now most of that range are public ASNs which are directly allocated by IANA.

However the range from 64,512 to 65,534 are private and can be utilized within private peering arrangements without being officially allocated.

Now ASNs or Autonomous System Numbers are the way that BGP identifies different entities within the network, so different peers.

So that's the way that BGP can distinguish between your network or your ASN and my network.

BGP is designed to be reliable and distributed and it operates over TCP using port 179 and so it includes error correction and flow control to ensure that all parties can communicate reliably.

It isn't however automatic, you have to manually create a peering relationship, a BGP relationship between two different autonomous systems and once done those two autonomous systems can communicate what they know about network topology.

Now a given autonomous system will learn about networks from any of the peering relationships that it has and anything that it learns it will communicate out to any of its other peers.

And so because of the peering relationship structure you rapidly build up a larger BGP network where each individual autonomous system is exchanging network topology information.

And that's how the internet functions from a routing perspective.

All of the major core networks are busy exchanging routing and topology information between each other.

Now BGP is what's known as a path vector protocol and this means that it exchanges the best path to a destination between peers.

It doesn't exchange every path only the best path that a given autonomous system is aware of and that path is known as an AS path, an autonomous system path.

Now BGP doesn't take into account link speed or condition, it focuses on paths.

For example, can we get from A to D using A, B, C and D or is there a direct link between A and D?

It's BGP's responsibility to build up this network topology map and allow the exchange between different autonomous systems.

Now while working with AWS or integrating AWS networks with more complex hybrid architectures, you might see the terms IBGP or EBGP.

Now IBGP focuses on routing within an autonomous system and EBGP focuses on routing between autonomous systems.

And this lesson will focus on BGP as it relates to routing between autonomous systems because that's the type that tends to be used most often with AWS.

Now I need to stress at this point that this lesson is not a deep dive into BGP.

All I need you to understand at this point is the high level architecture so that you can make sense of how it's used within AWS.

So let's look at this visually and hopefully it will make more sense.

So I want to step through an example of a fairly common BGP style topology.

So this is Australia, the land of crocodiles and kangaroos.

And in this example we have three major metro areas.

We have Brisbane on the east and this has an IP address range of 10.16.0.0/16.

And the router is using the IP of 10.16.0.1 and this has an autonomous system number of 200.

We have Adelaide on the south coast using a network range of 10.17.0.0/16 and the router is using 10.17.0.1 and this has an autonomous system number of 201.

And then finally between the two in the middle of Australia we have Alice Springs using the network 10.18.0.0/16.

The router uses 10.18.0.1 and the autonomous system number is 202.

Now between Brisbane and Adelaide and between Adelaide and Alice Springs is a one gigabit fiberlink.

And then connecting Brisbane and Alice Springs is a five megabit satellite connection with an unlimited data cap.

BGP at its foundation is designed to exchange network topology and it does this by exchanging paths between autonomous systems.

So let's step through an example of how this might look using this network structure.

We start at the top right with Brisbane and this is how the route table for Brisbane might look at this point.

The route table contains the destination.

In this case we only have the one route and it's the local network for Brisbane.

The next column in the route table is the next hop.

So what IP address is needed is the first or next hop to get to that network and 0.0.0.0 in this case means that it's locally connected.

And this is because it's the local network that exists in the Brisbane site.

And then finally we have the AS path which is the autonomous system path and this shows the path or the way to get from one autonomous system to another.

And the I in this case means that it's the origin so it's this network.

Now the two other locations will have a similar route table at this stage.

So Adelaide will have one for 10.17.0.0 and Alice Springs will have one for 10.18.0.0/16.

And both of those will have 0.0.0.0 as the next hop and I for the AS path because they're all local networks.

So each of these autonomous systems so 200, 201 and 202 can have peering relationships configured.

So let's assume that we've linked all three.

So Brisbane and Alice Springs, Alice Springs and Adelaide and then finally Adelaide and Brisbane.

Each of those peers will exchange the best paths that they have to a destination with each other.

So Adelaide will send Brisbane the networks that it knows about and at this point it's only itself.

And what it does when it exchanges this or when it advertises this is it pre-pens its AS number onto the path.

So Brisbane now knows that to get to the 10.17.0.0 network it needs to send the data to 10.17.0.1.

And because of the AS path it knows that it goes through autonomous system 201 which is Adelaide and then it reaches the origin or I.

And so it knows that the data only has to go through one autonomous system to reach its final destination.

Now in addition to this Brisbane will also receive an additional path advertised from Alice Springs in this case over the satellite connection.

And Alice Springs propends its AS number 202 onto that path.

So Brisbane knows to get to the 10.18.0.0/16 network.

The next stop is 10.18.0.1 which is the Alice Springs router and it needs to go via the 202 autonomous system number which belongs to Alice Springs.

So at this point Brisbane knows about both of the other autonomous systems and it's able to reach both of them from a routing perspective.

Now in addition to that Adelaide will also learn about the Brisbane autonomous system because it has a peering relationship with the Brisbane autonomous system.

And in addition Adelaide will also in the same way learn about the network in Alice Springs because it also has a peering relationship with the Alice Springs ASN 202.

And then finally because Alice Springs also has BGP peering relationships between it and both of the other autonomous systems.

It will also learn about the Brisbane autonomous system and the Adelaide autonomous system.

And so at this point all three networks are able to route traffic to the other two.

So if we look at the route table for Alice Springs it knows how to get to the 10.16 and 10.17 networks via the ASN of 202.01 respectively.

All three autonomous systems can talk to both of the others and this has all been configured automatically once those BGP peering relationships were set up between each of the autonomous systems.

But it doesn't stop there.

This is a ring network and so there are two ways to get to every other network clockwise and anti-clockwise.

Adelaide is aware of how to get to Alice Springs so ASN 202 because it's directly connected to that.

And so it will advertise this to Brisbane pre-pending its own ASN onto the AS path.

And so Brisbane can now reach Alice Springs via Adelaide so using the 201 and then 202 AS path.

Notice how the next hop for the route given to Brisbane is the Adelaide router so 10.17.0.1.

And so if we used this route table entry the traffic would go first to Adelaide and then be forwarded on to Alice Springs.

Likewise Adelaide is aware of Brisbane and so it will advertise that to Alice Springs pre-pending its own ASN onto the AS path.

So notice how this new route on the Alice Springs route table the one for 10.16.0.0/16 is going via Adelaide so 10.17.0.1.

The AS path is 201 which is Adelaide, 200 which is Brisbane and then the origin.

Now lastly Adelaide will also learn an additional route to Alice Springs but this time via Brisbane.

And Brisbane would pre-pend its own ASN onto the AS path.

So in this case we've got the additional route at the bottom for 10.18.0.0/16 but the next hop is Brisbane 10.16.0.1 and the AS path is 200 which is Brisbane and then 202 which is Alice Springs and then we've got the origin.

Autonomous systems advertise the shortest route that they're aware of to any other autonomous systems that they have peering relationships with.

Now at this point we're in a situation where we actually have a fully highly available network with paths to every single network.

If any of these three sites failed then BGP would be aware of the route to the working sites.

Notice that the indirect routes that I've highlighted in blue at the bottom of each route table have a longer AS path.

These are non-preferred because it's not the shortest path to the destination.

So Brisbane for example if it was sending traffic to Alice Springs it would use the shorter path, the direct satellite connection.

By default BGP always uses the shorter path as the preferred one.

Now there are situations where you want to influence which path is used to reach a given network.

Imagine that you're the network administrator for the Alice Springs network.

Now that autonomous system has two networking connections, the fiber connection coming from Adelaide and the satellite connection between it and Brisbane.

Now ideally you want to ensure that the satellite connection is only ever used as a backup when absolutely required and that's for two reasons.

Firstly it's a slower connection, it only operates at 5 megabits and also because it's a satellite connection it will suffer from significantly higher latencies than the fiber connection between Alice Springs and Adelaide and then Adelaide and Brisbane.

Now because BGP doesn't take into account performance or condition the satellite connection because it's the shortest path will always be used for any communications between Alice Springs and Brisbane.

But you are able to use a technique called ASPATH prepending which means that you can configure BGP at Alice Springs to make the satellite link look worse than it actually is.

And you do this by adding additional autonomous system numbers to the path.

You make it appear to be longer than it physically is.

Remember BGP decides everything based on path length and so by artificially lengthening the path between Alice Springs and Brisbane it means that Brisbane will learn a new route, the old one will be removed and so the new shortest path between Brisbane and Alice Springs will be the one highlighted in blue at the bottom of the Brisbane route table.

This one will be seen as shorter than the artificially extended one using ASPATH prepending and so now all of the data between Brisbane and Alice Springs will go via the fiber link from Brisbane through Adelaide and finally to Alice Springs.

BGP thinks that the path from Brisbane to Alice Springs directly over the satellite connection has three hops versus the two hops for the fiber connection via Adelaide and so this one will always be preferred.

So in summary a BGP autonomous system advertises the shortest path to a destination that it's aware of to all of the other BGP routers that it's paired with.

It might be aware of more paths but it only advertises the shortest one and it means that all BGP networks work together to create a dynamic and ever-changing topology of all interconnected networks.

It's how many large enterprise networks function, it's how the internet works and it's how routes are learned and communicated when using Direct Connect and dynamic VPNs within AWS.

Now that's everything that I wanted to cover.

This has just been a high level introduction to how BGP works and it's going to be a protocol that you'll need to understand in order to architect more complex or hybrid networks between AWS and on-premise.

Now that's all of the theory that I wanted to cover in this lesson so go ahead, finish off this video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I'm going to be covering another important piece of networking functionality, VPC peering.

I want to cover the theory and architecture quickly and then move on to a demo so you can experience exactly how it works.

So let's jump in and get started.

VPC peering is a service that lets you create a private and encrypted network link between two VPCs.

One peering connection links two and only two VPCs.

Remember that no more than two.

It's important for the exam.

A peering connection can be created between VPCs in the same region or cross region and the VPCs can be in the same account or between different AWS accounts.

Now there are some limitations when running a VPC peering connection between VPCs in different regions but it still can be accomplished.

When you create a VPC peer you can enable an option so that public host names of services in the peered VPCs resolve to the private internal IP addresses and this means that you can use the same DNS names to locate services whether they're in peered VPCs or not.

If a VPC peer exists between one VPC and another and this option is enabled then if you attempt to resolve the public DNS host name of an EC2 instance it will resolve to the private IP address of that EC2 instance.

And if your VPCs are in the same region then they can reference each other by using security group ID and so you can do the same efficient referencing and nesting of security groups that you can do if you're inside the same VPC.

This is a feature that only works with VPC peers inside the same region.

In different regions you can still utilize security groups but you'll need to reference IP addresses or IP ranges.

If the VPC peers are in the same region then you can do the logical referencing of an entire security group and that massively improves the efficiency of the security of VPC peers.

Now if you can take away just two important facts from this theory lesson about VPC peers it's that VPC peering connections connect two VPCs and only two.

One VPC peer connects two VPCs and the second fact that I want you to take away is that this connection is not transitive.

Now what I mean by that and I'll show you it visually on the next screen is that if you have VPC A peered to VPC B and you have VPC B peered to VPC C that does not mean that there is a connection between A and C.

If you want VPC A B and C to all communicate with each other then you need a total of three peers one between A and B one between B and C and one between A and C.

So you need to make sure that for any connectivity requirements that you have there is always a peering connection between every VPC pair that you want to connect.

You can't route through interconnected VPCs and you'll see exactly how that looks visually on the next screen.

Now when you create a VPC peering connection between two VPCs what you're actually doing is creating a logical gateway object inside of both of those VPCs and to fully configure connectivity between those VPCs you need to configure routing.

So route tables with routes on them pointing at the remote VPC IP address range and using the VPC peering connection gateway object as the target and don't worry you'll get to see exactly how this works when you implement it in the next demo lesson.

I do want you to keep in mind that as well as creating the VPC peering connection and configuring routing you also need to make sure that traffic is allowed to flow between the two VPCs by configuring any security groups or network ACLs as appropriate.

So let's look at the architecture visually before we move on to a demo lesson where you'll get the chance to implement VPC peering between a number of different VPCs.

So architecturally let's say that we have three VPCs belonging to animals for life.

So we've got VPC A which is using an IP sider of 10.16.0.0/16.

We've got VPC B at the bottom which is using 10.17.0.0/16 and then VPC C on the right which is using 10.18.0.0/16.

By default each of these VPCs are isolated networks so no communication is allowed between any of the VPCs.

Now to allow communications we can create a peering connection between VPC A and VPC B and we can add another peering connection between VPC B and VPC C.

Now what that would do as I mentioned on the previous screen is establish a networking link and create a logical gateway object inside each VPC.

So step two would be to configure routing tables within each VPC and associate these with subnets.

And these routing tables have the remote VPC sider and as the target the VPC peering connection or the gateway object that's created when we create the VPC peering connection.

Now this would mean that the VPC router in VPC A would know to send traffic destined for the IP range of VPC B toward the VPC peering logical gateway object.

That configuration would be needed on all subnets at both sides of all peering connections assuming we wanted to allow completely open communications.

Now something to understand for the exam it does come up in questions at an associate level is that the IP address ranges of the VPCs so the VPCs siders cannot overlap if you want to create VPC peering connections.

So this is another reason why right at the start of the course I cautioned against ever using the same IP address ranges.

If you want to allow VPCs to communicate with each other using VPC peers you cannot have overlapping IP addresses.

Now assuming that you have followed best practice and don't have any overlapping sider ranges inside your VPCs then you will have connectivity between your isolated networks but one really really important thing to understand both for production usage and the exam is that with the architecture that you see now VPC A and B have one peering relationship and VPC B and C have another peering relationship but there is no link between VPC A and VPC C and while it might seem logical to assume that they could communicate through VPC B as an intermediary that's not the case.

Routing isn't transitive.

What this means is that you cannot communicate through an intermediary.

You need to have a VPC peer created between all of the VPCs that you want to be able to communicate with each other.

At least if you only use VPC peers there is a product called the transit gateway which I'll talk about later in the course which is a little bit more feature rich but for VPC peers you need to make sure that you have one peering connection between all VPCs that you want to communicate.

So in this example for VPC A to communicate with VPC C they would need their own independent peering connection created between those two VPCs.

Now with VPC peering any data that's transferred between VPCs is encrypted and if you're utilizing a cross region VPC peer then the data transits over AWS's global secure network so you get secure transit and you gain the performance from using the global AWS transit network versus the public internet.

Okay so that's it for the features and architecture of VPC peering that's everything that I wanted to cover in this lesson.

Next you're going to be doing a demo where you'll have the chance to implement this within your own AWS environment so thanks for watching go ahead and complete this video and then when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk about another type of endpoint available within a VPC and that's an interface endpoint.

These do a similar job to gateway endpoints but the way that they accomplish it is very different and you need to be aware of the difference.

So let's jump in and get started.

Just like gateway endpoints, interface endpoints provide private access to AWS public services, so private instances or instances which are in fully private VPCs.

Interface endpoints historically have been used to provide access to all services apart from S3 and DynamoDB.

Historically both of these services were only available using gateway endpoints and interface endpoints were used for everything else.

Recently though AWS have enabled the use of S3 using interface endpoints so at the time of creating this lesson you have the option to use either gateway endpoints or interface endpoints.

Currently DynamoDB is still only available using gateway endpoints.

Now one crucial difference between gateway endpoints and interface endpoints is that interface endpoints are not highly available by default.

They're interfaces inside a VPC which are added to specific subnets inside that VPC.

So one subnet as you now know means one availability zone.

So one interface end point is in one availability zone meaning if that availability zone fails then the functionality provided by the interface endpoint also fails.

To make sure that you have a highly available service then you need to add one interface endpoint in one subnet in each availability zone that you use inside a VPC.

So if you use two availability zones you need two interface endpoints.

If you use three then you'll need three interface endpoints.

Now because interface endpoints are just interfaces inside a VPC you're able to use security groups to control access to that interface endpoint from a networking perspective and that's something that you can't do with gateway endpoints.

You do still have the option of using endpoint policies with interface endpoints in just the same way as with gateway endpoints and these can be used to restrict what can be accessed using that interface endpoint.

Another aspect of interface endpoints that you should be aware of is they currently only support the TCP protocol and only IP version 4.

Now IP version 4 is probably the most important of those two things that you need to know.

I've not seen it come up in the exam yet but it will make its way there eventually and it's probably something that you should be aware of regardless.

Now behind the scenes interface endpoints use private link which is a product that allows external services to be injected into your VPC either from AWS or from third parties.

So if you see any mention of private link it's a technology that allows AWS services or third party services to be injected into your VPC and be given network interfaces inside your VPC subnet.

So private link is how interface endpoints operate but it's also how you can deploy third party applications or services directly into your VPC and this is especially useful if you're in a heavily regulated industry but you want to provide access to third party services inside private VPCs.

You can do it without creating any additional infrastructure you just use private link and inject that services network interfaces directly into subnets inside your VPC.

Now interface endpoints don't work in the same way that gateway endpoints do it's a completely different way of providing a similar type of functionality.

Gateway endpoints used a prefix list which was a logical representation of a service and this was added to route tables that's how traffic flows to the gateway end point from VPC subnets.

Now interface endpoints primarily use DNS.

Interface endpoints are just network interfaces inside your VPC.

They have a private IP within the range which the subnet users that they're placed inside.

Now the way that this works is that when you create an interface endpoint in a particular region for a particular service you get a new DNS name for that service an endpoint specific DNS name and that name can be used to directly access the service via the interface endpoint.

This is an example of a DNS name that you might get for the SNS service inside the US East 1 region.

Now this name resolves to the private IP address of the interface endpoint and if you can update your applications to use this endpoint specific DNS name then you can directly use it to access the service via the interface endpoint and not require public IP addressing.

Now interface endpoints are actually given a number of DNS names.

First we've got the regional DNS name which is one single DNS name that works whatever AZ you're using to access the interface endpoint.

It's good for simplicity and for high availability.

Also each interface in each AZ gets a zonal DNS which resolves to that one specific interface in that one specific availability zone.

Now either of these two types of DNS endpoints can be used by applications to directly and immediately utilize interface endpoints.

But interface endpoints also come with a feature known as private DNS and what private DNS does is associate a Route 53 private hosted zone with your VPC.

This private hosted zone carries a replacement DNS record for the default service endpoint DNS name.

It essentially overrides the default service DNS with a new version that points at your interface endpoint and this option which is now enabled by default means that your applications can use interface endpoints without being modified.

So this makes it much easier for applications running in a VPC to utilize interface endpoints.

Without using interface endpoints accessing a service like SNS from within a VPC would work like this.

The instance using SNS would resolve the default service endpoint which is SNS.us-eas-1.amazonaws.com.

It would resolve this name to a public space IP address and the traffic would be routed via the VPC router then the internet gateway and out to the service.

Private instances would also attempt to do the same so they would also try to resolve this default service address but without having access to a public IP address they wouldn't be able to get their traffic flow past the internet gateway so it would fail.

But if we change this architecture and we add an interface endpoint if private DNS isn't used then services which continue to use the service default DNS would leave the VPC via the internet gateway and connect with the service in the normal way.

Now for services which choose to use the endpoint specific DNS name they would resolve that name to the interface endpoints private IP address.

The endpoint is a private interface to the service that it's configured for in this case SNS and so the traffic could then flow via the interface endpoint to the service without requiring any public addressing.

It's as though SNS in this example has been injected into the VPC it's being accessed in a more secure way.

Now if we utilize private DNS it makes it even easier.

Private DNS replaces the services default DNS so even clients which haven't been reconfigured to use the endpoint specific DNS so they keep using the service default DNS name will now go via the interface endpoint.

So in this example using private DNS overrides the default SNS service endpoint name so SNS.us-east-1.amazonaws.com.

When you use private DNS rather than that resolving to a public IP address belonging to the SNS service it's overridden so it now resolves to the private IP address of the interface endpoint.

So using private DNS means that even services or applications which can't be modified to use the endpoint specific DNS name will also utilize the interface endpoint.

So for the exam I want you to try and remember a few really important things.

Gateway endpoints they work using prefix lists and route tables so they never require changes to the applications.

Essentially the application thinks that it's communicating directly with S3 or DynamoDB and all we're doing by using a gateway endpoint is influencing the route that that traffic flow uses instead of going via the internet gateway and requiring public IP addresses it goes via a gateway endpoint and can use private IP addressing.

Interface endpoint uses DNS and a private IP address for the interface endpoint.

You've got the option of either using the endpoint specific DNS names or you can enable private DNS which overrides the default and allows unmodified applications to access the services using the interface endpoint.

Interface endpoints don't use routing they use DNS so the DNS name is resolved it resolves to the private IP address of the interface endpoint and that is used for connectivity with the service.

Now gateway endpoints because they're a VPC logical gateway object they're highly available by design but interface endpoints because they use normal VPC network interfaces are not.

When you're designing an architecture if you're utilizing multiple availability zones then you need to put interface endpoints in every availability zone that you use inside that VPC.

But at this point thanks for watching we finished everything that I wanted to cover so go ahead finish up this video and when you're ready I'll look forward to you joining me in the next lesson.

Welcome back and in the next two lessons I'll be stepping you through two types of VPC endpoint.

Now in this lesson I'll be talking about gateway endpoints and in the next I'll be covering interface endpoints.

Now they're both used in roughly the same way, they provide the same functionality but they're used for different AWS services and the way that they achieve this functionality from a technical point is radically different.

So let's get started and in this lesson I want to cover gateway endpoints.

So at a high level gateway endpoints they provide private access to supported services and at the time of creating this lesson the services that work with gateway endpoints are S3 and DynamoDB.

So what I mean when I say private access in the context of this lesson, I mean that they allow a private only resource inside of VPC or any resource inside a private only VPC to access S3 and DynamoDB.

Remember that both of these are public services.

Normally when you want to access AWS public services from within a VPC you need infrastructure and configuration.

Normally this is an internet gateway that you need to create and attach to the VPC and then for the resources inside that VPC you need to grant them either a public IP version 4 address and IP version 6 address or you need to implement one or more NAT gateways which allow instances with private IP addresses to access these public services.

So these services exist outside of the VPC and so normally public IP addressing is required and a gateway endpoint allows you to provide access to these services without implementing that public infrastructure.

Now the way that this works is that you create a gateway endpoint and these are created per service per region.

So let's use an example of S3 in the US East 1 or Northern Virginia region.

So you create this gateway 4S3 in US East 1 and you associate it with one or more subnets in a particular VPC.

Now a gateway endpoint doesn't actually go into VPC subnets.

What happens is that when you allocate the gateway endpoint to particular subnets something called a prefix list is added to the route tables for those subnets and this prefix list uses the gateway endpoint as a target.

Now a prefix list is just like what you would find on a normal route but it's an object, it's a logical entity which represents these services.

So it represents S3 or DynamoDB.

Imagine this is a list of IP addresses that those services use but where the list is kept updated by AWS.

So this prefix list is added to the route table.

The prefix list is used as the destination and the target is the gateway endpoint.

And this means in this example that any traffic destined for S3 as it exits these subnets it goes via the gateway endpoint rather than the internet gateway.

Now it is important for the exam to remember that a gateway endpoint does not go into a particular subnet or an availability zone, it's highly available across all availability zones in a region by default.

Like an internet gateway it's associated with a VPC but with a gateway endpoint you just set which subnets are going to be used with it and it automatically configures this route on the route tables for those subnets with this prefix list.

So it's just something that's configured on your behalf by AWS.

A gateway endpoint is a VPC gateway object, it is highly available, it operates across all availability zones in that VPC, it does not go into a particular subnet.

So remember that for the exam because that is different than interface endpoints which we'll be covering next.

Now when you're implementing gateway endpoints you can configure endpoint policies and an endpoint policy allows you to control what things can be connected to by that gateway endpoint.

So we can apply an endpoint policy to our gateway endpoint and only allow it to connect to a particular subset of S3 buckets.

And this is great if you run a private only high security VPC and you want to grant resources inside that VPC access to certain S3 buckets but not the entire S3 service so you can use an endpoint policy to restrict it to particular S3 buckets.

Now gateway endpoints can only be used to access services in the same region.

So you can't for example access an S3 bucket which is located in the AP Southeast 2 region from a gateway endpoint in the US East 1 region, it's in the same region only.

So in summary gateway endpoints support two main use cases.

First you might have a private VPC and you want to allow that private VPC to access public resources in this case S3 or DynamoDB.

Maybe you have software or application updates stored in S3 and want to allow a super secure VPC to be able to access them without allowing other public access or access to other S3 buckets.

Now the second type of architecture that gateway endpoints can help support is the idea of private only S3 buckets.

Gateway endpoints can help prevent leaky buckets.

S3 buckets as you know by now can be locked down by creating a bucket policy and applying it to that S3 bucket.

So you could configure a bucket policy to only accept operations coming from a specific gateway endpoint.

And because S3 is private by default for anything else the implicit deny would apply.

So if you allow operations only from a specific gateway endpoint you implicitly deny everything else.

And that means that the S3 bucket is a private only bucket.

One limitation of gateway endpoints that you should be aware of the exam is that they're only accessible from inside that specific VPC.

There are logical gateway objects and you can only access logical gateways created inside of VPC from that VPC.

So before we finish up with this theory lesson let's quickly look at the architecture visually because it will probably help you understand exactly how all of the components fit together.

Without using gateway endpoints this is the type of architecture that you've been using so far in the course.

Two availability zones each with two subnets one public and green on the right and one private in blue on the left.

Resources in the public subnets on the right can be given public IP version 4 addresses and so access public space resources using those addresses through the VPC router via the internet gateway into the public space and then through to the public resource S3 in this example.

Now private instances can't do this they still go via the VPC router but they need to use a NAT gateway which provides them with a NATed public IP version 4 address to use and then this public address that's owned by the NAT gateway is used via the internet gateway and finally through to the public resource again S3.

The problem with this architecture is that the resources have public internet access either directly for public resources or via the NAT gateway for private only EC2 instances.

If you want instances inside the VPC to be able to access S3 but not the public internet then it's problematic.

If you work in a heavily regulated industry and you need to create VPCs which are private only with no internet connectivity then that is almost impossible to do without using gateway endpoints.

Using gateway endpoints we can change this architecture.

Architecturally to use gateway endpoints we create one inside of VPC and when creating it we associate it with one or more subnets and this means that a prefix list is added to the route table for that subnet.

This means that any traffic which leaves the private instances inside those subnets now has a route to the public service so it will go via the gateway endpoint and they won't need public addresses to talk to that service.

Imagine the gateway endpoint is being inside your VPC but having a tunnel to the public service and that way data can flow from private services inside the VPC through the gateway endpoint to the public service without needing any public addressing.

Note how this VPC has no internet gateway and no NAT gateway.

The private instance has no access to anything else outside the VPC only S3 and that's only because we've created the gateway endpoint.

We could even go one step further using a bucket policy on the S3 bucket and denying any access which doesn't come via the gateway endpoint.

Now a couple of important things to remember for the exam gateway endpoints are highly available by design.

You don't need to worry about AZ placement just like internet gateways that's all handled for you by the VPC service.

For the exam just know that gateway endpoints are not accessible outside of the VPC that they're associated with and in terms of access control endpoint policies can be used on gateway endpoints to control what the endpoint can be used to access.

So if you did want to allow access to one or two S3 buckets only rather than the entire service then that's something which can be controlled by using an endpoint policy on the gateway endpoint.

Now that's everything that I wanted to cover in this lesson about the theory and architecture of gateway endpoints.

In the next lesson we're going to be covering interface endpoints which offer similar functionality to gateway endpoints but and this is critical they're implemented in a very different way from an architecture perspective and that difference really does matter for the exam.

And if you intend to use these products in real world production implementations.

But at this point thanks for watching we finished everything that I wanted to cover so go ahead finish up this video and when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk about another type of gateway object available within VPCs, the egress only internet gateway.

The name gives away its function, it's an internet gateway which only allows connections to be initiated from inside a VPC to outside.

Let's step through the key concepts and architecture and you'll get chance to implement this yourself in the demo lesson later in this section.

To understand why egress only internet gateways are required, it's useful to look at the differences between IPv4 and v6 inside of AWS.

With IPv4, addresses are private or public.

The connectivity profile of an instance using IPv4 is easy to control, private instances cannot communicate directly with the public internet or public AWS services, at least not directly.

Public instances they have a publicly routable IP address which works in both directions and in the absence of any security filtering, public instances can communicate to the public internet and be communicated with from the public internet.

For private IPv4 addresses, the NAT gateway provides two pieces of functionality which are easy to confuse into one.

First, the NAT gateway provides private IPv4 IPs with a way to access the public internet or public AWS services but, and this is the important thing in the context of this lesson, it does so in a way which doesn't allow any connections from the internet to be initiated to the private instance.

So NAT as a process allows private EC2 instances to connect out to the public internet and receive responses back but doesn't allow the public internet to connect into that private instance.

Now NAT as a process exists because of the limitations of IPv4, it doesn't work with IPv6 and so we have a problem because all IPv6 addresses in AWS are publicly routable.

It means that an internet gateway will allow all IPv6 instances to connect out to the public space AWS services and the public internet but will also allow networking connectivity back in.

So anything on the public internet from a networking perspective will be allowed to initiate connections to IPv6 enabled EC2 instances.

In the absence of any other filtering the IPv6 instance will be exposed to the public internet.

So since NAT isn't usable with IPv6 we have a functionality hole, the ability to connect out but not allow networking connectivity to be initiated in an inbound direction and that's what egress only internet gateways provide for IPv6.

They allow connections to be initiated out and response traffic back in but they don't allow any externally initiated connections to reach our IPv6 enabled EC2 instances.

With normal internet gateways all IPv6 instances from a networking perspective can connect out and things are capable of connecting into them.

With egress only internet gateways then IPv6 instances can initiate connections out and receive responses back but things cannot initiate connections to them in an inbound way.

And architecturally that looks something like this.

So this is a common architecture, a VPC with two subnets in two availability zones and inside these subnets we've got two IPv6 enabled EC2 instances.

Now the first step just like with a normal internet gateway is to create it and attach it to the VPC.

Just like a normal internet gateway it's highly available by design across all of the AZs that the VPC uses and it scales based on the traffic flowing through it.

So for any exam questions where you're asked about the architecture of egress only internet gateways it is exactly the same as a normal internet gateway.

It's just the way that you use it which differs.

The architecture is exactly the same.

Now once we've created and attached it to the VPC then we need to focus on the route tables in the subnet.

We need to add a default IPv6 route of colon colon slash zero and use the egress only internet gateway as a target.

This means that the flow for IPv6 traffic will flow to the egress only internet gateway via the VPC router and from there out to the destination service.

Let's say a software update server.

Any response traffic will be allowed to flow back in because all types of internet gateway understand the state of traffic, their stateful devices.

What wouldn't be allowed in is any inbound traffic so traffic that's initiated from the public internet.

This will fail, it won't be allowed to pass through the egress only internet gateway and reach our IPv6 enabled EC2 instances.

And that's it.

It's not really a complex architecture.

It's just like an internet gateway.

Only it's designed for IPv6 traffic and it only allows outgoing connections and their response.

It also allows incoming connections.

Now you can use a normal internet gateway for both IPv4 instances with a public IPv4 IP and the IPv6 enabled instances and in that case traffic is allowed out and in in a bidirectional way.

If you need to implement a VPC where you only want IPv6 instances to be able to connect out and receive responses so in many ways like the architecture that you get from using a NAT instance then if you need to do that with IPv6 then you use an egress only internet gateway.

Now you're going to get the chance to implement one of these yourself in an upcoming demo lesson later in this section and that will help really cement the knowledge that you've learned in this theory lesson.

For now though just go ahead and complete the lesson and when you're ready I look forward to you joining me in the next.

Welcome back to this lesson where I want to talk briefly about VPC Flow Logs, which are a useful networking feature of AWS VPCs, which provide details of traffic flow within the private network.

The most important thing to know about VPC Flow Logs is that they only capture packet metadata.

It doesn't capture packet contents.

If you need to capture the contents of packets, then you need a packet sniffer, something which you might install on an EC2 instance.

So just to be really clear on this point, VPC Flow Logs only capture metadata.

So this means things like the source IP, the destination IP, the source and destination ports, packet size and so on.

Anything which conceptually you could observe from outside.

Anything to do with the flow of data through the VPC.

Now Flow Logs work by attaching virtual monitors within a VPC and these can be applied at three different levels.

We can apply them at the VPC level, which monitors every network interface in every subnet within that VPC.

We can apply them at the subnet level, which monitors every interface within that specific subnet and they can be applied to interfaces directly and only monitor that one specific network interface.

Now Flow Logs aren't real time.

There's a delay between traffic entering or leaving monitored interfaces and showing up within VPC Flow Logs.

Now this often comes up as an exam question.

So this is something that you need to be aware of.

You can't rely on Flow Logs to provide real time telemetry on network packet flow.

There's a delay between that traffic flow occurring and that data showing up within the Flow Logs product.

Now Flow Logs can be configured to go to multiple destinations.

Currently this is S3 and CloudWatch Logs.

Now it's a preference thing.

Each of these comes with their own trade-offs.

If you use S3, you're able to access the log files directly and can integrate that with either a third party monitoring solution or something that you design yourself.

If you use CloudWatch Logs, then obviously you can integrate that with other products.

You can stream that data into different locations and you can access it either programmatically or using the CloudWatch Logs console.

So that's important.

That distinction you need to understand for the exam.

You can also use Athena if you want to query Flow Logs stored in S3 using a SQL-like querying method.

Now this is important if you have an existing data team and a more formal, rigorous review process of your Flow Logs.

You can use Athena to query those logs in S3 and only pay for the amount of data read.

So Athena remember is an ad hoc querying engine which uses a schema on read architecture.

So you're only billed for the data as it's read through the product and the data that's stored on S3.

So that's critical to understand.

Now visually, this is how the Flow Logs product is architected.

We start with a VPC with two subnets, a public one on the right in green and a private one on the left in blue.

This architecture is running the Categorum application and this specific implementation has an application server in the public subnet.

Which is accessed by our user Bob.

The application uses a database which is within the private subnet and this has a primary instance as well as a replicated standby instance.

Flow Logs can be captured as I just mentioned at a few different points.

We've got the VPC.

We can also capture them at a subnet level and then finally directly on specific elastic network interfaces.

And it's important to understand that Flow Logs capture from that point downwards.

So any Flow Logs enabled at the VPC level will capture traffic metadata from every network interface in every subnet in that VPC.

Anything enabled at the subnet level is going to capture metadata for any network interfaces in that specific subnet and so on.

Flow Logs can be configured to capture metadata on only accepted connections, only on rejected connections or they can capture metadata on all connections.

So visually this is an example of a Flow Log configuration at the network interface level.

It captures metadata from the single elastic network interface of the application instance within the public subnet.

If we created something at the subnet level, for example the private subnet, then metadata from both of the database instances is captured as part of that configuration.

And anything captured can be sent to a destination and the current options are S3 and CloudWatch Logs.

Now I'm going to be discussing this in detail in a moment but the Flow Logs product captures what are known as Flow Log Records.

And architecturally these look something like this.

And I'm going to be covering this next in detail.

I'm going to step through all of the different fields just to give you a level of familiarity before you get the experience practically in a demo lesson.

A VPC Flow Log is a collection of rows and each row has the following fields.

All of the fields are important in different situations but I've highlighted the ones that I find are used most often.

So source and destination IP address, source and destination port, the protocol and the action.

Consider this example.

Bob is running a ping against an application instance inside AWS.

So Bob sends a ping packet to the instance and it responds.

This is a common way to confirm connectivity and to assess the latency.

So this is a good indication of the performance between two different internet connected services.

Now the Flow Log for this particular interaction might look something like this.

I've highlighted Bob's IP address in pink and the server's private IP address in blue.

This shows outward traffic from Bob to the EC2 instance.

Remember the order, source and destination and that's for both the IP addresses and the port numbers.

Now normally you would have a source and destination port number directly after that but this is ping so ICMP which doesn't use port so that's empty.

The one highlighted in pink that's the protocol number and ICMP is 1, TCP is 6 and UDP is 17.

Now you don't really need to know this in detail for the exam but it definitely will help you if you use VPC Flow Logs day to day and it might feature as a point of elimination in an exam question.

So do your best to remember the number for ICMP, TCP and UDP.

Now the second to last item indicates if the traffic was accepted or rejected.

This indicates if it was blocked or not by a security group or a network access control list.

If it's a security group then generally only one line will show in the Flow Logs.

Remember security groups are stateful so if the request is allowed then the response is automatically allowed in return.

What you might see is something like this where you have one Flow Log record which accepts traffic and then another which rejects the response to that conversation.

If you have an EC2 instance inside a subnet where the instance has a security group allowing pings from an external IP address then the response will be automatically allowed.

But if you have a network ACL on that instance's subnet which allows the ping inbound but doesn't allow it outbound then it can cause a second line, a reject.

It's important that you look out for both of these types of things in the exam so if you see and accept and then a reject and these look to be for the same flow of traffic then you're going to be able to tell that both a security group and a network ACL are used and they're potentially restricting the flow of traffic between the source and the destination.

Flow Logs show the results of traffic flows as they're evaluated.

Security groups are stateful and so they only evaluate the conversation itself which includes the request and the response.

Network ACLs are stateless so they consider traffic flows as two separate parts, request and response and both of these are evaluated separately so you might see two log entries within VPC Flow Logs.

Now one thing before I finish up with this lesson, VPC Flow Logs don't log all types of traffic.

There are some things which are excluded.

This is things such as the metadata service so any accesses to the metadata service running inside the EC2 instance, this includes time server requests, any DHCP requests which are running inside the VPC and then any communications with the Amazon Windows license server.

Obviously this applies only for Windows EC2 instances so you need to be aware that certain types of traffic are not actually recorded using Flow Logs.

Now we are going to have some demos elsewhere in the course where you are going to get some practical experience of working with Flow Logs but this is all of the theory which I wanted to introduce within this lesson.

At this point go ahead and complete this video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to introduce a product which is becoming more important for the exam.

And as a solutions architect it's an essential one to understand.

That product is the AWS Global Accelerator.

It's a product which is designed to optimize the flow of data from your users to your AWS infrastructure.

Now we have a fair amount to cover so let's jump in and take a look.

To understand why global accelerator is required, let's review a pretty typical problem when using AWS.

Let's say that you've created an application and you choose to initially host it in the US.

Now it involves cats and so logically it becomes really popular initially with users based in the US and these users generally have a great user experience.

But over time the notoriety of the application increases and it becomes popular with global users.

And these global users have a much less optimal experience.

The reason for their suboptimal experience is that generally the traffic between their locations and the infrastructure in North America is likely to be less direct.

Conceptually every flow of data using the internet can take a different route.

Take this example, a communication between a laptop and a VPC.

The communication isn't direct.

Data moves between different routers, different hops.

Each hop adds delay, variability and potential failure.

And what's worse is that the route can vary between customers and even for the return flow of traffic for the same customer.

Now each of these hops is suboptimal.

The lower the number of hops generally the better and more consistent the experience.

It means that generally customers who are further away from your infrastructure go through more internet based hops and this means a lower quality of connection.

The internet is designed to be distributed, it's designed to be autonomous and highly resilient.

And while speed is important it's less important than these other priorities.

Now global accelerator as a product isn't actually that difficult to understand architecturally.

In many ways its architecture is similar to cloud front and one of the key things in the exam is for you to be able to determine when to use cloud front and when to use global accelerator because they both improve performance but in different ways and for different reasons.

Global accelerator starts with two Anycast IP addresses.

Now Anycast IP addresses are a special type of IP address.

Normal IP addresses which you will have experienced so far are actually referred to as Unicast IP addresses.

And Unicast IP addresses refer to one thing, one network device.

Generally if you have two devices on a network which use the same Unicast IP address at the same time then bad things happen.

In contrast Anycast IPs are designed to allow this, their IP addresses which multiple devices can use and they're advertised onto the public internet and internet core routers will route traffic to the device closest to the source.

So with this example we have Anycast IP addresses of 1.2.3.4 and 4.3.2.1 and both of these map on to three global accelerator edge locations.

Now in reality there are many more but I'm trying to keep this diagram tidy.

The key thing to understand is that all three of these global accelerator edge locations are all using this pair of Anycast IP addresses.

So if there's any traffic that's destined for either one of these Anycast IP addresses then that can be serviced by anyone at the global accelerator edge locations.

So in this example if we have two users, one based in London and one based in Australia and they browse to either of these Anycast IP addresses then they would both be routed to an edge location that's closest to them, crucially using the public internet.

This part of the connection is still subject to the variability that the public internet can cause but now it's very limited to just the part between the customer and the global accelerator edge location.

What we've done is essentially move the AWS network closer to the customer.

At this point global accelerator accepts the data that arrives at one of its edge locations and it transits that data from that edge location to the destination but crucially this transit occurs over the AWS global network.

AWS have their own dedicated network so Fiberlinks between all of their different regions and they control these entirely.

They handle capacity and they handle performance and to use their own words if performance is anything but optimal you can complain to them.

Now for the exam I really only need you to understand this architecture so that customers will arrive at one of the global accelerator edge locations because they're using one of the Anycast IP addresses that's allocated to us when we create a global accelerator.

So we make a global accelerator, we create it, we're allocated these two Anycast IP addresses and if our customers use these then their connections will be routed to the closest global accelerator edge location.

That part which is indicated in red on the diagram that will occur over the public internet and so that can be affected by the variability that the public internet suffers from but once the traffic has entered the global accelerator product then it's transited over the AWS global network into our infrastructure platforms and the benefit of that is substantially improved performance.

There are less hops, AWS generally maintain the network to a higher standard and it's designed and maintained specifically for the transit of data between AWS regions.

So for the exam just understand the architecture, understand how it works, what it does and then finally when and where to use it.

And regarding those last two criteria so when and where I want to talk about some additional points which might help.

So global accelerator is very much like cloud front so you're okay to be confused.

They both in their own way move the AWS network closer to your customers.

Now cloud front specifically moves the content closer by caching it on the edge locations.

Global accelerator moves the actual AWS network as close to your customers as possible.

The aim with global accelerator is to get your customers onto the global AWS network as quickly as possible as close to their location as possible and this is done using these anycast IP addresses.

Once the traffic arrives at the edge it's transited over the AWS global network all the way through to one or more locations.

Now on the previous screen I showed you the example with one location of infrastructure.

So we created the Categorum application and hosted it in North America.

But global accelerator is also capable of routing traffic to the closest infrastructure location to the customer.

It can make the decision to direct connections from London to local infrastructure based in Europe rather than the US.

The key thing that global accelerator does is to get the data from your customer to an application end point as quickly as possible with the best performance as possible.

Now the one key difference between global accelerator and cloud front conceptually is that global accelerator is a network product.

It works on any TCP or UDP applications including web apps whereas cloud front only caches HTTP and HTTPS content.

If you see questions which mention caching then it's probably going to be cloud front that is the right answer but if you see questions which mention TCP or UDP and the requirement for global performance optimization then possibly it's going to be global accelerator which is the right answer.

Now why I keep mentioning cloud front is that people tend to confuse them, tend to confuse the situations where you would pick one over the other.

I want to start off with both of these products in your mind and make sure that you understand the points of differentiation.

Global accelerator doesn't cache anything.

It doesn't cache content, it doesn't cache any network data.

It doesn't provide any HTTPS or HTTP level capabilities.

It doesn't understand the protocol for either HTTP or HTTPS.

It's a network product.

So the question gives you a scenario which involves transiting network data TCP or UDP as quickly and efficiently as possible through a global network then it's likely to be global accelerator.

If it mentions content delivery, caching, pre-signed URLs or any of the other services that cloud front provides then logically it's going to be cloud front that's the correct answer.

So why it might initially seem confusing, why you might find it a little bit difficult to distinguish between these two products at this point it should be obvious that they're completely separate.

If you need to do caching, if you need to deal with web or secure web or anything involves with the delivery of content or the manipulation of that content it's going to be cloud front.

If you want global TCP or UDP network optimization then it's going to be global accelerator.

At this point though that's everything that you'll need to know 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 lesson, I want to cover something which starts to feature much more in AWS exams and that's CloudFront Lambda at Edge.

You don't need to have any experience implementing it, but you do need to know how it's architected and what it's capable of doing.

So let's jump in and get started.

Lambda at Edge is a feature of CloudFront which allows you to run lightweight Lambda functions at CloudFront Edge locations.

Now these Lambda functions can adjust traffic between the viewer and the origin in a number of interesting ways and we'll talk about some of those soon.

Now there are some limitations that you need to be aware of because the Lambda functions are running at the Edge.

They don't have the full Lambda feature set.

So currently only Node.js and Python are supported as run times.

You can't access any VPC based resources since the functions are running in the AWS public zone and additionally Lambda layers are not supported.

Lastly, the functions have different size and execution time limits versus normal Lambda.

Now you don't need to memorize all of these facts.

What's more important is a good understanding of the architecture.

So let's look at that next.

Lambda at the Edge starts with the traditional CloudFront architecture.

So customers on the left, the Edge locations in the middle and the origins on the right.

Now any interaction between a customer, Edge location and origin consists of four individual parts of that communication.

The connection between the customer and the Edge location which is known as the viewer request.

Then you've got the connection between the Edge location and the origin known as the origin request.

Next, when the origin responds, there's a connection between the origin and the CloudFront Edge known as the origin response.

And then finally, the connection between the Edge location and the customer known as the viewer response.

Now with Lambda at the Edge, each of these individual components of the wider communication can run a Lambda function and this Lambda function can influence the traffic as part of that connection.

So a viewer request Lambda function runs after the CloudFront Edge location receives a request from a viewer.

An origin request function runs before CloudFront forwards that request onto the origin.

An origin response function runs after CloudFront receives a reply from the origin.

And then finally, a viewer response function runs before the response is forwarded back to the viewer.

Now there are limits on how the Lambda functions can run in each part of the architecture.

At the viewer side, a Lambda at Edge function has a limit of 128 MB for memory allocation and a function timeout of five seconds.

At the origin side, the memory limits are the same as a normal Lambda, but with a 30 second timeout.

Now again, don't worry too much about these limits.

For now, try to focus at a high level on what these limits mean, what types of architectures and what type of adjustments these Lambda functions can perform on each of these different components of the flow of data between a viewer and an origin and back again.

Now let's look at some example solutions which involve Lambda at the Edge.

Now I've included a link attached to this lesson which gives a few examples of situations where you would use Lambda at the Edge.

Now I can't give an exhaustive list in this lesson because just like Lambda itself, you can pretty much do anything that you want as long as you can code it within a Lambda environment.

But a couple of common examples that you might find useful for the exam.

First, you can use Lambda at the Edge to perform A/B testing.

And this is generally done with a viewer request function.

You can use a viewer request function in an A/B testing scenario to present two different versions of an image without creating redirects or changing the URL.

In this architecture, the function views the viewer request and modifies the request URL based on which version of an image you want the viewer to receive.

With this architecture, the Lambda function can modify the viewer request and change the URL based on any logic that you can define inside a Lambda function.

It can be things like a percentage-based algorithm or it can be random chance.

Another scenario which you might use Lambda at the Edge for is running a function as part of the origin request.

And this can be used to perform a gradual migration between different S3 origins.

You can use a function running in this part of the architecture to gradually transfer traffic from an existing S3 origin over to a new one.

And you can do so in a controlled way.

For example, based on a weighted value which represents a percentage of the traffic of your application.

So over time, you can increase the percentage of traffic which goes to the new S3 origin versus the old.

And all of this can be done in a controlled way without updating the CloudFront distribution.

Now, you can also use Lambda at the Edge to customize behavior based on the type of device that your customer has.

So given a particular type of device or a particular capability of that device, you can display different objects.

Now this might include different sizes of objects or objects with different quality levels.

For example, if you have a device which has a high DPI screen, so a higher dots per inch, then you might want to display objects which themselves have a higher DPI value and save lower DPI objects for devices which can't support high DPI.

So again, that's something that you can use Lambda at the Edge for rather than making any changes to the CloudFront distribution.

You can also use Lambda at the Edge to vary the content displayed by country.

So a Lambda function that's running in the origin request component of the communication can be used to adjust what gets displayed based on the country of the customer.

Now the link that I've included attached to this lesson gives a lot more examples of the types of scenarios that would benefit from Lambda at the Edge.

And in addition to the scenarios, most of these include example Lambda function code that you can implement in your own environments.

So this is going to be something that's outside of the scope of this course.

You only need to be aware of the architecture of Lambda at the Edge for this certification.

But if you do want to experiment with this in your own time, then you can use the examples contained on this page.

And again, the URL is attached to the lesson and you can do your own experimentation.

But at this point, that's all of the architecture that I wanted to cover in this lesson.

I just want you to be aware of exactly what Lambda at Edge can be used for because you might get a question on it in the exam.

So make sure that you're comfortable with all of the examples that I've given in this lesson and all of the examples which are included on the link that are attached to this lesson.

Again, you won't need to remember all of the different facts and the execution limits and the memory amounts.

It's all about the architecture.

So if you familiarize yourself with all of the examples that are on screen now and the ones that are in the link attached to this lesson, then you'll have all of the information that you need to answer questions about this topic in the exam.

But at this point, that's all of the theory that I wanted to cover in this lesson.

So go ahead, complete the lesson, and then when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this video I want to step through how you can deliver private content from CloudFront using behaviors.

Now additionally I want to step through the differences between signed URLs and signed cookies and these are ways to deliver private content through to your end users.

Now we've got a lot to cover so let's jump in and get started.

CloudFront can run in two security modes when it comes to content.

The first and the default is public.

In this mode any content which is distributed via CloudFront is public and can be accessed by any viewer.

This is the mode that you've probably experienced so far but there's also private and in this mode any requests made to CloudFront need to be made with a signed cookie or signed URL or they'll be denied.

CloudFront distributions are created with a single behavior and in this state the whole behavior and so the whole distribution is either public or private.

Generally though you're going to have multiple behaviors and part will be public and part private and this allows you to redirect any unintended accesses to a private behavior at a public one for example starting a login process.

Now there are two ways to configure private behaviors in CloudFront the old way and the new preferred way.

Now in both cases you require a signer and a signer is an entity or entities which can create signed URLs or signed cookies.

Once a signer is added to a behavior that behavior is now private and only signed URLs and cookies can be used to access content.

Now with the old way you first had to create a CloudFront key to use and this is something that an account root user had to create and manage.

This is a special key that's tied to an AWS account rather than a specific identity within that account and once a CloudFront key exists in an account that account can be added as a trusted signer to a distribution specifically a behavior in that distribution.

Now for real-world usage and for the exam while this is the legacy method you do need to remember the term trusted signer.

If you see it you'll know that a private distribution or a private behavior is involved.

Now the new and preferred method is to create trusted key groups and assign those as signers.

The key groups determine which keys can be used to create signed URLs and signed cookies.

Now there are a few reasons why you should use trusted key groups versus the old architecture.

First you don't need to use the AWS account root user to manage public keys for CloudFront signed URLs and signed cookies.

If you use trusted key groups then you can admin these in a much more flexible way.

You can manage these key groups and the configuration using the CloudFront API and you can associate a higher number of public keys with your distribution more specifically with your behavior giving you more flexibility in how you use and manage those keys.

So it's absolutely preferred to use this new method of trusted key groups versus the old method of a CloudFront key being added to an AWS account and that account being added as a trusted signer.

So there's the old way and the new way and absolutely you should prefer the new way for any new deployments.

Now at this point I want to quickly step through the differences between signed URLs and signed cookies so you know some of the situations where you might use one versus the other.

So signed URLs provide access to one object and one object only.

That's really critical.

Remember that one for the exam because it can be a really easy way to pick between the two.

Now this is not really valid at this point but historically RTMP distributions couldn't use signed cookies so this was a legacy point to pick between signed URLs and cookies but this isn't really applicable anymore.

Now you should use signed URLs if the clients don't support using cookies.

Not everything does so if your client doesn't support cookies then you can only use signed URLs.

Now cookies can provide access to groups of objects so you could use a signed cookie to provide access to groups of files or all files of a particular type.

For example all catgifts so this is a really common re-daintain the application URLs.

So when you use signed URLs with Cloud Front you get a custom URL.

If you want to present access using a certain format of URL then you need to use signed cookies so that's another point of differentiation.

Now visually this is how the architecture looks so we start with our customers who are using the Categorum application this time the new iPhone application.

Because of the popularity of the existing web application the new mobile application has been developed to use Cloud Front.

The application has images which are public and then some more sensitive ones for example cats bearing all for a belly rub.

So there needs to be some method of distributing private content.

So within the Cloud Front distribution there are two behaviors a public behavior which is the default and this handles all non-sensitive application operations and then a private one which handles access to all of the sensitive catgifts.

All of the infrastructure runs within an AWS account and it's a serverless application so the back end consists of API gateway, Lambda for the compute functionality and S3 to store the media.

The application flow starts when the application connects through to the distribution which for the default behavior uses the API gateway as an origin which uses Lambda for the serverless compute.

Let's assume that the mobile app is using ID Federation so a Google, Twitter or Facebook Identitate for Logins.

The application communicates with the default behavior uses API gateway it logs in and accesses some images which are private.

The Lambda signer function checks the application's access to the image and if everything is good because we've added trusted key groups on the distribution specifically the behavior the Lambda function is able to generate a signed cookie which grants access to a selection of images belonging to this specific application user.

That cookie together with information on access URLs is returned to the mobile application.

The mobile application all behind the scenes uses the access information to access the images and it supplies the cookie along with this request.

The cookie is checked by CloudFront and assuming everything checks out an origin fetch occurs.

The cat images are retrieved and returned back to the application.

Private behaviors are an excellent way to secure content but you need to make sure that the origin is also secure.

In this case the S3 origin needs to be configured using an origin access identity so that it only accepts connections from the CloudFront distribution and that will avoid the security issue where CloudFront gets bypassed.

Now at this point that's all of the theory I wanted to cover in this video.

Thanks for watching go ahead and complete the video and when you're ready I look forward to you joining me in the next.

Welcome back.

In the next few lessons I want to talk about how to secure the content delivery path when using CloudFront.

When content is being delivered globally using CloudFront there are a few zones that you need to think about.

First on the left are the origins so these are the locations where content is hosted.

In the middle we've got the CloudFront network which consists of the network itself and the edge locations and then on the right the public internet and our consumers of content.

For the next two lessons I want to focus on the security of this path.

So first in this lesson the security of the origin fetch side which is the transfer of data into the CloudFront network from the origins and then through to the edge locations.

Then in the next lesson I'll be covering the security of the customer or viewer side.

So how to get content through to the consumer in a safe and secure way.

For this lesson I'll be focusing on the origin side security and I want to focus on how we can make sure that only CloudFront gets access to the data on those origins.

Essentially avoiding an ingenious customer bypassing CloudFront and accessing the origins directly.

So let's get started and explore this part of the delivery path.

Now before we start I want to reiterate something that I covered in an earlier lesson.

You can use S3 as an origin for CloudFront but you can do it in two different ways.

If you just use S3 as an origin then it's known as an S3 origin.

If you utilize the static web hosting feature of S3 and use this with CloudFront then the S3 bucket is treated the same as any non S3 origin and this is known as a custom origin.

For this lesson when I'm covering OAIs or origin access identities this is only applicable for S3 origins so not using the static website feature of S3.

So what is an OAI?

Well it's a type of identity.

It's not the same as an IAM user or an IAM role but it does share some of the characteristics of both.

It can be associated with CloudFront distributions and those CloudFront distributions when they're accessing an S3 origin in essence the CloudFront distribution becomes that origin access identity.

This means when a CloudFront distribution is accessing an S3 origin the identity can be used within bucket policies so either explicit allows or denies.

Generally the common pattern is to lock an S3 origin down to only being accessible via CloudFront so this uses the implicit default deny to apply to everything except the origin access identity.

So the origin access identity is explicitly allowed access to the bucket and everything else is implicitly denied and visually this looks like this.

So we start this architecture with a CloudFront distribution already configured for animals for life and this architecture uses an S3 origin a few edge locations and we've also got two customers Julie and Moss and we want to allow access via CloudFront to this S3 origin and deny any direct access and so to do that we create an origin access identity and we associate that origin access identity with the CloudFront distribution.

Now the effect of doing this means that the edge locations gain this identity the origin access identity.

Then we can create or adjust the bucket policy on the S3 bucket.

We add an explicit allow for the origin access identity and then in its most secure form we remove all other access leaving the implicit deny.

Now at this point any accesses from the edge locations are actually from the origin access identity the virtual identity that we've created and associated with the CloudFront distribution and so access from the edge locations is allowed because the origin access identity is explicitly allowed via the bucket policy.

Direct access though for example from our Moss user would not have the origin access identity associated with them and because of this it's implicitly denied from accessing the bucket.

So with this configuration we've explicitly allowed the origin access identity we've not explicitly allowed anything else and so what remains is the implicit deny that applies to everything but that identities can be created and used on many CloudFront distributions and many buckets at the same time.

Generally though I find it easier to manage if you create one origin access identity for use with one CloudFront distribution because long term this makes it easier to manage permissions.

So that's how we handle origin security for S3 origins but what about non S3 origins custom origins is there a way to secure those?

Well let's take a look at that next.

For this architecture let's say that we have two custom origins two CloudFront edge locations and a customer and what we want to do is prevent the customer accessing the origins directly.

Now remember these are not S3 origins and so we can't use origin access identities to control access.

So for custom origins we have two ways that we can implement a more secure architecture.

First we can utilize custom headers and the way that this works is that our users use HTTPS to communicate with the edge locations and we can insist on this by configuring the viewer protocol policy.

Now HTTPS is actually just HTTP running inside a secure tunnel and so this has the advantage of protecting the contents of that tunnel.

Now we can also use the same protocol between the edge location and the origin and this is known as the origin protocol policy.

But in addition to this we configure CloudFront to add a custom header which is sent along with the request to the origin.

But the origin is configured to require this header to be present otherwise it won't service requests.

These are called custom headers and can be configured within CloudFront so because the entire stream utilizes HTTPS then nobody can oversee the headers that we're using and fake them.

The custom headers are injected at the edge location and these allow our custom origin to know for sure that the request is coming from a CloudFront edge location and if this header isn't present the origin will simply refuse to service any of the requests.

Now that's one way to handle it but we do have another way and that's via traditional security methods.

AWS actually publicize the IP addresses of all of their services so we can easily determine the IP ranges at the CloudFront edge locations.

Now if we have the IP ranges that are used by CloudFront then we can use a traditional firewall around the custom origin.

This firewall is then configured to allow connections in from the edge locations and deny anything else.

So this is another solution which means the origin is essentially private to anything but CloudFront and can't be bypassed.

Now you can use either of these approaches or even both of them in combination.

In doing so you make sure that the secure and private distribution of content cannot be bypassed by accessing the origins directly.

All of these methods so origin access identity, custom headers and traditional IP blocks secure the first part of the content delivery path.

In the next lesson we're going to look at how to use CloudFront to secure the point between the edge location and our customer.

So thanks for watching go ahead complete this lesson and when you're ready I look forward to speaking to you in the next.

Welcome back and in this lesson I want to go into a little bit more detail about origin types and origin architecture within CloudFront.

You need to understand the types of origins, how they differ and the features that each of them provides.

Now this is going to be another lesson where it's easier to show you the differences rather than talk about them so I'm going to move over to my console UI and explain the key points that you need to know for the exam and real-world usage.

Okay so let's take a look at some origins.

So I'm going to click on the services drop down and just type CloudFront so I'll move to the CloudFront console.

Now I've got two CloudFront distributions that are already set up.

One of them is a production one so this one is blurred out and the other one is just one that I'm getting ready for production usage.

So I'm going to open up this distribution then I'm going to click on origins.

So architecturally origins are where CloudFront goes to get content.

If an edge location receives a request from a customer and that object isn't cached at the edge then an origin fetch occurs to the relevant origin.

Now origin groups and I don't have any of those configured allow you to add resiliency.

So if you have two or more origins created within a distribution then you can create an origin group, group those origins together and have an origin group used by a behavior.

Remember origins themselves are selected from behavior so if I go to behavior we only have the one default behavior.

If I select it and click edit it's here where I can pick an origin or an origin group where any requests for this path pattern this is the default behavior so it's got a star wild card but for this behavior it will direct any requests if an origin fetch is required at the origin or origin group specified in this drop down.

Now this is only the single origin but if we had an origin group then it would provide resilience across those origins so this is a really cool way to be able to add resilience.

Now moving back to origins there are actually a few categories of origins and it's important that you understand all of them and exactly which features they provide as well as the situations where you'd use one versus the others.

So for origins you can have Amazon S3 buckets, AWS media package channel endpoints, AWS media store container endpoints and then everything else and everything else means web servers.

Now we haven't covered media package or media store yet I will be touching upon those elsewhere in the course but this split between S3 buckets media package and media store and then everything else is important.

The everything else being web servers these are known as custom origins and these have different features and restrictions versus S3 buckets and it's also important that you know that an S3 bucket has one set of features but if you configure static website hosting on that S3 bucket and use that as an origin then CloudFront views it as a web server so a custom origin and the feature set available is different.

S3 origins the simplest to integrate because they're designed to work directly with CloudFront so let's look at exactly what we can configure with an S3 origin so I've already got one prepared so I'll select it and click on edit.

Now for the origin domain name this is pointed directly at an S3 bucket an origin path allows CloudFront to use a particular path inside that origin so by default any requests made to the default behavior which are pointing at this origin will apply to the top level of the bucket.

If we wanted to look inside a particular path in that bucket for example images then we could specify that in the origin path box.

Now because this is an S3 origin we have access to various advanced features which we won't have if we're using custom origins and one of those advanced features is origin access.

Now this is the ability to restrict access to an S3 origin so that it's only accessible via a CloudFront distribution.

Now there are two ways of doing this we have origin access identity which is the legacy way and because this is an older CloudFront distribution this is why I've got legacy access identities selected.

Now the new and recommended way is origin access control and I'm going to have a demo coming up elsewhere in the course while you'll get the chance to experience this in practice.

For now though we don't need to worry too much about it just know that it means that you can restrict an S3 origin so that it's only accessible via the CloudFront distribution.

Another important thing to realize when you're using S3 origins is whichever protocol is used between the customer and the edge location so the viewer protocol policy is also used between CloudFront and the S3 origin the origin protocol policy so they're matched if you're using an S3 origin you've got the same viewer side and origin side protocol so whether you're using HTTP or HTTPS they're matched at both sides.

Then lastly you have the ability to pass through origin custom headers so if you have any headers which you want to pass through to the origin then you can do so on the origin settings and that's pretty much all that can be customized when you're using an S3 origin.

Everything's handled on your behalf the complex configuration comes when you're using a custom origin so let's look at that next.

So I'm going to click on cancel and then I'm going to click on create origin.

Now for origin domain name I'm just going to type a placeholder so in this case catagram.io.

Now CloudFront is smart enough to realize that this isn't an S3 bucket and so now I get the additional options that we're able to configure for custom origins so we still have the ability to specify an origin path so this works in the same way as it does for S3 origins if we want our behavior to point at an origin but instead of using the top level of that origin look at a sub path then we can specify that in the origin path box.

Now because this is a custom origin we can be much more granular with some of the configuration options so we can specify a minimum origin SSL protocol so this configures the minimum protocol level that CloudFront will use when it establishes a connection with your origin so best practice is always to select the latest version that's supported by the custom origin because that ensures maximum security.

You can also configure the origin protocol policy so remember for S3 origins the viewer protocol and the origin protocol are matched when you're using a custom origin you're able to select from one of three options you can either say HTTP only, HTTPS only or to match the viewer protocol policy so if the viewer protocol policy is HTTP and this option was selected then CloudFront would connect to your custom origin also using HTTP you can explicitly set either insecure or secure or you can match it so you've got to pick whichever is appropriate for your particular use case.

Now with custom origins you also have the ability to pick the HTTP and HTTPS port to use for CloudFront connections between the edge location and the origin so when you're using S3 you don't have the ability to set this because S3 doesn't have configurable ports but if you're running a custom origin it might well be that you have different services bound to different ports and so you have the ability to select the port to use for HTTP and HTTPS now the default of course is 80 for insecure HTTP and 443 for secure HTTPS so you can change these if you're using different ports on your custom origin and these are really important points remember for the exam so if you see any exam questions which talk about custom ports or the ability to configure the origin protocol policy or the minimum SSL protocol versions then you need to be using a custom origin.

Now you do still have the ability to pass through custom headers and elsewhere in this section of the course I'm going to be talking about how you can secure origins so they're only accessible using CloudFront if you're not using an S3 origin it means you don't have the ability to use origin access identities or origin access control and so to secure custom origins you can use custom headers you can pass in a custom header that only you're aware of and have your custom origin check for that header and that allows you to configure your custom origin only to accept connections from CloudFront so this is an important one to remember if you're wanting maximum security while using custom origins.

Now that's pretty much everything that I wanted to cover in this lesson I just wanted to give you a quick walkthrough of some of the important configuration options that you have available when it comes to S3 origins and custom origins it's fairly common to see CloudFront distributions use S3 origins and this is a popular way of delivering static content if you do need to integrate custom origins then you should be aware of some of those advanced configuration options and for the exam definitely make sure that you're aware of the different options that you have for custom origins and S3 origins because it does come up in the exam in multiple questions with that being said though that is everything that I wanted to cover about origins so go ahead complete this lesson and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to focus on how CloudFront works with SSL.

Each CloudFront distribution receives a default domain name when it's created.

It's the default way that you access a distribution and it's a CNAME DNS record.

Now it looks something like this.

It starts with a random part and is always followed by cloudfront.net.

Now you can enable HTTPS access to your distribution by default with no additional requirements as long as you use this address.

CloudFront is supplied with a default SSL certificate which uses star.cloudfront.net as the name.

So it covers all of the CloudFront distributions which use that default domain name.

Most of the time though you want to use your own custom name with a CloudFront distribution.

For example cdn.catagram.whatever.

And this is allowed via the alternate domain name feature where you specify different names which will be used to access a CloudFront distribution.

Once these are added and active you can point that custom name at your CloudFront distribution using a DNS provider such as Route53TPS you need a certificate applied to the distribution which matches that name.

And even if you don't use HTTPS you need a way of verifying that you own and control the domain.

And that way is by adding an SSL certificate which matches the name that you're adding to the CloudFront distribution.

The result whether you want to use HTTPS or not you need to add a cert to the distribution which matches the alternate domain name that you're trying to add.

And to do this you either need to generate or import an SSL certificate using the AWS certificate manager known as ACM.

Now this is a regional service.

Normally you need to add a certificate in the same region as the service that you're using.

So a load balancer located in AP Southeast 2 would also need a certificate creating within ACM also in the AP Southeast 2 region.

Now the exceptions to this are global services and one such global service is CloudFront.

For these services the certificate needs to be always created or added in US East 1.

Remember this for the exam.

It will come up.

For CloudFront if you're wanting to add any certificates they always need to be in US East 1 which is the northern Virginia region.

Now there are a few options that you can set on a CloudFront behavior in terms of how to handle HTTP versus HTTPS.

First you can allow both HTTP or HTTPS so no restrictions.

You will allow the customer to make the choice about the protocol whether it's insecure or secure.

Second you can redirect any incoming HTTP connections to HTTPS which is the option many people use to encourage the use of secure HTTP.

And then finally you can restrict a behavior within CloudFront to only allow HTTPS but this does mean that any HTTP connections will fail entirely.

Now if you choose to use HTTPS with CloudFront then you have to have the appropriate certificates which match the name that you're using for that distribution.

For the exam understanding certificates is really important which is what I want to cover in detail in the remainder of this lesson.

Now there are actually two sets of connections when any one individual is using CloudFront.

First you've got the connection between the viewer and the CloudFront edge location and second the connection between CloudFront and the origin that's being used and these are known as the viewer and origin protocols.

And for the exam and really try to commit this one to memory both of those connections need valid public certificates as well as any intermediate certificates in the chain and the key part here is public.

Self-signed certificates if you see that term will not work with CloudFront.

They need to be publicly trusted certificates.

Okay so now I've covered the basics of HTTPS with CloudFront.

Let's quickly move on and touch on something else.

One really important thing to understand about CloudFront and SSL for the exam is how it's charged and to understand that and why it is this way you need a little understanding of how SSL has worked over time.

So historically in the distant past so before 2003 every SSL enabled website needed its own dedicated IP.

The reason why is critical to understand if you really want to understand SSL.

So SSL and TLS are often used interchangeably but in this context I just mean encryption that happens over a network connection.

Now the problem is is that when encryption is being used as part of HTTPS that encryption happens at the TCP layer and this is much lower level than HTTP which is an application layer protocol.

Now you might be aware that a single web server can actually host many websites using different names using one single IP address.

For example I could host Catergram and DogoGram on the same server using the same IP address.

Now how this works when only using HTTP is that when your web browser is sending a request to my web server which hosts both of these sites on a single IP it uses what's called a host header.

Essentially your browser tells my server that you're requesting a page from Catergram or DogoGram and so my server knows to provide that particular website rather than the other.

So if you're accessing Catergram you tell my web server you're accessing Catergram and it knows to provide you with the Catergram website rather than the DogoGram website.

But this happens at the application layer so layer 7 and this is after the connection has been established.

Now TLS so the encrypted part of HTTPS this happens before this point so before the browser sends the web server the information about the site that it wants.

Part of what TLS does is allow a web server to validate its identity.

When you first create the encrypted connection between you and an IP address so before you start a HTTP connection the web server identifies itself.

Now the issue is that if you don't have a way of telling that web server which site you're trying to access and there wasn't such a way originally then the server doesn't know and so the server can only provide one certificate.

And this is why historically it wasn't possible to host multiple HTTPS sites on a single IP.

If they needed separate certificates then the web server had no method of understanding which particular site you were trying to access.

It had no method of supplying the relevant certificate and so it couldn't handle more than one certificate.

So if you had multiple sites which needed multiple certificates then they all needed separate IP addresses.

So in 2003 an extension was added to TLS called SNI or server name indication.

An SNI adds the ability for a client to tell a server which domain name it's attempting to access and this occurs within the TLS handshake so before HTTP even gets involved.

So when you're establishing the encrypted connection between your device and CATAGRAM your device can tell the server that it wants to access CATAGRAM.

The server can then respond with the CATAGRAM certificate proving its identity as the CATAGRAM server and this allows one IP to host many HTTPS websites which need their own certificates.

Now the problem is that all the browsers don't support SNI.

So if you want to use CloudFront and you want to allow HTTPS connections and you want to use a custom certificate with a custom domain name then CloudFront needs to provide dedicated IP addresses if it needs to support older browsers.

So when using CloudFront you can either choose to use SNI mode which is free as part of the service or you can choose to use a dedicated IP at the edge location and this costs money at the time of creating this lesson $600 per month per distribution.

So if you need to support HTTPS on anything but prehistoric browsers it's standard and it's free and you don't need to pay any extra you just need to install that SSL certificate.

For all the browsers SNI won't be supported and you need to pay $600 per month for a dedicated IP address.

Okay so with that being said one last thing before we finish and that's to look at the architecture of SSL in CloudFront visually.

So let's move on and look at that next.

So architecturally this is how it looks.

We have a CloudFront edge location in the middle and three origins on the right.

An S3 bucket, an application load balancer and a custom origin and this could either be an EC2 instance or an on-premises web server.

On the left we have a few customers at the top one customer which is using a modern web browser and they're using this to browse category.

At the bottom we have some customers with a slightly older pre-2003 browser.

What you need to understand for the exam is the certificate requirements to support this and how the older browser influences things.

Now to start because we have a mixture of clients and some of them include older browsers.

With this architecture we would need to use a dedicated IP and this does cost extra.

If we only had to support modern browsers which support SNI then we could use the one shared IP address.

So in either case our customers use these IP addresses to connect to one or more edge locations and this is called the viewer protocol or viewer connection.

The connection between the viewers or the customers and the edge location.

The key consideration here is that the certificate used by the edge location has to be a publicly trusted certificate.

Something trusted by the web browsers which our customers use and this generally means something by the major certificate authorities such as Komodo, Digisert, Symantec or AWS certificate manager.

If you use the AWS certificate manager then just to reiterate the certificate has to be created in US East One.

I'm going to keep stressing this point throughout any cloudfront related lessons in the course because it features all the time in the exam.

For anything cloudfront related where it integrates with a regional service so logging or certificates then assume you have to interact with it in US East One.

Now any public certificate needs to match the name of the cloudfront distribution that it's being applied to.

So if you add a custom domain name the DNS needs to point at cloudfront and the certificate needs to match the DNS name that you're using.

So that's the viewer side secured and a really important point again that I want to stress is that you cannot use self signed certificates.

Only publicly trusted certificates are able to be applied to cloudfront distributions.

That's another really important point for the exam.

At the other side is the connection between the edge location and the origin or the origins and this is called the origin protocol.

Now the rules about certificates at this side are similar to the viewer side.

First they need to use publicly trusted certificates and of course again this means no self signed certificates.

If your origin is S3 then you don't need to worry about anything else because S3 handles this natively.

So you don't need to apply certificates onto your S3 bucket and indeed you can't actually change the certificate that's on an S3 bucket.

So if you're using S3 origins it's really simple.

You just point your cloudfront distribution or specifically your behavior at the origin and everything works.

If you're using an application load balancer then this needs a publicly trusted certificate and you can either use one that's generated externally or you can use the AWS certificate manager to generate a managed one on your behalf.

For any custom origins so EC2 instances or on-premise servers then again you need to use a publicly trusted certificate but neither of these services are supported by ACM and so you can't use ACM to manage the certificate on your behalf.

You need to apply the certificates manually.

Now in all cases for origins I'm going to stress this again.

The certificate needs to match the DNS name of the origin.

So in order for SSL to work as an architecture from the viewer side the certificate applied to cloudfront needs to match the DNS name of whatever your customers are using to access cloudfront and then at the origin side the certificate installed on any of your origins needs to match the DNS name that cloudfront is using to contact the origin.

So that's really important.

Now that's everything I wanted to cover for this lesson.

Thanks for watching.

Go ahead and complete it and when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk about AWS Certificate Manager or ACM.

This is something which is essential to understand for almost all of the AWS certifications and most real-world projects.

You need to know a little bit at the associate level, more at the pro level and different things matter in each of the different streams.

So architect, developer and operations.

Now let's just jump in and get started.

Let's start with the basics just to put ACM into context.

HTTP or the Hypertext Transfer Protocol was initially created without the need for much in the way of security, so no server identity authentication or transport encryption.

As HTTP evolved from just text to move towards complex web applications, the security vulnerabilities became an issue.

For example, if somebody could spoo for websites DNS name, then they could direct users to another potentially compromised web server.

Users would be unaware of this because the address displayed by the browser would appear normal just like they expect, and this could be used to gain access to credentials and potentially sniff data in transit.

The evolution of HTTP, HTTPS or Hypertext Transfer Protocol Secure to use its full name was designed to address the problems with HTTP.

It uses either SSL or TLS protocols to create a secure tunnel which normal HTTP can be transferred through.

In effect, the data is encrypted in transit from the perspective of an outside observer.

Now, HTTPS also allows for servers to prove their identity.

Using SSL and TLS, servers can be authenticated by using digital certificates.

These certificates can be digitally signed by one of the certificate authorities trusted by the web client.

Since your web client trusts the CA, you trust the certificate which it signs, and that's why you trust the site itself.

It means that it's harder to spoof.

If the site claiming to be Netflix.com actually has the Netflix.com certificate which is signed by a trusted certificate authority, then it's almost certain to actually be Netflix.com.

To be viewed as secure, a website picks a DNS name like animalsforlive.org, it generates a certificate or has one generated for it, it's signed and it uses that certificate to prove its identity, so the DNS name and the certificate are tied together.

Now, ACM can function both as a public certificate authority generating certificates which are trusted by public web browsers and devices, or as a private certificate authority.

So this has the same architecture, but something which is private to your organization, and this is something often used by large corporates.

With private certificate authorities, you need to configure clients so that they trust the private certificate authority.

Something generally done manually by adding this trust into your client laptop and desktop builds, or automatically by adding a policy to configure this trust.

In public mode, browsers trust a list of certificate authorities provided by the vendor of that operating system, and these trusted providers can then themselves trust other providers which establishes this chain of trust.

With ACM, you can either generate or import certificates, so the product can make certificates for you, which just needs to use DNS or email verification to prove that you own the domain, and if ACM generates the certificates, it can automatically renew them on your behalf, and you won't have any ongoing issues with expired certificates.

If you import certificates generated from another external source, then you're going to be responsible for renewing them, which generally means renewing them with this external source, and then importing them again into ACM.

Now, these are really important points to remember for the exam.

If ACM generates the certificate for you, it can automatically renew it.

If it imports it, you're going to be responsible.

Now, another important point for the exam is that ACM can only deploy certificates to supported services.

The certificates are always stored encrypted within the product and deployed in a managed and secure way to those supported services, so services within AWS which are integrated with ACM.

Now, not all services are supported.

In fact, this is generally only CloudFront and loadbalances.

EC2, for example, which is a self-managed compute service, is not supported because AWS has no way of securing the transfer and deployment.

If you manage an EC2 instance, if you have root access, there will always be a way to access the certificate, and the whole point of ACM is to secure the storage and deployment of those certificates.

Now, that's going to be tested in AWS exams all of the time, so the idea that you are aware that not all AWS services are supported, specifically EC2, is not, so only supported services can be used with ACM.

Remember that for the exam just to restress, you cannot use ACM with EC2.

A few more important things to know before we look at the architecture visually.

ACM is a regional service.

There is an isolated ACM in US East One and another in AP Southeast Two and another in every AWS region.

If you import a certificate into a region or generate a certificate in that region, those certificates cannot leave that region.

Once inside, they're locked to that particular region.

Now, and this is really critical for the AWS exams, I cannot stress this enough.

If you want to use a certificate within a service, for example, a load balancer in AP Southeast Two, then the certificate needs to be inside ACM in that same region.

I'm going to repeat this because it's that important.

To use a certificate from ACM inside a load balancer within a particular region, so AP Southeast Two, that certificate needs to be within ACM also in AP Southeast Two.

Now, there's one exception to this and it's not really an exception once you understand why.

For CloudFront, that service, while being global, you should view it as running in US East One from an ACM perspective.

For CloudFront, conceptually, I want you to think about it that a distribution, which is the unit of configuration for CloudFront, is actually within US East One.

And so you always use US East One for CloudFront certificates.

So last time of repeating this, for most services, the certificate needs to be in the same region where the service is located.

So a load balancer needs to be in the same region as the certificate that it's using within ACM.

For CloudFront, always use US East One with ACM.

If you generate a certificate in any other region, you won't be able to deploy it using CloudFront.

Now, let's look at this visually because everything should start to click.

Visually, this is how ACM looks.

On the right, we've got three regions, US West One at the top, US East One in the middle, and AP Southeast Two at the bottom.

Inside each of these regions, we have regionally isolated instances of ACM, one running in each region.

Then also in each region, we have application load balancers together with associated EC2 instances.

We also have a CloudFront distribution, associated edge locations, and an S3 origin.

For this lesson, the region of the S3 bucket doesn't matter because we're focusing on ACM, and S3 does not use ACM for certificates.

On the left, we have some globally distributed users, and on the right, our security specialist.

Step number one is that our security specialist will interact with ACM in each of these regions and generate a certificate and then deploy it out to ACM in each region where service is required.

This means for supported services in those regions such as application load balancers, those certificates can be used from ACM to services in those regions.

What we can't do is deploy cross region.

In this example, from ACM located in US West One to a load balancer located in US East One, cross region deployment is not supported.

Nor can we deploy to unsupported services such as EC2.

For CloudFront, as I mentioned earlier in the lesson, conceptually think about it as the distribution, the main unit of configuration, being located in US East One.

This means when deploying certificates to CloudFront using ACM, the certificate needs to be located in US East One.

At that point, once the certificate is linked to the distribution, the distribution can then take the certificate and deploy it out to the edge locations no matter what regions they're located in.

Once the certificates are deployed onto supported services they can be used, they allow trust to be established from customers to the application load balancer, as with the top example, and the same architecture is true for edge locations at the bottom.

Once the ACM certificate is deployed to the distribution and then passed out to the edge locations, customers can make secure connections to those edge locations.

Now, once again, ACM isn't used for S3, which handles its own interaction with CloudFront within this architecture, so S3 does not use ACM for any certificates.

Now, that's all of the architecture which I wanted to cover about ACM.

It's everything that you need for the associate or professional level AWS certifications, and enough to get started with the product for any real world projects.

Now, I found ACM comes up a lot in the exams focused on diagnosing errors around which certificates can be used in which regions.

So now you know that certificates can only be used in the same regions that they're deployed into.

Cross region deployments are not supported, EC2 is not supported in CloudFront, to repeat it one last time, from the point of view of ACM is in US East One.

Now, you have all you need with everything that I've covered in this lesson, so thanks for watching.

Go ahead and complete this lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about CloudFront TTL as well as CloudFront invalidations.

Now both of these are features which can be used to influence how long objects are stored at edge locations and when they're ejected.

Now we've got a lot to cover so let's jump in and get started.

Now let's step through in detail exactly what happens with caching one image at one edge location.

So a simple architecture is an S3 origin on the left, an edge location in the middle and three users top, middle and bottom right.

Now let's say that we have a photo of Whiskers the cat and he's crying a little so it's not his best ever photo but that's the one that's uploaded into the S3 bucket by the Categorum application.

Now our first customer makes a request for the picture of Whiskers.

This image is not stored on the edge location and so an origin fetch happens where the image is retrieved from the origin and placed on the edge location before being returned to the customer which is the response.

Now let's say that the image of Whiskers is replaced in the origin so we take away this picture of Whiskers the cat crying and we replace it with a much better one.

So now we've got a much happier looking picture of Whiskers but now that this image has been replaced on the origin, note how the one on the edge location is still the old version so what happens when another customer makes a request to the same edge location.

This time the older or bad image of Whiskers is returned.

Why?

Because it's the one that's cached at the edge location and from an object perspective it's still viewed as valid even though the origin has a new version it's never checked because the copy that's cached in the edge location is viewed as valid by CloudFront.

Now there are ways to influence this which I'll explain later in the lesson but for now you need to understand this architecture can be problematic.

Now at some point every object that's cached by CloudFront will expire and when that happens it's not immediately discarded but now it's stale it's viewed as not current.

If at this point another customer requests a copy of this object then the edge location doesn't immediately return the object.

Instead as with step two it forwards this on to the origin and the origin will respond in one of two ways.

Now this is based on the version of the object that's cached at the edge location versus the one that's stored in the origin.

It's either current or the origin has an updated object.

If it's current then a 304 not modified is returned and the object is delivered directly from the edge location to the customer and the copy of the object in the edge location once again becomes viewed as current.

If there is a difference between the edge location and the origin so if the origin has a newer version of the object then a 200 okay message is returned along with a new version of the object which replaces the one that's cached at the edge location.

That's how an edge location behaves within the CloudFront network.

An object stays in the cache ideally for the entire time that it's valid.

If the edge location has capacity issues then in theory it could be ejected early.

Even when an object expires the next time that it's accessed assuming that it's still within the edge location cache then the edge location checks the version of the object that it has versus the one in the origin and if they're the same a 304 code is returned and the object is not updated it's just marked as once again been current.

A new version of the object is only transferred if the communication between the edge location and the origin determines that the version of the object that's in the origin has been updated.

Now the problem that you need to understand is step four on this diagram.

The middle user received an old version of the object even though a newer version was stored in the origin so he updated the copy of the whiskers object and even though that updated copy existed in the origin that user received a copy of the old object and that's something that you need to be aware of because there are ways that you can influence this and that's what I want to look at for the remainder of this lesson.

So now let's talk about object validity.

An edge location views an object as not expired when it's within its TTL or time to live period.

So let's explore what this means.

Before we do it's important to understand that as a general rule the more often that the edge location delivers objects directly to your customer which is called a cache hit the lower the load will be on your origin and the better performance for the user.

So where possible we want to avoid edge locations having to perform origin fetches to our origins because that will mean that cloud front is performing better.

It's giving better performance to our customers.

Objects which are cached by cloud front have a default validity period of 24 hours and this value is actually defined on a behavior within a distribution.

The default value for this default TTL is 24 hours.

This means any objects cached by cloud front using this behavior will also have a default TTL of 24 hours and this means 24 hours after the object is cached they're viewed as expired.

Now also on a behavior within a distribution you can set two other values the minimum TTL and the maximum TTL.

Now these values don't by themselves do anything to influence caching behavior.

Essentially they set lower and upper values for the TTL value that an individual object can have.

Now it's possible to define per object values for the TTL.

If you don't specify an object TTL then the default one attached to the behavior is used so the 24 hour default TTL.

Now an origin which remember could be an s3 bucket or a custom origin running your application.

Both of these can direct cloud front to use object specific TTL values using headers.

Now there are a number of different headers and you do need to remember these for the exam.

The first header is called cache-control s-max-age and this is a value in seconds.

We've also got cache-control s-max-age and this is again also configured in seconds.

Now think about these as the same thing setting either or both of these will do the same thing direct cloud front to apply a TTL value in seconds for a particular object and after the number of seconds specified within this object specific TTL have passed then that object will be viewed as expired.

Now we also have the expires header and instead of specifying a number of seconds this actually specifies a date and time.

So a specific date and time that you wish to direct cloud front that an object should be viewed as expired.

Now for any of these headers both the ones that are specified in seconds and the expires header where you specify a date and time the minimum TTL and maximum TTL specified on the behavior are both limiters.

So values below the minimum TTL of the behavior will mean that the minimum TTL is used rather than the per object setting and likewise for any per object TTLs specified which are above the maximum TTL for the behavior will mean that the maximum TTL value is used instead of the per object setting.

So it's important that you understand the architecture of this you have a default TTL on a behavior which is by default set to 24 hours you can change this value though but by default it is 24 hours and this applies to any object which doesn't have a per object TTL set you also set minimum TTL and maximum TTL values and these act as limiters for any per object settings that are defined using these cash control headers so max - age s - max age and then expires.

Now I mentioned this earlier but these headers can be set using custom origins or s3 if you're doing it using custom origins then these can be injected by your application or the web server if you're using s3 then these are defined on every object using object metadata so that's something that you can set using the API the command line or even the console UI.

Now let's look at one last topic before we finish up with this lesson and that's cash invalidations so cash invalidations are performed on a distribution whatever you set the invalidation to be is applied to all edge locations within that distribution so it's something that takes time it isn't immediate but what a cash invalidation does is immediately expire any objects regardless of their TTL based on the invalidation pattern that you specify so some examples include this one which is used to invalidate a specific object using a specific path in this case forward slash images forward slash whiskers one dot jpeg we've also got this one which uses a wild card and this will invalidate any objects in the images path which start with whiskers so this could be whiskers one whiskers two or even whiskers one three three seven dot jpeg all of these would be affected by this wild card invalidation pattern and then we've got this one which is forward slash images forward slash star and this would affect any objects contained within this path so this could be images about whiskers it could be images of sparky it could be images of woofy anything that's contained in this specific path would be matched by this star wild card and then lastly we've got slash star and this invalidates all objects which are cached by a distribution so this means everything on every edge location is immediately invalidated now there is a cost to perform cache invalidations and that cost is the same regardless of the number of objects which are matched by the pattern so invalidation should only really be thought of as a way to correct errors if you are regularly having a need to update individual files or invalidate individual files then you might want to think about using versioned file names instead now an example of a versioned file name would be whiskers one underscore v one dot jpeg if that's the crying picture from the start of the lesson and you wanted to replace it then you could add a new object called whiskers one underscore v two dot jpeg or v three dot jpeg and then update your application to point at that new version and this requires no invalidation now this one comes up in the exam all the time because versioned file names are better for a few reasons first because you're using a different name for the object it means that even if those objects are cached in a customer's browser it won't be used because you're changing the name and the application points at the new name even data cached in a user's browser won't impact the image or the object that your customers see second it means that logging is more effective because you know which actual object was used because nothing has the same name it also means that you keep all versions of all objects and these are consistent between edge locations so you can move between them and of course it's less expensive because you don't need to use continued cache invalidations now don't confuse versioned file names with s3 object versioning that's a different thing s3 object versioning allows you to have different data for an object different versions which use the same name cloudfront will always use the latest object version in a bucket by default what i'm describing here is different using versioned file names means having different file names for different actual versions different data stored in different file names and that means that each of these file names will be cached independently on every edge location and you can move between them in a consistent way by making changes to your application so this is an important one to remember for the exam if you do see any questions in the exam which talk about versioned file names and the question is looking at the scenario from a cost efficacy point of view then it's likely going to be versioned file names which is the correct answer now that's all of the theory that i wanted to cover in this lesson so thanks for watching go ahead and complete the lesson and when you're ready i'll look forward to you joining me in the next.

Welcome back and in this lesson I want to quickly step through the architecture of CloudFront behaviors.

Now I've introduced them earlier in this section.

You need to have a good grasp of what options are set at the distribution level and what is configured within a behavior.

Now as I've already introduced behaviors, it's going to be easier for me to show you rather than tell you the detail of behaviors and how behaviors fit in to the wider CloudFront components.

So I'm going to switch over to my console and step through all the features and exactly how things work.

Okay, so let's take a look at some behaviors.

So I'm going to go ahead and move to the CloudFront console.

So I'll click on services and type CloudFront.

Select it from the list.

Now I've got two CloudFront distributions.

One of them is production and one of them is for my testing.

So the production one's blurred out.

I'm just going to go ahead and move into my testing distribution.

So distributions are the unit of configuration within CloudFront and you'll see that there are lots of high level options which configured at a distribution level.

So it's here where all of the main important configuration options for the distribution are configured.

So let's take a look at some of them.

So first we've got the price class.

The price class determines which edge locations your distribution is deployed to.

So you can make CloudFront slightly cheaper by selecting to only deploy the distribution to US, Canada and Europe based edge locations.

This will result in a slightly reduced level of performance for any users not in those regions.

You can elect to use all of the edge locations which provides the best performance or use the option in between which deploys to only the US, Canada, Europe, Asia, the Middle East and Africa.

So normally I like to deploy out to all edge locations because I prioritize customer performance but you do have the ability to narrow this down and select only the US, Canada and Europe for deployment.

So just keep that in mind.

It's also to a distribution that you're able to associate a web application firewall.

So this is a layer seven firewall product available within AWS.

Now I'll be covering this elsewhere in the course, but it's at a distribution level that you can configure this integration.

So you create a web ACL within the WAF product and then associate it with a CloudFront distribution.

It's also at a distribution level that you can configure alternate domain names for your CloudFront distribution.

So notice how my CloudFront distribution has this default domain name, which is the random string which is unique for this distribution and then followed by CloudFront.net.

So this is the default, but I did configure an alternate domain name which is labs-bucket.cantral.io and this is added at a distribution level.

It's also at the distribution level that you can configure the type of SSL certificate that you want to use with the CloudFront distribution.

Now I'll be talking about this elsewhere in this section where I focus specifically on CloudFront and SSL, but you're able to use the default certificate as long as you're using that default DNS name.

If you want to use an alternate domain name and use that with HTTPS, then you need to use a custom SSL certificate.

And when you're using a custom SSL certificate, that's defined also at the distribution level.

It uses ACM and you have to pick between SNI and non-SNI.

And I'll be talking about exactly what that means in a dedicated lesson elsewhere in this section.

Now for the exam, this is important.

You can select the security policy to use.

So there are various different security policies and AWS update these periodically.

Now this is generally a trade-off because if you pick a more recent security policy, then potentially you can prevent any customers with older browsers accessing your distribution.

So you need to pick the one that's the best balance of security and accessibility for your users.

Now as well as that, all the things that are configured at a distribution level are supported HTTP versions, whether you want logging on or off, which again, I'll have another lesson coming up elsewhere in the course that talks about this.

So this is all of the high level things which can be configured at a distribution level.

There's also a lot which can be configured from a behavior perspective.

Now a single distribution can have multiple behaviors.

And I've mentioned that there's always going to be the one default behavior.

So let's open that up.

I'll select it and then click on edit.

Now the way that behaviors work is for any requests which are incoming to an edge location, their pattern matched against any behaviors for that distribution using this path pattern.

Now the default behavior has a wild card or star path pattern.

And so it matches anything which is not matched by another more specific behavior.

Once a path pattern is matched against an incoming request, it's then subject to any of the options specified within this behavior.

The most important one is which origin or origin group to use, but you can also select the viewer protocol policy.

So which policy is used between the viewer and the edge location?

Options include insecure or secure HTTPS.

You can redirect insecure towards secure HTTPS or only accept secure HTTPS.

So these are configurable on a per behavior basis.

That's important to understand.

You can also select to allow different HTTP methods.

And again, that's configured on a behavior.

You can configure field level encryption and I talk about this in a dedicated lesson elsewhere in this section.

So I won't go over it here in detail, but this allows you to encrypt data from the point that it enters the edge location through the cloud front network.

And again, this is configured on a per behavior basis.

You're also able to set all the cache directives within a behavior.

And you can do this either using legacy cache settings, which mine is configured using because this is an older distribution.

Or you can use the newer cache policy and origin request policy settings.

And these are recommended by AWS.

So this is the methods that are cash, the cash and origin request settings.

You're able to set whether you want to cash based on any request headers.

So options include non whitelist or all.

And again, this is per behavior.

The minimum TTL, maximum TTL and default TTL again is set on a per behavior basis.

And I talk about this in much more detail elsewhere in this section of the course.

An important one for the exam is that you're also able to restrict viewer access to a behavior.

So this is different than restricting access to an S3 origin.

This is the option that sets the entire behavior to be restricted or private.

And if you select this, you need to specify the trusted authorization type, which is trusted key groups or trusted signers.

Now, key groups are the new way of doing this and signers are the legacy way.

And for the exam, if you see trusted key groups or trusted signer, then you know that it is set to restrict viewer access.

And you need things like signed cookies or signed URLs in order to access the content.

And I'll be discussing this if appropriate elsewhere in the course.

And many distributions which are in use in the real world will have some behaviors which are non restricted, for example, sign on, and then some behaviors which are restricted and these control access to sensitive content.

It's on a behavior that you can set to compress objects automatically.

And it's also on a per behavior basis that you can associate Lambda at Edge functions with CloudFront.

So I talk about Lambda at Edge elsewhere in this section of the course, but it's at the behavior level that you associate these Lambda functions.

Now, from a real world perspective, you're obviously always going to have access to Google and the console.

So you can easily remind yourself exactly which options are set on a per behavior basis versus the distribution.

For the exam, do your best to try and commit these to memory.

Specifically, you need to understand that all of the caching controls are set on a behavior as well as the restrict viewer access.

If you remember those are behavior based.

You'll also remember that you can have different settings for those options for different behaviors in the same distribution.

And that will help you answer some of the more complex exam questions which you might encounter.

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

I just wanted to give you a quick walkthrough to help you understand the different components.

Go ahead, complete this lesson.

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

Welcome back.

In this lesson, I want to either introduce or refresh your memory on the high-level architecture of Cloudfront.

So what it does, what components it has and some of the important terminology.

So this lesson is just going to be an introduction or a refresher.

So let's jump in and get started.

Cloudfront is a content delivery network.

Its job is to improve the delivery of content from its original location to the viewers of that data.

And it does so by caching and by using an efficient global network.

So let's look at an example.

Let's say that I'm running an application from Australia and the application becomes so successful that it has global users.

Bob on the west coast of the US and Julie in the UK.

Now if they access the application, then the data has to flow from Australia to them.

And in reality, the route that the data takes will be a lot less direct than I'm showing on screen now.

Whatever route the data takes, it's traveling long distances.

And this introduces two problems.

Higher latencies and slower transfer speeds.

Both of these impact user experience.

It means that data is being transferred globally.

And it means that it's being transferred each and every time that data is requested.

And Cloudfront helps us with this.

I want to introduce some concepts first before we look visually at the architecture of Cloudfront.

Now you might be familiar with these terms if you've studied for the Associate Level Solutions Architect Certification.

If so, consider this a refresher for some of the more advanced topics covered in later lessons of this section.

So first we've got an origin.

And an origin is the original location of your content.

An origin can either be an S3 origin or a custom origin.

It's either S3 or anything else which runs a web server and has a publicly routable IP version 4 address.

So an S3 bucket or anything else.

The origin though is where your content lives and it's where it's served from.

And we'll talk more about origins as we move on in the section.

But for one Cloudfront configuration, you would either have one or more origins.

Next is a distribution.

And the distribution is the unit of configuration within Cloudfront.

To use Cloudfront, you create a distribution and this distribution gets deployed out to the Cloudfront network.

Almost everything is configured within a distribution, either directly or indirectly.

And so when I just mentioned that a Cloudfront configuration can have multiple origins, well they're all configured inside a distribution, but indirectly as I'll talk about later in this lesson.

Next we have edge locations and these are the names of the pieces of global infrastructure where your content is cached.

AWS have regions which are located globally, generally at least one in all major markets for AWS.

But these are almost always located in or around capital cities or other major areas of usage for AWS.

Edge locations are bigger in number and more widely distributed.

So there are more edge locations, they're smaller than regions, and these are distributed globally, much closer to your customers.

At the time of creating this lesson, there are over 200 edge locations and there's a big chance that there's one in the city closest to you.

So just to put this into context, edge locations are smaller than AWS regions.

There are generally one or more racks in a third party data center and a usually 90% storage with the odd bit of compute services tacked on for certain AWS services which we'll be talking about throughout this course.

But generally edge locations are used for the storage or the caching of dates, so you're not able to select an edge location as a target to deploy an EC2 instance.

Now the last term which I want to introduce is a regional edge cache and these are much bigger than edge locations and there are fewer of them.

They're designed to hold more data to cache things which are accessed less frequently, but where there's still a performance benefit for caching your data closer to your customers than your origins.

So regional edge caches do provide a real benefit when it comes to larger, more global deployments of CloudFront.

Now the diagram coming up next will make it clear how regional edge caches and edge locations are related.

So let's look at that next.

CloudFront isn't that complex as an architecture.

At a high level, Bob uploads some content to an S3 bucket which is going to be used as the origin for our CloudFront distribution.

In addition, Bob creates a CloudFront distribution which as I've mentioned is the configuration for CloudFront.

On the distribution, he configures the S3 bucket to be the origin, so the original location of the content.

And then at the other side of this architecture are our edge locations, so the locations which cache the content which will be distributed globally.

So these edge locations, as with the content, are distributed globally as close to our customers as possible.

Now one of the things which is created along with the distribution is a domain name for that distribution.

And this looks something like this.

It always ends in CloudFront.net and it will be unique to every distribution which you create.

You can also take your own domain name and configure the distribution to use that alternate domain name.

In this case, animalsforlife.org.

Once you've configured a distribution exactly how you like it, you can deploy that distribution to the CloudFront network.

And what this actually does is push the distribution configuration to all of the chosen edge locations, meaning that these edge locations can now be used by your customers because they have the configuration stored within the distribution.

Architecturally, in between the edge locations and the origin, remember this is where your content is stored.

So in between those two things are the regional edge caches.

Now they're bigger than the edge locations and generally support a number of local edge locations in the same geographic area.

So now let's assume that we have two customers who want to access our content hosted in our S3 bucket.

We have Julie and Moss and let's assume that they're in different locations but they're within the same continent.

Maybe Julie is in France on holiday and Moss lives in London.

So when Julie or Moss attempt to access animalsforlife.org, both of them will be directed towards their closest edge location.

And both Moss and Julie in this example are looking to access the same object, whiskers.jpg.

Now let's assume though that Julie attempts to access this object first.

So Julie makes the request for whiskers.jpg and her local edge location is checked for this object.

Now if the object was locally cached in this edge location, then the object would be returned immediately and the process would stop.

Julie would get the request returned quickly.

Her experience will be really positive and have high performance.

This is called a cache hit and this is a good thing.

Delivering content from a local edge location in all cases is what you want because it will always deliver better performance.

So faster speeds and lower latency.

If the object is not stored locally in an edge location, then this is called a cache miss and this is a bad thing.

If this happens, then Julie's edge location might check its closest regional cache and this is bigger.

So there's a bigger chance that the object will be stored regionally within this cache.

So the regional cache acts as a bigger cache for multiple edge locations.

And so if any local edge locations have accessed this object before, then it's likely to be stored in the regional edge cache.

Now if the object is not in the regional edge cache, then the process that happens next is called an origin fetch.

The content is fetched from the origin and this means that whiskers.jpg is now stored on the regional cache.

The regional cache pushes the object back to the edge location which originally requested it, which also means that it's now cached at the local edge location.

Once it's locally cached in the edge location, then it's returned to Julie and all of this happens behind the scenes.

Julie has no awareness of the multiple step process which is occurring within the cloud front network.

If Julie or anyone else near that local edge location requests the object again, then it can be delivered directly from that edge location.

This is a cache hit and this will offer improved access times, so lower latency and better performance.

And this will occur from the second access onward whenever it's locally cached at the edge location.

But what about Moss?

Well because Moss is accessing from a different edge location, he would make his own request and this would contact his local edge location.

But because his local edge location doesn't have a cached copy of that object, this will be a cache miss.

And so it also checks its regional edge cache.

It's checking for the whiskers.jpg object.

This time though, the regional edge cache does have the object based on the previous time when Julie accessed that object.

And so this time it's immediately returned to the edge location from the regional edge cache.

The local edge location that Moss is using caches that object and then immediately it's delivered to Moss.

Any customers accessing the object from a similar location to Moss will immediately get the object returned from the edge location.

Again, a cache hit and this is instead of using the regional cache or the origin.

So by deploying CloudFront, you can reduce the load on origins and get improved performance for your customers globally.

Now there are two important architectural things that you need to know about CloudFront at this stage.

First, it integrates with ACM or the AWS certificate manager.

So you can use SSL certificates with CloudFront.

And also CloudFront is for download style operations only.

Any uploads go direct to the origin for processing.

CloudFront performs no write caching and that's important to understand because there are questions which test your knowledge of whether it does read only or read and write caching.

Now I want to elaborate on one thing at this point because it will make the lessons which follow a lot easier to understand.

I talked about distributions earlier in this lesson and I mentioned that they're the base configuration entity within CloudFront.

But they aren't actually where a lot of the important configuration is stored, at least not directly.

That's actually contained within behaviors which themselves are contained within distributions.

A behavior is a configuration within a distribution.

Think of it like a sub configuration.

It works on the principle of a pattern match.

So let's look at this visually.

So we start with two users on the right connected to two edge locations.

And these edge locations receive their high level configuration via the distribution within CloudFront.

At the other side on the left we've got the origins.

It's easy to assume that origins are directly linked to distributions.

But that's not actually how it's architected.

Instead, origins are linked to behaviors which themselves are linked to distributions.

So behaviors architecturally sit in the middle between origins and distributions.

A CloudFront distribution always has at least one behavior but it can have many more.

So all CloudFront distributions start with the one behavior, the default behavior.

And this has a pattern of star which matches everything.

It's a wild card.

But you can define other behaviors which are more specific and these take priority.

Let's assume that this architecture on screen is for the Categorum application.

The default behavior is used for anything not matched by another behavior.

So low security things.

But let's say that we have private images which are located in the top bucket.

And this is more heavily restricted.

Well we could define a second behavior matching a more specific pattern.

Let's say IMG/*.

So anything accessed via the distribution which has a path of IMG/ and then anything else would use this other behavior.

Now the path pattern as the name suggests matches a certain path.

And this can allow us to have different configurations within a distribution.

So we can have different configuration options for different components of our CloudFront distribution.

Things like TTL, policies, origins and even the public or private nature of CloudFront may have been described as being set on the distribution.

But that's not actually entirely accurate.

They're actually set on behaviors which are themselves part of a distribution.

So that's a quick refresher and over the remaining lessons in this section of the course I'm going to be focusing in on a few of the key bits of functionality provided by CloudFront.

For now just go ahead and complete this lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this video, I want to briefly talk about Amazon AppFlow at a high level.

So in this video, I'll be covering the basics.

If you need any other knowledge for the course that you're studying, then there will be additional videos.

If you only see this one, don't worry, it's everything that you'll need to know.

Now let's jump in and get started.

AppFlow is an interesting service in that if you worked in this space and had this specific problem, you'll immediately see the value that the product provides.

If not, you might not get the point.

AppFlow is a fully managed integration service.

Think of it like middleware.

It allows you to exchange data between applications using flows.

So applications are connected to using connectors and the main unit of configuration of the product is a flow.

Now a flow consists of a source connector and a destination connector and other optional components.

But at a high level, it's the job of the product to exchange data.

Now examples of this might be to sync data across applications or aggregate data from different sources together to avoid data silos within your organization.

By default, the service uses public endpoints which allows it to interact with public SaaS applications, but it can work using private link to access private sources.

Now it comes with functionality for connecting to many of the most popular applications by default, but you can use the custom connector SDK to build your own.

Now some examples where you might use the product are to sync contact records from Salesforce to Redshift for analysis, or to copy your support tickets from something like Zendesk into S3 for storage or analysis.

AppFlow is one of those services which can do a lot.

If you have a need for this type of functionality, you will immediately understand how awesome it is.

Now visually, this is how the architecture might look.

We start with a flow and into this, we configure source and destination connections.

In this case, Slack and Redshift.

Now connections store the configuration and credentials to access an application.

And it's important to understand that they're defined separately from flows so they can be reused across many different flows.

Now it's using connections with this example that the product knows how to connect to Slack and to Redshift and what authentication details to use for both of these applications.

Now next within the flow, we define source and destination field mappings as well as any optional data transformation configuration.

This is what in this example tells AppFlow what fields were interested in from Slack and where to write them in Redshift.

We're also able to define optional filtering and validation within the flow to control what data we want to copy and what if any checks should be performed en route.

And that at a high level is AppFlow.

It's designed to enable you to exchange data between applications in a managed way.

A basic architectural understanding is enough knowledge for most of the AWS exams.

And if you need to know more, I'll include additional videos.

If you only see this one, this is everything that you need to know.

And at this point, that's everything I'm going 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 back and in this lesson I want to very briefly touch on Amazon MQ.

Amazon MQ is a product which is almost like a merge between SQS and SNS but using open standards.

Now it's something that you need to understand for the exam so let's jump in and get started and I'm going to keep this as brief as possible.

To understand when you would use Amazon MQ it's good to put it into context versus the other AWS products which are similar.

SNS and SQS are AWS services which utilise AWS APIs.

SNS provides topics which are one to many communication channels and SQS provides queues which are one to one communication channels.

Now while queues can have multiple compute things adding to the queue and removing from it, conceptually it's the same worker group at each side so it's one to one communications and queues are generally used to allow different components of an application to be decoupled.

Now both of these services so SNS and SQS are both public services within AWS meaning they can be accessed from anywhere which has network connectivity to the public endpoint for those services.

They're also both highly scalable and integrated with AWS from an API's perspective but also other AWS products can directly use them.

Now the problem is that larger organisations might already use topics and queues meaning they might already have an on-premise messaging system and this on-premise messaging system or queuing system might already use certain industry standards.

That organisation might want to migrate that existing system into AWS and if that's the case SNS and SQS won't work without application modification.

To migrate an existing messaging system or queuing system into AWS without application modification means that we need a standards compliant solution.

Amazon MQ is an open source message broker.

It's based on a managed implementation of Apache Active MQ which is one of the most common enterprise message broker solutions.

If you need a system which supports the JMS API or protocols such as AMQP, MQTT, OpenWire or Stomp then this means that you need Amazon MQ.

Now the product provides both queues and topics so it provides both one-to-one and one-to-many messaging architectures and it does so within the same product.

Now it's a managed service but not managed in the same way that SNS and SQS are.

With Amazon MQ you're provided with message broker servers and these can either be a single instance for test development or if you're cost conscious or a highly available pair for production usage.

One critical thing to understand about Amazon MQ is that unlike SQS and SNS it's not a public service.

It runs in a VPC and so private networking or holes in a firewall are required for anyone who needs to access it and it also doesn't have native AWS integration so you can't use it with other AWS products and services in the same way as SNS and SQS because other services expect to use SNS and SQS.

So you do have to keep in mind both the strengths and the limitations of this product and in the exam you will be expected to be able to identify the types of situation when you would select to use Amazon MQ and I'll be touching upon that towards the end of this lesson.

Now this is an architecture of SNS which you've seen before.

Publishers add messages to a topic, subscribers get those messages delivered and SNS as a service runs in the public AWS zone so it's accessible anywhere which has a network connection.

This is how SQS functions.

Again messages can be added to a queue and received at the other side of that queue and once again it's an AWS public service meaning it's accessible anywhere which has a network connection with connectivity to the public SQS endpoint.

So visually this is how a typical Amazon MQ deployment might look.

You might have an existing on-premises environment with an existing messaging infrastructure.

In this example a message producer interacts with an on-premise implementation of Active MQ.

Now if you want to migrate this into AWS or begin a period of coexistence then you need an AWS environment and let's say we have one with two availability zones and let's say into this environment you provision a highly available pair of Amazon MQ servers which would deploy a primary and standby and use EFS for shared storage between the two by default.

This means data is replicated between availability zones and between the brokers.

Now the really really crucial thing to understand for the exam is that Amazon MQ is not a public service and this means that you need a private network connection between your on-premises environment and AWS.

Now this could be a virtual private network or it could be a direct connect.

This private networking means that the on-premises broker and the AWS managed pair can communicate over this connection.

And this is what allows any migrated application to communicate with those brokers using standard protocols and integrate with the on-premises implementation.

Now before we finish I want to go through a few considerations that you should be aware of for the exam.

So your default position should be to use SNS or SQS for most new implementations where you require topics or queues.

You should always select to use SNS or SQS if you need topics or queues and AWS integration is required.

So if you want to take advantage of other AWS services for logging or permissions or encryption or if you're using other AWS services which expect SNS and SQS to exist then this is a good reason to pick SNS or SQS.

You should choose Amazon MQ if you need to migrate from an existing system with little to no application change and especially if you need to utilize APIs such as JMS or protocols such as AMQP, MQTT, OpenWire and Stomp.

Remember though if you do decide to use Amazon MQ and this is really important I've seen it in a number of exam questions you need to make sure that you do have the appropriate private networking configured.

Amazon MQ is not a public service.

It occupies a VPC and anything which accesses the service needs to have access to that networking inside the VPC.

Now again you don't need to have extensive knowledge of this product for the exam.

I have started to see more and more questions crop up dealing with hybrid style scenarios where an existing system exists on premises and you need to migrate from it into AWS or establish coexistence with that existing system and for both of those type of architectures Amazon MQ is an excellent solution.

With that being said though that's everything I wanted to cover in this lesson so go ahead complete the lesson and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about AWS Glue.

Glue is an interesting product which starts to feature more in the AWS exams and more in real world projects which I've been exposed to.

Now I'm only going to be talking about it in terms of the architectural theory in this lesson because anything more is well beyond the scope of this course.

So let's just jump in and take a look.

AWS Glue is a serverless ETL or Extract, Transform and Load system.

There's another product within AWS called Data Pipeline which can also do ETL processors but this uses compute within your account.

Specifically it creates EMR clusters to perform the tasks.

Glue is serverless.

AWS provide and manage all of the resources as part of the managed service.

Now at a high level, Glue is used to move data and transform data between a source and destination.

And these sources and destinations are databases, streams or other stores of data such as S3.

If you want to take source data and restructure it or enrich it, then you can use a Glue job to handle that in a serverless way.

Glue also crawls data sources and generates the AWS Glue Data Catalog which I'll cover in more detail next.

Glue supports a range of data locations.

Source data stores such as S3, RDS and any JDBC compatible databases such as Redshift or others and DynamoDB fall under this category.

We've also got source streams such as Kinesis Data Streams and Apache Kafka and then we've got data targets which include S3, RDS and again any JDBC compatible databases.

So that's AWS Glue at a high level.

Now let's quickly focus on Data Catalog.

AWS Glue provides a data catalog and if you've never heard that term, a data catalog is a collection of metadata combined with data management and search tools.

Essentially it's persistent metadata about data sources within a region.

Now the AWS Glue Data Catalog provides one unique data catalog in every region of every AWS account and it helps avoid data silos because rather than data being hidden away somewhere managed by a particular team and not visible to any other teams in the organization, it makes this metadata, the data structure available to be browsed and then brought into other systems using the ETL features of Glue.

So it's something that improves the visibility of data across an organization.

Now various AWS Data Related products can use Glue for ETL and catalog services, like Athena, Redshift Spectrum, EMR, AWS Lake Formation, they all use Data Catalog in some way and the way data is discovered is by configuring crawlers and giving them credentials and then pointing them at sources and letting them go to work.

Visually this is how the components of Glue fit together.

Let's start with the Data Catalog functionality.

So we have some data sources on the left, S3, RDS, maybe some JDBC compatible stores, DynamoDB, Kinesis, Kafka and much more.

So we configure data crawlers which connect to these stores.

They connect, they determine, schemers, they create metadata and all of this information goes into a data catalog which means that rather than those data stores being siloed, we now have visibility of them across the organization.

So this data catalog can be connected to by users of the AWS account and so all members of the business can get value from all of the data by using it in other areas than the area that it was gathered in.

So it essentially publicizes data from across an organization.

It makes it visible.

It allows a finance team to use data that's gathered by different teams within the organization.

Now the other components of Glue are Glue jobs and the Data Catalog is also used as part of Glue jobs.

Glue jobs are extract, transform and load jobs.

So data is extracted from a source and then loaded into a destination and in the middle Glue can perform transformation using a script which you create.

Now Glue is serverless and as such you don't need to manage the compute which is used to perform the transformation.

Instead AWS maintain a pool of resources and these are used to perform the transform tasks when required and you're only billed for the resources which you consume.

Now Glue jobs can be started manually or invoked in an event driven way using events from other sources or scheduled events within EventBridge and that's pretty much what you need to understand about Glue for the exam.

It's an extract, transform and load or ETL service and a data catalog service which is serverless and it forms part of the data and data analytics services provided by AWS.

Historically the ETL part of this has been done using Data Pipeline and so in exam questions you will generally only have one or the other.

So either Data Pipeline or Glue.

If you see both then look for keywords such as serverless, ad hoc or cost effective and if you see these you should pick Glue rather than Data Pipeline.

So Data Pipeline does offer some additional functionality versus Glue but over time it's my expectation that the Glue product will replace the functionality offered by Data Pipeline.

At this point though that's everything I wanted to cover in this lesson so go ahead and complete the lesson and then when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to go into some more depth about Amazon Cognito which is one of the core identity products available within AWS.

Now we do have a lot to cover so let's jump in and get started.

Now this is going to be one of the most important non-graphical screens of information in the entire course.

I want to make sure that you understand the terrible naming within the Cognito product.

Cognito provides two main pieces of functionality.

Both are very different but both are essential to understand.

Now the service as a whole provides authentication, authorization and user management for web and/or mobile applications.

Now authentication means to login to verify credentials.

Authorization means to manage access to services and user management means to allow the creation and management of a serverless user database.

Now there are two parts of Cognito.

User pools and identity pools and the naming on these is terrible.

This is why most students struggle to understand the detail of how Cognito works.

The end goal of a user pool is to allow you to sign in and if successful you get a JSON web token known as a JWT.

This JWT can be used for authentication with applications, certain AWS products such as API Gateway can even accept it directly.

But, and this is crucial to understand, most AWS services cannot use JWTs.

To access most AWS services you need actual AWS credentials.

Now user pools do not grant access to AWS services, their job is to control sign in and deliver a JWT.

So they do things like sign up and sign in services.

They also provide a built-in customizable web user interface to sign in users.

They provide certain security features such as multi-factor authentication.

They check for compromised credentials and they offer account takeover protection as well as phone and email verification.

Now you can also implement customized workflows and user migration by using Lambda triggers and we'll talk about that if applicable elsewhere in the course.

Now where it gets confusing is that user pools as well as allowing sign in from built-in users.

They also allow social sign in using identities provided by Facebook, Google, Amazon, Apple, as well as offering sign-in services using other identity types such as SAML identity providers.

But the important thing to understand is this is about offering a joined up user management experience.

At no point can a user pool be used to directly access most AWS resources.

When you think of user pools imagine a database of users which can include external identities.

They sign in and they get a JWT.

That's it.

I'm stressing this point because it's really important to conceptually separate this from an identity pool which is coming up next.

Now the aim of an identity pool is to exchange a type of external identity for a set of temporary AWS credentials which can then be used to access AWS resources.

Now one option is unauthenticated identities which can be used to offer guest access to AWS resources.

Imagine you have a mobile application and want to allow high scores to be stored in a leaderboard which is hosted using DynamoDB and you want to offer this without a user having to sign up and this is one way to do that.

Identity pools can also be used to swap an external identity for temporary AWS credentials and this means things like Google identity, Facebook, Twitter, SAML 2.0 for corporate logins and even user pool identities.

So from an identity pool perspective user pools are just treated as another form of identity.

Now all of these are examples of authenticated identities.

If another identity provider which we trust say that they have authenticated successfully then identity pools will exchange that identity for temporary AWS credentials.

Now I hope at this point that you do see the difference.

User pools are about offering a joined up sign up or sign in experience with user directory and profile management services.

So it's about login and about managing user identities.

Identity pools are about swapping either an unauthenticated or authenticated identity for AWS credentials and one possible type of identity is actually a user pool identity.

And this is a reason why these two different components of Cognito are often difficult to separate because they can operate together.

Now identity pools work by assuming an IAM role on behalf of the identity.

That assumption generates temporary credentials and they're provided back in return in most cases to a mobile or web application.

These IAM roles are configured within identity pools and there's going to be a demo coming up very soon where you can experience that.

Now for the rest of this lesson let's just step through a few architecture overviews and I think doing this visually will help you to understand how the product works.

First let's step through an architecture which just uses user pools.

Remember user pools are about user management, sign in, sign up and anything associated with that process.

So we start with a web and mobile application and a Cognito user pool with both internal identities and social sign in.

So anyone can sign in to the pool with any type of identity and the result is a Cognito user pool token also known as a JSON web token or JWT.

This user pool token proves that the identity has been used to sign in and it now represents a Cognito user pool user.

Whether an internal user is used or a social identity the authenticated identity is now a user pool identity.

And this token can then be used to access self-managed resources such as applications running on servers that you manage or accessing databases which you also manage.

It can also be used with an API gateway which is capable of accepting user pool tokens directly.

Remember these are known as JWTs.

An API gateway is capable of accepting JWTs for authentication.

So let's focus for a second on what's just happened.

A user pool is a collection of identities of users.

It's used to allow sign up and sign in both for internal users and social sign in.

The tokens which are generated as a result can be used for self-managed systems and the tokens can be used to authenticate for API gateway.

But, and this is the single biggest thing to remember about Cognito, these tokens cannot be used to access AWS resources.

In general that requires AWS credentials and AWS credentials can be handed out via identity pools.

So let's look at those next.

So we have the same web and mobile application.

This time though we aren't using user pools.

We're allowing customers to log in directly using external identities.

How this works is as follows.

We start with a collection of supported external identities.

And these include the same social identities which I've demonstrated previously with user pools.

Our application allows users to sign in with any of those external identities.

So when they click on a sign in button within our application, they're directed at an external ID provider sign in page.

You might have experienced one of these before.

This is an example of the sign in with Google page.

After a customer authenticates with their Google credentials, which it's worth pointing out that we never have access to.

Because this sign in takes place on the external identity provider.

In any case we receive a Google token as a result, but it could be a Facebook token, an Amazon token or whatever external ID provider is used.

Crucially it can be one of many different types.

And if we want to support many different external identity providers, then we need to configure that support.

But now that we have this external ID provider token, this proves that a user has logged in with an external ID provider.

This token can't be used to access AWS resources and that's where identity pools come in handy.

Our application takes this token and passes it to an identity pool that we've configured.

We've configured this to support every external identity that we want to allow logins from.

This is a key thing to keep in mind.

If we want to support five external ID providers, we need five different configurations, five different types of token to be supported.

What happens next is that Cognito is configured with roles, at least one for authenticated identities and one for unauthenticated or guest identities.

In this case we have an authenticated identity, the Google token.

And so on our behalf Cognito assumes a role and generates temporary AWS credentials which are then passed back to the application.

The application can then use these credentials to access AWS resources.

Once they expire, the application renews them again using Cognito and the process continues.

The permissions the application has are based on the roles permissions.

At no point does the application store any credentials within code or any credentials permanently.

So the process is that an external identity provider authenticates a user, Cognito identity pools swap the external ID token for temporary credentials and these are used to authorize access to AWS resources.

So once again focus on the fact that user pools are about sign in and sign up for users and identity pools are about swapping identity tokens from an external ID provider for temporary AWS credentials.

These are two very different and isolated tasks.

Now you can use user pools and identity pools together to fix one small lingering problem.

With this configuration your application has to be able to deal with many different ID tokens from many different external providers.

Now one option is that we could use user pools to handle the many different types of identity and then we can use identity pools to swap the Cognito user pool token for AWS credentials.

Now the swapping of any external ID provider token for AWS credentials is known as Web Identity Federation and you're going to experience that term both in the real world and in the exam.

So let's quickly step through the final architecture which combines both user pools and identity pools.

We start with a user pool and this is configured to support external identities and its internal store of users.

Whatever is used, whichever identity type is used to log in, the identity that's authenticated is now a Cognito user pool user.

So there's only one type of token which is generated whether sign in is using internal users or social sign in.

This is the user pool token or JWT.

By using a user pool we've abstracted away from all of the configuration of many different external ID providers.

We have conceptually one user store to manage, one set of user profiles all provided via a Cognito user pool.

So if you log in with a user pool user or if you log in via the user pool but using Google credentials the outcome is the same.

A user pool token is returned to the application so the user pool simplifies the management of identity tokens.

Next the application can pass this user pool token into an identity pool and this assumes an IAM role defined in the identity pool which generates temporary AWS credentials and these temporary credentials are returned to the application.

The benefit to this approach is that the identity pool need only be configured with a single external identity provider, the user pool.

But otherwise the process is the same as using an identity pool directly just with less admin overhead.

The application can then use those AWS credentials to access AWS resources and that's pretty much everything I wanted to cover.

Now in summary user pools manage user sign up and user sign in either internal or using social logins.

And what you get as a result is a user pool token also known as JSON web token or JWT and that is the output of any form of sign in using user pools.

Now identity pools swap external identity tokens for AWS credentials.

This process is called federation.

External identity tokens can be direct external identity tokens such as Google, Amazon, Facebook and many others or they can be user pool tokens which can themselves represent external ID logins.

Once an application uses an identity pool to gain access to temporary AWS credentials it can access AWS resources.

Now this process allows for a near unlimited number of users.

An unlimited is much more than the 5000 I am user limit which means this is great for web scale applications.

Now you're going to get experience of identity pools in an upcoming advanced demo.

For now though that's everything that I wanted to cover.

Really try to focus on understanding the two different parts of Cognito really well.

I promise it will be helpful for both the exam and for the real world.

Now at this point that's everything I wanted to cover so 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 and in this lesson I want to cover another product within the Kinesis family, Kinesis Video Streams.

Now this product is a little bit different than the others in the family, it's still used for streams but this time for video data.

So let's jump in and take a look.

Kinesis Video Streams allows you to ingest live video streaming data from producers and producers can be security cameras, smartphones, cars, drones or non-video but time serialized data such as audio data, thermal data, depth or even radar data.

Now once the media is inside AWS then consumers can access the data frame by frame or as needed to perform further analysis and on the next screen I'll be demonstrating an architecture involving recognition which is a service I cover elsewhere in the course.

Kinesis Video Streams can persist data and encrypt data both in transit and at rest and it does this as a managed service.

Now you can't access the data directly that's ingested by Kinesis Video Streams and that's really critical to understand for the exam.

It's not stored in its original format, it's all been indexed and stored in a structured way inside the product so don't let any exam question fool you into thinking that you can access the data directly on storage such as EBS or S3 or EFS.

It's not possible you have to go via the product itself.

Now Kinesis Video Streams integrates with other AWS services and two really common examples a recognition for live stream deep learning based analytics for example facial recognition and something like Kinect for voicemail or other audio streaming.

Now let's step through a fairly common style of architecture which uses Kinesis Video Streams and recognition because this should help you understand all the different components and how they can be used for the exam.

Now let's say we have a smart home so we have a cat, a doggo and three video cameras and we want a solution where we can detect any known or unknown faces in the house and alert us if anything is concerning so those three cameras stream their video feeds into AWS specifically three Kinesis Video Streams one per camera.

Now this means we don't need any processing in the house no hardware designed to perform complex analysis on the video and it means that we've got a location to store the video data in some form outside of the property.

So we configure those three video streams to integrate with recognition video this is a product I've talked about elsewhere in the course which provides deep learning based intelligence for images and video and one of the things that it can do is facial recognition on live video streams so the Kinesis Video Streams are integrated with recognition and we also define a face collection so data on some known faces which we expect in our house so we've got Bob the homeowner, Julie his friend another random friend and Whiskers small group of cat sitters for when his human minion isn't around.

Now recognition then analyzes the streamed data and outputs an analysis to a Kinesis data stream.

The analysis includes details of any faces which are detected in the video stream and in addition to that list of detected faces it can identify any of those which it has a level of confidence match one of the faces in the face collection.

Now we can configure a lambda function to be invoked based on records in the Kinesis data streams so the lambda function is invoked and can analyze every record in the stream and then it can make some logic based decisions based on whether it detects known or unknown faces and if a face is detected which shouldn't be there then the lambda function can utilize the simple notification service which can be used to send Bob or Julie a notification and this is an example of a very simple architecture using Kinesis video streams and recognition that can be used for an event driven video analytics workflow.

Now the product is capable of doing so much more but in the exam if you see any mention of any live video streaming and any analytics that needs to be performed on that video stream if you see any mention of G streamer or RTSP then you can probably think about using Kinesis video streams as your default answer.

With that being said though I don't expect it to feature in the exam in a detailed way so that's everything that you need to know to cover you for any exam questions so go ahead complete this video and when you ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover Amazon Kinesis Data Analytics.

This is a real-time data processing product and it's critical that you understand its features together with when you should and shouldn't use it for the exam.

Before I start talking about Kinesis Data Analytics I want to position the product relative to everything else.

Kinesis data streams are used to allow the large-scale ingestion of data into AWS and the consumption of that data by other compute resources known as consumers.

Kinesis Data Firehose provides delivery services.

It accepts data in and then delivers it to supported destinations in near real-time and it can also use Lambda to perform transformation of that data as it passes through.

Kinesis Data Analytics is a service which provides real-time processing of data which flows through it using the structured query language known as SQL.

Data inputs at one side, queries run against that data in real-time and then data is output to destinations at the other.

The product ingests from either Kinesis data streams or Kinesis Firehose and can optionally pull in static reference data from S3 but I'll show you how that works visually in a moment.

Now after data is processed it can be sent on in real-time to destinations and currently the supported destinations are Firehose and indirectly any of the destinations which Firehose supports but keep in mind if you're using Firehose then the data becomes near real-time rather than real-time.

The product also directly supports AWS Lambda as a destination as well as Kinesis Data Streams and in both of those cases the data delivery is real-time so you only have near real-time if you choose Firehose or any of those indirect destinations.

If you use Lambda or Kinesis Data Streams then you keep the real-time nature of the data.

Conceptually the product fits between two streams of data input streams and output streams and it allows you in real-time to use SQL queries to adjust the data from the input to the output.

Now let's look at it visually because it will be easier to see how all of the various components fit together.

So on the left we start with the inputs the source streams and this can be Kinesis Streams or Kinesis Firehose.

In the middle we create a Kinesis Analytics application this is a real-time product and I'll explain what that means in a second.

The Kinesis Analytics application can also take data in from a static reference source an S3 bucket and then the Kinesis Analytics application will output to destination streams on the right so Kinesis Streams or Kinesis Firehose.

Remember all of these are external sources or destinations they exist outside of Kinesis Data Analytics.

Kinesis Data Analytics doesn't actually modify the sources in any way what actually happens is this inside the analytics application you define sources and destinations known as inputs and outputs.

So conceptually what happens is for the input side objects called in application input streams are created based on the inputs.

Now you can think of these like normal database tables but they contain a constantly updated stream of data from the input sources the actual Kinesis Streams or Firehose.

These exist inside the analytics application but they always match what's happening on the streams which are outside of the application.

Now the reference table is a table which matches data contained within an S3 bucket and it can be used to store static data which can enrich the data coming in over the streams.

Consider the example of a popular online game where a Kinesis Stream has all of the data about player scores and player activities.

In this particular case the reference table might contain data on player information which can augment the stuff coming in via the stream so if the stream only contains the raw score and activity data then the reference data will contain other metadata about those players so maybe player names certain items the player has or awards and these can all be used to enrich the data that's coming in real time from Kinesis Streams.

Now the core to the Kinesis Analytics application is the application code and this is coded using the structured query language or SQL.

It processes inputs and it produces outputs so in this case it operates on data in the in application input stream table and the reference table and any output from the SQL statement is added to in application output streams and again think of these like tables which exist within the Kinesis Analytics application only these tables map onto real external streams so any data that's outputted into those tables by the Kinesis Analytics application is entered onto the Kinesis Stream or Kinesis Firehose and then these will feed into any consumers of the stream or destinations of the firehose.

Additionally any errors generated by the SQL query can be added to an in application error stream and all of this happens in real time so data is captured from the source streams via the in application input stream so the virtual tables it's manipulated by the analytics application using the SQL query and then stored into the in application output streams which put that data into either the external Kinesis Stream or external Kinesis Firehose.

All of this just to stress it again happens in real time and if the output data is delivered into a Kinesis Stream then it stays real time if the output data is delivered into a Kinesis Firehose then it becomes near real time delivering to all of those supported destinations.

Now you only pay for the data processed by the application but it is not cheap so you should only use it for scenarios which really fit this type of need and before we finish this lesson let's talk about that the scenarios where you might choose to use Kinesis data analytics.

Now there are some particular use cases or scenarios which fit using Kinesis data analytics at a high level this is anything which uses streaming data that needs real time SQL based processing so things like time series analytics so maybe election data and e-sports things like real-time dashboards for games so high score tables or leaderboards and even things like real-time metrics for security and response teams anything which needs real-time stream-based SQL processing is an ideal candidate for Kinesis data analytics.

Now I mentioned in the previous lesson that data firehose can also support transformation of data using lambda but remember the key differentiator is that data firehose is not a real-time product and using lambda you're restricted to relatively simple manipulations of data.

Using Kinesis data analytics you can create complex SQL queries and use those queries to manipulate input data into whatever format you want for the output data so it has a lot more in terms of features than data firehose so if you're dealing with any exam questions which need really complex manipulation of data in real-time then Kinesis data analytics is the product to choose.

Okay so with that being said that's everything that I wanted to cover in this theory lesson go ahead complete the lesson and then when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk in detail about Amazon Kinesis data firehose.

Now this is one product out of the Kinesis product set which combined a design to cope with large amounts of streaming data ingestion consumption and management within AWS.

Now it's important for the exam that you really understand the different situations when you would use each of the Kinesis family of products so let's jump in and explore data firehose in detail.

You learned in the last lesson that Kinesis data streams is a product which provides a way for producers to send huge quantities of data into AWS, storing that data for a window of time and then allowing multiple consumers to consume that data at different rates.

Now producers need to be designed to put data into Kinesis and consumers need to be designed to consume data from Kinesis.

What Kinesis by default doesn't offer is a way to persist that data.

Once records in Kinesis age past the end of the rolling window then they're gone forever.

Now Kinesis data firehose is a fully managed service to deliver data to supported services including S3 which lets data be persisted beyond the rolling window of Kinesis data streams.

Data firehose is also used to load data into data lake products, data stores and analytics services within AWS.

So data firehose scales automatically.

It's fully servalous and it's resilient.

Firehose accepts data and it offers near real-time delivery of that data to destinations.

Now this is key for the exam.

It is not a real-time product, it is a near real-time product.

So generally the delay is anywhere around the 60 second mark.

So it's not like Kinesis which offers consumers fully real-time access to data which is ingested.

Firehose is near real-time.

So remember that one for the exam.

Firehose also supports the transformation of data on the fly using lambda.

Anything that you can define in a lambda function can be done to data being handled by firehose but be aware that it can add latency depending on the complexity of the processing.

Now firehose is a pay-as-you-go service.

You'll build based on data volume passing through the service.

So it's a really cost-effective service which handles the delivery of data through to supported destinations.

So let's look at the architecture of firehose visually.

We start with Kinesis data firehose in the middle.

The end result of firehose is to deliver incoming data through to a number of supported destinations.

Now these are important for you to remember for the exam.

You need to be able to pick if firehose is a valid solution and for that you need to know the valid destinations for the service.

So it can deliver data to HTTP endpoints which means it can deliver to third-party providers.

It directly supports delivery to Splunk.

It can deliver data into Redshift.

It can also deliver data into Elasticsearch and then finally it can deliver data into S3.

Firehose can directly accept data from producers or that data can be obtained from a Kinesis data stream.

So if you already have a set of producers adding data into a Kinesis data stream then we might want to integrate that with firehose.

Remember these producers are adding data into the Kinesis stream.

That data is available in real time by any consumers of that stream but Kinesis offers no way to persist that data anywhere or no way to deliver it natively to any other services.

But what we can do is to integrate the Kinesis data stream with the Kinesis firehose delivery stream.

That data is delivered into firehose in real time.

Now producers can also send data directly into firehose if you have no need for the features that Kinesis data streams provide or you just want to use firehose directly.

In any case firehose actually receives the data in real time but this is where that changes.

So even though firehose receives data in real time firehose itself is not a real-time service.

Kinesis data streams are real time but firehose is what's known as a near real-time service.

What this means in practice is that any data being handled by the service is buffered for delivery.

Firehose waits for one MB of data or 60 seconds.

These can be adjusted but these are the general minimums of the product.

So for low volume producers firehose will generally wait for the full 60 seconds and then deliver that data through to the destinations.

For high volume producers it will deliver every MB of data that's injected into the product.

So even though firehose gets the data in real time it doesn't deliver it to the destination in real time and that's essential to remember for the exam.

So if there are any answers which involve firehose it cannot be a real-time solution.

It can only be near real time.

So from an AWS perspective something in the range of 200 milliseconds would be a real-time product but something in the range of 60 seconds would be classified as near real time and you need to get a feel for the differences between those two and which products fit into which of those categories.

Now firehose can actually transform the data passing through it using lambda.

So source records added to firehose are sent to a lambda function and functions can be created from blueprints to perform common tasks and then transformed records are sent back for delivery but this can add to the latency of data flowing through the product.

And if you do decide to do a transform then you can optionally store the unmodified data in a backup bucket which you define.

Once the buffer or time buffer passes then data is passed into the final destinations so transformed records can be sent into S3 or directly to Elasticsearch or directly to Splunk or HTTP endpoints.

The only exception to this architecture for delivery is when you're using Redshift.

What happens with Redshift is it uses an intermediate S3 bucket and then runs a Redshift copy to bring the data from S3 into the product.

So even though conceptually it's direct when used you're actually copying data to an intermediate location an S3 bucket and then you're running the copy command to pull that data into Redshift and that's handled all end-to-end by the data firehose product.

Now there are a few common situations where firehose will be used.

You might use it to provide persistence to data coming into a Kinesis stream so providing a permanent storage of data that comes into a stream so it's not lost when it exits the rolling window that Kinesis data streams provide or you might use it if you want to store data in a different format because firehose can transform it using Lambda.

Or you might want to deliver data that comes either directly into firehose or via data stream into one of the supported products.

But just keep in mind though it is not real-time.

I need to stress that for the exam it's only near real-time.

You trade the fact that you don't have to build this yourself so you don't need to put in the effort to build this solution but what you lose is the real-time nature of Kinesis.

If you need a solution which handles data in real-time then you need to stick to Kinesis and use something like a Lambda function to handle what to do with that data.

Say delivering it in real-time to Elasticsearch.

Now with that being said that is everything I wanted to cover in this lesson.

For the exam you just need a good architectural overview of how the firehose product works and some of the scenarios which it might be used for.

So really try to focus on these core concepts.

Exactly what firehose does.

Try to commit to memory that it's only a near real-time product and make sure that you remember all of the supported destinations.

Now thanks for watching.

Go ahead and complete this lesson and then when you're ready I'll look forward to you joining me in the next.

Welcome back and in this video I want to talk about another product within AWS, Kinesis Data Streams.

So let's just jump in and get started.

Kinesis is a service that a lot of people I talk to confuse with SQS.

There are even exam questions which test your ability to select between the two.

Now this shouldn't be a difficult thing to do because they're actually very different products designed for different situations.

Kinesis is a scalable streaming service.

Now what I mean by this is that it's designed to ingest data, lots of data from lots of devices or applications.

Producers send data into a Kinesis stream.

The stream is the basic entity of Kinesis and it can scale from low levels of data throughput to near infinite amounts of data.

Now Kinesis is a public service and it's highly available in a region by design.

You don't need to worry about replication or providing access from a network perspective like other application services within AWS.

All of this is handled as a service.

Kinesis Streams provide a level of persistence.

You have a default 24 hour rolling window so when data is ingested by a Kinesis stream from a producer it's accessible for 24 hours by default from that point.

So data which is 24 hours and one second old is discarded.

Now as a product it includes storage for that amount of data so however much you ingest within that 24 hour period the storage is included.

And this window can be increased up to a maximum of 365 days for additional costs.

Kinesis supports lots of producers pushing data into a stream but also multiple consumers reading data from that same stream.

And consumers can access data from anywhere within the rolling window.

For example the default 24 hours.

And each of these consumers might access this data at different levels of granularity so maybe looking at data every second or looking at data points once per minute or once per hour.

This makes Kinesis great for things like analytics and dashboards.

Now visually the product architecture looks like this.

On the right we have producers and these might be things like EC2 instances, on-premises servers, mobile applications or devices and even things like IoT sensors.

On the left we have consumers.

Again these could be on-premises servers running software to access Kinesis, EC2 instances or even Lambda functions which can be configured to invoke when data is added to the stream.

In the middle is the stream itself and it's into this that producers send data so the stream ingests this data.

And it's from this that consumers read the data.

Now the way that a Kinesis stream scales is by using a shard architecture.

A stream starts off with one shard and as additional scale is required shards are added to the stream.

Now each shard provides its own capacity.

One MB per second of ingestion capacity and two MB per second of consumption.

The more shards a stream has the more expensive it is and the more performance that it provides.

Now what also impacts the price is the data window.

As I mentioned previously by default a stream provides a 24 hour window and this can be increased up to 365 days for additional cost.

And remember the window is also persistent so a 365 day window means 365 days worth of data stored by Kinesis.

The way that the data is stored on a stream is via Kinesis data records and these have a maximum size of one MB.

Kinesis data records are stored across shards meaning the performance scales in a linear way based on the number of shards.

Kinesis also has a related product called the Kinesis data fire hose and there will be a separate video discussing this in more detail.

This connects to a Kinesis stream and can move the data which arrives onto a stream en masse into another AWS service.

An example being S3.

So if you have a fleet of sensors which stream data into Kinesis and that's used for real time analysis but if you also need to store this longer term maybe to analyse it using a different AWS product such as EMR which is a big data analytics tool then you can put that data into S3 using Kinesis fire hose.

Now I just want to spend a few moments more comparing SQS and Kinesis so that you understand the differences from a conceptual level.

Now one of the common areas of confusion is this difference between these two products.

When should you pick SQS versus Kinesis?

Well if you're in the exam and you're reviewing one particular question then you need to review it through this lens.

Is the question about the ingestion of data or is it about worker pools decoupling or does it mention asynchronous communications?

Well if it's about the ingestion of data it's going to be Kinesis.

If it's about any of the others then assume it's SQS first and only change your mind if you have strong reasons to do so.

SQS generally has one thing or one group of things sending messages to the queue.

This might be something like a web tier inside an auto scaling group.

Generally you won't have hundreds or thousands of sensors sending to an SQS queue.

It's not designed for that type of workflow.

Additionally you'll generally only have one consumer or group of consumers reading from the queue, generally a worker tier.

SQS queues are generally used for decoupling application components.

They allow asynchronous communications where the sender and receiver don't need to be aware of each other and don't care about each other.

SQS also doesn't really provide the concept of persistence.

Messages on a queue are temporary.

Once they're received and processed the next step is deletion at which point they're gone forever.

There's no concept of a time window within SQS queues.

Now contrast this to Kinesis.

It's designed for huge scale ingestion of data.

Lots of things sending data into a stream at potentially super high data rates.

And it's designed for multiple consumers, each of which might be consuming data at different rates.

Kinesis is designed for ingestion, analytics, monitoring, application clicks or mobile click streams.

If you think for a minute about the two products they aren't all that similar, either in function or in terms of the ideal architecture.

Try and make sure that before you go into the exam you really clearly see the distinction between these two products.

There's always going to be one or two questions asking you about either of these products and generally one which asks you to pick between them for a given scenario.

Now that's everything that I wanted to cover in this video at the high level about Kinesis data streams.

Thanks for watching, 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 lesson I want to talk about dead letter queues which is another piece of SQS functionality which you need to be aware of.

So let's just jump in and get started.

Dead letter queues are designed to help you handle reoccurring failures while processing messages which are within an SQS queue.

So let's say that you have a queue and inside this queue is a single message and let's say that this particular message is problematic.

Something about it is causing errors while processing it.

So the first time that it's received it's invisible for the duration of the visibility timeout.

Then once the visibility timeout expires it appears again in the queue assuming that it hasn't been successfully processed and then explicitly deleted.

But imagine that this process happens again and again.

The message is received, processing fails and eventually the message appears again after the visibility timeout.

This process could continue forever and it's this issue which dead letter queues aim to fix.

Every time the message is received the receive count attribute is incremented initially 1 then 2 then 3 then 4 then 5 and so on.

What we can do is define a redrive policy.

So this defines the source queue, the dead letter queue to use and the conditions where the message will be moved into this dead letter queue and it defines a variable called max receive count.

So how this works is that when the receive count on a given message is more than the max receive count and when the message isn't explicitly deleted it's moved to the dead letter queue.

Setting up a dead letter queue gives you some really useful pieces of functionality.

It allows you to configure an alarm for any messages which are delivered to a dead letter queue so this could automatically notify you if you have any problematic messages.

It's a separate area which allows you to perform separate isolated diagnostics so you can examine logs for a particular message to determine why it's repeatedly failed processing.

You can analyze the contents of messages which are delivered to a dead letter queue to diagnose what's causing the issue and it also allows you to test or apply separate processing which can be used for problematic messages.

Now one really important thing to keep in mind when you're using dead letter queues in the real world all SQS queues have retention periods for messages so if a message ages past a certain point and hasn't been processed then that message is dropped.

Now the way that this works is that when a message is added to a queue it has an N queue timestamp so the timestamp of the point that it was sent into the queue.

Now when you're moving a message from a normal queue to a dead letter queue this N queue timestamp is not adjusted so it remains the same the timestamp is maintained and it's the date and time when it was added to the original queue so you have to be really careful when a message is moved into a dead letter queue.

If a message for example has been in a source queue for one day and the retention period on a dead letter queue is two days the message will only remain in the dead letter queue for one additional day because this original N queue timestamp is used rather than the date and time that the message was moved into the dead letter queue so generally the retention period of dead letter queues should be longer than source queues and this takes into account that the N queue timestamp is not updated when the message is moved between queues.

So dead letter queues are a really useful architecture which allows you to build additional rigor into any processes surrounding queues.

It allows you to define this dead letter queue which helps with diagnostics, you can add additional processing features which allow problematic messages to be processed and many other use cases and finally a single dead letter queue can be used for multiple source queues so that's also something to keep in mind.

Now that's everything I wanted to cover in this lesson so 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 and in this lesson I want to cover a feature of SQS called delay cues.

And this is going to be a quick topic.

It's just something that you'll need to understand for the exam and it might come in useful for the real world.

So let's just jump in and get started.

Delay cues at a high level allow you to postpone the delivery of messages to consumers.

Now as a refresher, by now you'll understand the concept of a visibility timeout.

The concept is simple enough but we'll use this as an opportunity for a quick refresher.

So we start with an SQS cue and inside this cue we send a single message which has added to the cue using the send message operation.

Once a message is in the cue, messages can be polled using receive message.

And while the message is being processed, the visibility timeout takes effect.

During this time any further receive message calls will return no results.

During this processing period, either the process will complete and the message will be explicitly deleted or not.

If not, this suggests a failure in processing and the message will reappear on the cue.

Now the visibility timeout period is configurable.

The default is 30 seconds and the valid range is 0 seconds through to 12 hours.

And this value can be changed on a per cue or per message basis in which case it's changed with the change message visibility operation.

Now the critical thing to understand about visibility timeout is that messages need to appear on the cue and be received before this visibility timeout occurs.

So this is used to allow automatic reprocessing.

So you receive messages from a cue and you begin processing.

If that processing fails and the application doing it crashes, it might not be in a position where it can tell the cue that processing has failed.

And so visibility timeout means that after a certain configurable duration that message will reappear in the cue and can be processed again.

So visibility timeout is generally used for error correction and automatic reprocessing.

Now a delay cue is significantly different.

With a delay cue we configure a value called delay seconds on that cue.

Now this means that messages which are added to the cue will start off in an invisible state for that period of time.

So when messages are added they're conceptually parked or invisible for that duration of time.

They're not available on the cue.

During this delay seconds period any receive messages operation will return nothing.

Once the period expires the message will be visible on the cue.

Now the default is zero and for a cue to be a delay cue it needs to be set to a non-zero value and the maximum is 15 minutes.

You can also use message timers to configure this on a per message basis and this has the same minimum of zero and maximum of 15 minutes.

But it is important to know that you can't use this per message setting on 5-0 cues.

It's not supported.

Delay cues in a way are similar to visibility timeouts because both features make messages unavailable to consumers for a specific period of time.

But the difference between the two is that for delay cues a message is hidden automatically when it's first added to the cue.

Using visibility timeouts a message is initially visible and it's only hidden after it's consumed from the cue and automatically reappears if that message isn't deleted.

So delay cues are generally used when you need to build in a delay in processing into your application.

Maybe you need to perform a certain set of tasks before you begin processing a message or maybe you want to add a certain amount of time between an action that a customer takes and for the processing of the message that represents that action.

Visibility timeouts are used to support automatic reprocessing of problematic messages.

So it's important to understand that these two are completely different features.

Now with that being said that is everything I wanted to cover in this lesson.

I'll make sure I include some links attached to this lesson which provide additional information but this is what you'll need to understand for the exam and to get started in the real world.

At this point though you can go ahead and complete the video and when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to quickly step through the differences between standard SQSQs and FIFO SQSQs.

So let's quickly jump in and get started.

To get started with understanding some of the architectural differences between standard and FIFO Qs, I want you to think about FIFO Qs as single-lane highways and then think about standard Qs as multi-lane highways.

Imagine the messages as cars driving along these highways.

What this means is that the performance of a FIFO Q, so the number of cars per second in this analogy and the number of messages per second in reality, is limited by the width of the road.

FIFO Qs can handle 300 messages per second without batching and 3000 width.

Now this is actually 300 transactions per second to the SQS API when using FIFO mode.

Each transaction is one message but with batching it means that each transaction can contain 10 messages.

Now it's worth mentioning at this point that there is a high throughput mode for FIFO but at the time of creating this lesson it's only available in preview.

Standard Qs, so multi-lane highways in this analogy, don't suffer from any real performance issues and can scale to a near infinite number of transactions per second.

FIFO Qs as the name suggests guarantees order.

They're first in, first out, so what you're trading is performance for this preserved order.

They also guarantee exactly once processing, removing the chance of duplicate message delivery.

Now another odd restriction is that FIFO Qs have to have a FIFO suffix in order to be a valid FIFO Q.

Now remember that one because I've seen it come up in the exam many times before.

Now FIFO Qs are great for workflow based order processing, command ordering, so if you've got a system administrator who's entering commands into a processing system and you need the order of those commands to be maintained then FIFO Qs are ideal as well as any sequential iterative price adjustment calculations for sales order workflows.

Now standard Qs, so the multi-lane highways of Qs, they're faster.

Conceptually think of this as multiple messages being carried on the highway at the same time, so the multi-lane part of this analogy.

But because of this there are a few important trade-offs.

First, there's no rigid preservation of message ordering, it's best efforts only.

And second, what's guaranteed is only at least once message delivery, meaning in theory messages can be delivered more than once, so any applications which use standard Qs need to be able to accommodate the potential for multiple of the same messages to be delivered.

Now standard Qs are ideal for decoupling application components or for workable architectures or to batch together items for future processing, so all of these are ideal use cases for standard SQSQs.

Now that's everything I wanted to cover, I just wanted to make sure that for the exam you understand the difference in architecture between these two different Q types.

Thanks for watching, go ahead and complete the lesson and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover the architecture of another really important product within AWS.

It's something I've already mentioned in other lessons and it's the simple queue service or SQS.

So let's jump in and explore what the product provides and exactly how it works.

Simple queue service or SQS provides managed message queues.

And it's a public service so it's accessible anywhere with access to the AWS public space endpoints.

And this includes private VPCs if they have connectivity to the services.

It's fully managed so it's delivered as a service.

You create a queue and the service delivers that queue as a service.

Now queues are highly available and highly performant by design.

So you don't need to worry about replication and resiliency.

It happens within a region by default.

Now queues come in one of two types, standard queues and FIFO queues.

FIFO queues guarantee an order.

So if messages one, two and three are added in that order to a FIFO queue, then when you receive messages you'll also see them in order.

So one, two and then three.

With a standard queue this is best efforts.

But there's always the possibility with a standard queue that messages could be received out of order.

Now FIFO queues do come with some other considerations but more on that later.

Now the messages which are added to a queue can be up to 256 kilobytes in size.

If you need to deal with any data which is larger, then you can store it on something like S3 and link to that object inside the message.

Architecturally though, ideally you want to keep messages small because they're easier to process and manage at scale.

Now the way that a queue works is that clients can send messages to that queue and other clients can poll the queue.

And polling is the process of checking for any messages on a queue.

And when a client polls and receives messages, those messages aren't actually deleted from the queue.

They're actually hidden for a period of time, the visibility timeout.

Now the visibility timeout is the amount of time that a client can take to process a message in some way.

So if the client receives messages from the queue, if it finishes processing whatever workload that that message represents, then it can explicitly delete that message from the queue, and that means that it's gone forever.

But if a client doesn't explicitly delete that message, then after the visibility timeout, the message will reappear in the queue.

Architecturally this is a great way of ensuring fault tolerance because it means that if a client fails when it's processing a job, or maybe even fails completely, then the queue handles the default action to put the message back in the queue, which makes that message available for processing by a different client.

So the visibility timeout is really important.

It's something that features regularly on the exam.

Just be aware that the visibility timeout is the amount of time that a message is hidden when it's received.

If it's not explicitly deleted, then it appears back in the queue to be processed again.

Now SQS also has the concept of a dead letter queue.

And this is a queue where problem messages can be moved to.

For example, if a message is received five or more times and never successfully deleted, then one possible outcome of that can be to move the message to the dead letter queue.

And dead letter queues allow you to do different sets of processing on messages that can be problematic.

So if messages are being added to the queue in a corrupt way, or if there's something specific about these messages that means different styles of processing are required, then you can have different workloads looking at the dead letter queue.

Now I've already talked about how queues can be used to decouple application components.

One component adds things to the queue, another reads from the queue, and neither component needs to be aware or worry about the other.

But queues are also great for scaling.

Auto scaling groups can scale based on the length of the queue, and lambdas can be invoked when messages appear on a queue.

And this allows you to build complex worker pool style architectures.

Now this is a pretty common style of architecture that you might see which involves a queue.

So you might have two auto scaling groups.

The one on the right is the web application pool and the one on the left is a worker pool.

So a customer might upload a master video to the web application pool via a web app.

And the master video is taken by this web application pool and it's stored in a master video bucket, and a message is also added to an SQS queue.

Now the message itself has a link to the master video, so the S3 location that the master video is located at, and this avoids having to deal with unwieldy message sizes.

And at this point that's all that the web pool needs to do.

That's where the responsibility ends for this particular part of the application.

Now the web pool is controlled by an auto scaling group, and its scaling is based on CPU load of the instances inside that auto scaling group, meaning that it grows out as the load on the system increases.

The scaling of the worker pool is based on the length of the SQS queue, so the number of messages in the queue.

As the number of messages on the queue increases, the auto scaling group scales out based on this number of messages.

So it adds additional EC2 instances to cope with the additional processing.

So instances inside this auto scaling group, they all pool the queue and receive messages.

And these messages are linked to the master video, which is stored in the master bucket, which they also retrieve.

Now they perform some processing on that video, in this example generating different sizes of videos, and they store them in a different bucket.

And then the original message that was on the queue is deleted.

Now if the processing fails, or even if an instance fails, then it will be reprovisioned automatically by the auto scaling group, and the message that it was working on will automatically reappear on the queue after the visibility timeout has expired.

As the queue empties, the number of worker instances scales back in, all the way to zero if no processing workloads exist.

So the auto scaling group that's running the worker pool is constantly looking for the length of the queue.

When messages appear on the queue, the auto scaling group for the worker pool scales out, adds additional instances, those instances poll the queue, retrieve the messages, download the master video from the master bucket, perform the transcode operations, store that in the transcode bucket, delete the message from the queue, and the size of the worker pool auto scaling group will scale back in as that workload decreases.

Now this is an example of a worker pool elastic architecture that's using an SQSQ.

At this point, the responsibilities of the worker pool have finished.

It doesn't have any visibility of or care about the health of the web pool.

It purely responds to messages that appear inside the SQSQ.

So the effect of the SQSQ is to decouple these different components of this application and allow each of them to scale independently.

Once the worker pools finished its processing, then the web pool can retrieve the videos of different sizes from the transcode bucket and then present these to the user of our application.

Now this video processing architecture is one that's generally used to illustrate exactly how queues function.

So a multi-part application where one part produces a workload and the other part scales automatically to perform some processing of that workload.

It's actually a simplified version of the architecture that would generally be used in a production implementation of this.

For workloads like this where one job is logged and multiple different outputs are needed, generally we would use a more complicated version which looks something like this.

It has a similar architecture but it uses SNS and SQS fan out.

And the way that that works is once the master video is uploaded from our application user and placed into the master video bucket, a message is sent, but instead of the message going directly onto an SQSQ, the message is added onto an SNS topic.

Now this SNS topic has a number of subscribers.

For each different video size required, there is one independent SQS queue configured as a subscriber to that topic.

So in this example, one for 480p, one for 720p and one for 1080p.

So each size has its own queue and its own auto scaling group which scales based on the length of that individual queue.

And this means that if the different workload types need different sizes or capabilities of instances, then they can independently scale.

S3 buckets are capable of generating an event when an object is uploaded to that bucket, but it can only generate one event.

So in order to take that one event and create multiple different events that can be used independently, you'll use this fan out design.

So you'll take one single SNS topic with multiple subscribers, generally multiple SQS queues, and then that message will be added into each of those queues, allowing for multiple jobs to be started per object upload.

Now I want you to really remember this one for the exam.

You can't see me right now, but I'm winking as much as I can.

Really, really remember this one for the exam, this fan out architecture, because it will come in handy for the exam, I promise you.

But at this point, let's move on to the last few points that I want to cover before we finish this theory lesson.

I mentioned at the start of the lesson that there are two types of queues, standard and FIFO.

It's important that you understand the differences and benefits and limitations of both of these.

So think of standard queues like a multi-lane highway, and think of FIFO queues like a single lane road with no opportunity to overtake.

Standard queues guarantee at least once delivery, and they make no guarantees on the order of that delivery.

FIFO queues both guarantee the order and guarantee exactly once delivery, and that's a critical difference.

With standard queues, you could get the same message delivered twice on two different poles, and the order can be different.

FIFO queues guarantee exactly once delivery, and also they guarantee to maintain the order of messages in the same order as they were added.

So first in, first out.

Now, because FIFO queues are single lane roads, their performance is limited. 3,000 messages per second with batching, and 300 per second without.

So FIFO queues don't offer exceptional levels of scaling, because standard queues are more like multi-lane highways, and they can scale to a near infinite level, because you can just continue adding additional lanes to that multi-lane highway.

So standard queues scale in a much more linear and fluid way.

With SQS, you'll build on requests, and a request is not the same as a message.

A request is a single request that you make to SQS.

So one single request can receive between one and ten messages, or zero, and anywhere up to 64 kilobytes of data in total.

So SQS is actually less efficient and less cost effective the more frequently that you make requests, because you'll build based on requests, and requests can actually return zero messages, the more frequently that you poll an SQS queue, the less cost effective the service is.

Now why this matters is there are actually two ways to poll an SQS queue.

You have short polling and long polling.

Short polling uses one request, and it can receive zero or more messages.

But if the queue has zero messages on that queue, then it still consumes a request, and it immediately returns zero messages.

This means that if you only use short polling, keeping a queue close to zero length would require an almost constant stream of short polls.

Each of these consuming a request, and each of these being a billable item based on the product.

Now long polling on the other hand is where you can specify await time seconds, and this can be up to 20 seconds.

If messages are available on the queue, when you lodge the request then they will be received.

Otherwise it will wait for messages to arrive.

Up to 10 messages and 64 kilobytes will be counted as a single request, but it will wait for up to 20 seconds until messages do arrive on the queue.

Long polling is how you should poll SQS, because it uses fewer requests.

It will sit waiting for messages to arrive on the queue if non-currently exist.

One final point, because messages can live in an SQS queue for some time, anywhere up to 14 days, the product supports encryption at rest using KMS.

So this is server-side encryption.

It's encryption of the data as it's stored persistently on disk.

Now data by default is encrypted in transit between SQS and any clients, but you need to understand the difference between encryption at rest and encryption in transit.

They're not the same thing.

Now access to a queue is based on identity policies, or you can also use a queue policy.

So identity policies or queue policies can be used to control access to a queue from the same account, but queue policies only can allow access from external accounts.

And a queue policy is just a resource policy, just like the ones that you've used earlier in the course on S3 buckets or SNS topics.

Now that's all of the theory that I wanted to cover about SQS queues.

Thanks for watching.

Go ahead and complete this video.

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

Welcome back and in this lesson I want to go into a little bit more depth about API Gateway.

Now we've got a lot to cover in a single lesson so let's jump in and get started.

API Gateway is a service which lets you create and manage APIs.

Now an API is an application programming interface.

It's a way that applications communicate with each other.

So for example if you run the Netflix application on your TV then it's using an API to communicate with the Netflix back-end services.

API Gateway acts as an endpoint or an entry point for applications looking to talk to your services.

And architecturally it sits between applications which utilize APIs and the integrations which are the back-end services which provide the functionality of that API.

Now API Gateway is highly available and scalable so you don't have to worry about either.

It's delivered as a managed service.

It handles authorizations so you can define who can access your APIs using the API Gateway.

It can be configured to handle throttling so how often individuals can use APIs.

It can perform caching to reduce the amount that your back-end services are called as part of the usage of your API.

It supports cores so you can control security of cross-domain calls within browsers and it supports transformations and all of this within the API Gateway product.

It also supports the open API spec which makes it easy to create definition files for APIs so APIs can be imported into API Gateway and it also supports direct integration with AWS services.

So for things like writing into DynamoDB, starting a step function or anything through to sending messages to SNS topics you might not even need any back-end compute so it's capable of directly integrating with a range of AWS services.

Now API Gateway is a public service and so it can act as the front-end for services running within AWS or on-premises and it can also be an effective migration product to provide a consistent front-end while the backing services are being moved from on-premises into AWS or even re-architected moving from monolithic compute services such as virtual servers through to serverless architectures using Lambda.

Now lastly it can provide APIs that use HTTP, REST or even web socket-based APIs.

Now visually this is how the high-level architecture of API Gateway looks.

We have API Gateway in the middle here and this is acting as the endpoint for the consumers of our API and this could be mobile applications or the APIs or even web applications loaded from static hosting within an S3 bucket.

In any case these all connect to the API running on the API Gateway using the endpoint DNS name.

Now it's actually the API Gateway's job to act as an intermediary between clients and what are called integrations and these are the back-end services which provide the functionality to API Gateway.

API Gateway is capable of connecting to HTTP endpoints running in AWS or on-premises.

It can use Lambda for compute and this is something that's typically used within serverless architectures and as I mentioned previously it can even directly integrate with some AWS services such as DynamoDB, SNS and step functions.

Now there are three phases in most API Gateway interactions.

The request phase which is where the client makes a request to the API Gateway and then this is moved through API Gateway to the service provided by the integrations and then finally the response phase where the response is provided back to the client.

The request phase at a high level does three things.

It authorizes, validates and transforms incoming requests from the client into a form that the integration can handle and then the response takes the output from the integration, it transforms it, prepares it and then returns it through to the client.

API Gateway also integrates with CloudWatch to store logging and metric-based data for request and response side operations and it also provides a cache which improves performance for clients and also reduces the number of requests made to the back-end integrations.

So that's the high-level architecture and through the remainder of this lesson I want to touch on a number of the pieces of functionality in a little bit more detail and we'll start with authentication.

API Gateway supports a range of authentication methods.

Now you can allow APIs to be complete open access so no authentication is required but there are different types of authentication which are supported by the product and let's use the example of the Categorum application which is now serverless.

API Gateway can use Cognito user pools for authentication, this is one of the supported methods.

If this method is used then the client authenticates with Cognito and receives a Cognito token in return assuming a successful authentication.

It passes that token in with the request to API Gateway and because of the tight integration which API Gateway has with Cognito it can natively validate the token.

So that's Cognito but API Gateway can also be extended to use Lambda-based authorization which used to be called custom authorization.

With this flow we assume that the client has some form of bearer token something which asserts an identification and it passes this into API Gateway with the request.

Now at this point API Gateway not knowing how to natively validate this authentication or authorization it calls a Lambda authorizer and it's the job of this function to validate the request.

So it either does some custom compute maybe checking a local user store or it calls an ID provider an external provider of identification to check the ID.

If this all comes back okay and the Lambda function is happy it returns to API Gateway an IAM policy and a principal identifier.

API Gateway then evaluates the policy and it either sends the request on to a Lambda function so invoking the Lambda function or it returns a 403 access denied error if the access is denied.

Now IAM can also be used to authenticate and authorize with API Gateway by passing credentials in the headers but this level of detail is beyond what's required for the exam.

I just think it's useful to give you the architecture visually so you can picture how all the components fit together.

At this point let's move on and talk about endpoint types.

With API Gateway it's possible to configure a number of different endpoint types for your APIs.

First we've got edge optimized and with edge optimized endpoint types any incoming requests are routed to the nearest cloud front pop or point of presence.

We've also got regional endpoints and these are used when you have clients in the same region so this doesn't deploy out using the cloud front network instead you get a regional endpoint which clients can connect into so this is relatively low overhead it doesn't use the cloud front network and this is generally suitable when you have users or other services which consume your APIs in the same AWS region.

Lastly we have private endpoint types and these are endpoints which are only accessible within a VPC via an interface endpoint so this is how you can deploy completely private APIs if you use the private endpoint type.

The next concept I want to talk about are API Gateway stages.

When you deploy an API configuration in API Gateway you do so to a stage for example you might have the prod and dev stage for the Categorum application.

Most things within API Gateway are defined based on a stage so in this case you could have the production application connecting to the prod stage and developers testing new additions via the dev stage.

Each of these stages has its own unique endpoint URL as well as its own settings.

Each of these stages can be deployed onto individually so you might have version one of the API configuration deployed into production and this uses version one of a lambda function as a backing integration and then we might have version two which is currently under development deployed into the dev stage and this also could use a separate backing lambda function containing the new code.

Now you can roll back deployments on a stage so they can be used for some pretty effective isolation and testing but what you can also do with API Gateway stages is to enable canary deployments on stages.

What this means is that when enabled any new deployments which you make to that stage are actually deployed on a sub part of that stage the canary part of that stage and not the stage itself.

So traffic distribution can be altered between the base stage and the canary based on a user configurable value and eventually the canary can be promoted to be the base stage and the process repeated.

In this example it means that version two of the API configuration can be tested by the development team and then canary can be enabled on production.

Version two can be deployed onto production and this will be deployed into the canary because canary is enabled on the production stage.

We can adjust the distribution of traffic between the main production stage and its canary until we can completely happy and then we can promote the canary to be the full base stage and this process of development production cycles can then continue.

If you're not happy with how a canary is performing if it's got bugs or if it's negative in terms of performance then you can always remove it and return back to the base stage.

Now at this point I have to apologize I hate getting you to remember facts and figures but for the exam I genuinely think these facts and figures might help so do your best to note them down and remember them even if you only do it at a high level even if you only get the basics I think it will help you answer certain exam questions quicker and with less thought.

So to start with error codes generated by API gateway are generally in one of two categories.

First we have 400 series error codes and these are client errors this suggests that something is wrong on the client side so something wrong either on the client or in terms of how it's making a request through to API gateway maybe permissions are wrong maybe headers are malformed anything that's on the client side then we have 500 series errors and these are server errors so this indicates that there's a valid request but there's a back-end issue.

Now inside both of these categories there are a number of important requests that you need to remember the error code number four and I want to step through these on this part of the lesson so 400 400 this is one that's really hard to diagnose because it can actually have many different root causes but if you do see a 400 error then you should at least be aware that it's a generic client side error we've got 403 and this suggests an access denied error so either that the authorizer has executed and then indicates to API gateway that the request should be denied or the request has been filtered by something like the web application firewall.

Next we've got a 429 error code and this is an indication that throttling is occurring I mentioned earlier that API gateway can be configured to throttle requests so if you're getting a 429 error it means that you've exceeded a configured throttling amounts so 429 associate that with throttling now if you get a 502 error this is a bad gateway exception and this indicates that a bad output has been returned by whatever is providing the backing services so if you've got a lambda function servicing request your API then a 502 error suggests that that lambda is returning something that's invalid a 503 error indicates service unavailable so this could indicate that the backing endpoint is offline or you're having some form of major service issues so 503 is definitely one to remember I have seen that come up in the exam 504 indicates an integration failure now there is a limit of 29 seconds for any requests to API gateway so even though lambda has a timeout of 15 minutes if lambda is providing backing compute for an API gateway API then if that request takes longer than 29 seconds then this can generate a 504 error so you need to make sure that any lambda functions that are backing your APIs are capable of responding within that 29 second limit otherwise you might get 504 errors and I've included a link that's attached to this lesson which details all of the error codes as well as a little bit more detail if you do want to use it for extra reading now one final thing before we finish up with this in-depth lesson for API gateway and that's to talk about caching now you should be familiar with the general concept of caching at this point in the course as it relates to API gateway we start in the middle with an API gateway stage and this is important because caching is configured per stage this matters both for the exam and if you're developing this infrastructure for production situations now what happens with out a cache is that any users at the application make requests to the API gateway stage and there are some back-end integrations which service those requests without a cache those services would be used on each and every request with caching though you define a cache on that stage it can be anywhere from 500 mb to 237 gb in size it caches things by default for 300 seconds and this can be configured from zero meaning disabled through to a maximum of 3600 seconds and a point that you should know for the exam is that this cache can be encrypted now using a cache means that calls will only be made to the back end when there's a cache miss and this means reduced load reduced cost and improved performance because of the lower latency that caching provides okay so that's everything I wanted to cover in this in-depth lesson on API gateway this is definitely a service where you need to be aware of much more in the developer and operation streams of aws certifications at this point though that is everything that I'm going to be talking about so go ahead complete this lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I'm going to be covering AWS step functions.

To understand why step functions exist we need to look at some of the problems with Lambda that it addresses.

Step functions address some of the limitations of Lambda or not so much limitations but design decisions that have been made with the Lambda product.

No product is perfect and it's important to understand the product limitations or the design decisions which have been implemented as a product has been created.

Now you know by now that Lambda is a function as a service product and the best practice is to create functions which are small, focused and do one thing very well.

What you should never be doing with Lambda is trying to put a full application inside a Lambda function.

A because it's bad practice and B because there's an execution duration limit of 15 minutes.

A Lambda function cannot run past this 15 minute limit for its execution duration.

Now you can in theory chain Lambda functions together so one Lambda function reaches its end and it directly invokes another.

And by doing this in theory you can get another 15 minutes but this gets messy at scale.

What you're doing is building a chain of functions in an attempt to create a long running flow and this isn't what Lambda's designed for.

It's made worse due to the fact that Lambda runtime environments are stateless.

Each environment is isolated, cleaned each time and any data needs to be transferred between the environments if you want to maintain any form of state which is why you can't hold a state through different Lambda functions or different Lambda function invocations.

Imagine an example where you might have an order processing system.

You can upload a picture of your pet, maybe a cat or a dog or a lizard and have it printed on different types of material, maybe glass, metal or high quality paper.

This process can take more than 15 minutes and it will involve lots of decision points, potentially manual human intervention.

There's a state, the order, the process, it's all data that needs to persist and doing it by chaining together lots of Lambda functions is really, really messy.

Step functions as a service lets you create what are known as state machines.

Think of a state machine as a workflow.

It has a start point and it has an end point and in between there are states.

States you can think of as things which occur inside the state machine.

States can do things, they can decide things and they all take in data, modify data and output data.

So states are the things inside these workflows.

Conceptually the state machine is designed to perform an activity or perform a flow which consists of lots of individual components and maintain the idea of data between those states.

Imagine that you're ordering something from an online retailer such as Amazon.com so you complete the purchase and behind the scenes between you completing the purchase and you receiving your goods, lots of things happen behind the scenes.

So your stock is located, it's physically picked, it's packed and verified, postage is booked and when it's dispatched your order is flagged as being dispatched and that's an example of a long running order flow.

With Amazon it might only take a few hours to move through this flow from beginning to end.

With something more bespoke it could take longer and that's why the maximum duration for state machine executions within step functions is one year.

Now there are actually two types of workflows available within step functions.

We've got standard and express.

When you create a state machine you need to choose between the two and it influences some of the features so the speed and the maximum duration.

For the exam you only need to remember that at a high level standard is the default and it has a one year execution limit.

Express that's designed for high volume event processing workloads such as IOT, streaming data processing and transformation, mobile application back ends or any of those type of workloads and these can run for up to five minutes so you would use standard for anything that's long running and express for things that are highly transactional and need much more in terms of processing guarantees.

Now state machines can be started in lots of different ways.

A few examples are using the API gateway, IOT rules, you might use a vent bridge if you're wanting to use event driven architectures, Lambda can initiate state machines and you can even do it manually.

Now generally state machines are used for back end processing so something in your application will initiate a state machine execution.

With state machines you can use a template to create an export state machines once they're configured to your liking.

It's called Amazon States Language or ASL and it's based on JSON and you'll use this yourself during the demo lesson which is coming up later in this section.

Now state machines like any other AWS services they're provided with permissions to interact with other AWS services by using IAM roles.

The state machine assumes the role while running and it gets credentials to interact with any AWS services that it needs to.

Now before we look at the state machine architecture visually I want to focus on states themselves.

I want you to understand the type of states that exist so let's look at that next.

As a reminder states are the things inside a workflow, the things which occur so let's step through what states we have available.

First we've got the succeed and fail states and basically if the process through a state machine ever reaches one of these states then it succeeds or it fails depending on which of these states it arrives at.

That's nice and easy.

Next we've got the wait state and the wait state will wait for a certain period of time or it will wait until a specific date and time.

It's provided with this information as an input and it holds or pauses the processing of the state machine workflow until the duration is passed or until that specific point in time.

Next we've got choice and choice is a state which allows the state machine to take a different path depending on an input and it's useful if you want a different set of behavior based on that input.

For example you might want a state machine to react differently depending on the stock levels of an item in an order.

So the choice state allows you to have a choice inside a state machine and you'll be using the choice state as part of the demo later in this section.

Next we've got the parallel state and the parallel state allows you to create parallel branches within a state machine.

So you might want to take a certain set of actions depending on an input and that might use the choice state but one of those choices might be to perform multiple sets of things at the same time.

So you might have one of the choices of a choice state leading to the parallel state and that's exactly what you're going to implement in the demo lesson at the end of this section.

Next we've got the map state and a map state accepts a list of things.

An example might be a list of orders and for each item in that list the map state performs an action or a set of actions based on that particular item.

So if you have 10 items being ordered inside an order you might have a map state that performs a certain set of things 10 times one for each of those items on that order.

Now these are all examples of states but they are states which control the flow of things through a state machine.

The last type of state that I want to talk about is a task state and a task state represents a single unit of work performed by a state machine.

So it's the task state themselves that allow you to perform actions.

It allows the state machine to actually do things.

So a task states can be integrated with lots of different services.

So things like Lambda, AWS Batch, DynamoDB, the Elastic Container Service, SNS, SQS, Glue, SageMaker, EMR and lots of different AWS services.

And when you configure this integration that's how a state machine can actually perform work.

So what it does to do the work itself, the architecture of a state machine is that it coordinates the work occurring.

So a state machine has different states that control flow through that state machine and then it has task states which coordinate with other external services to perform that actual work.

Now let's look at how all of this fits together visually because it will make a lot more sense.

Now for this example we're going to use the scenario that we're going to look at in the demo lesson at the end of this section.

The scenario that we have is a serious one.

Bob has a cat called Whiskers who can never get enough cuddles.

It's become so bad that poor Whiskers has had to design a step functions powered serverless application to remind his human minion Bob every time a cuddle is required.

Whiskers wants to be in full control of the frequency of the cuddles and there are times when Whiskers might need a cuddle within a few minutes but sometimes it could be more than 15 minutes or even hours away.

He wants to be able to notify his human minion when the next cuddle is needed however far away he is and so there needs to be multiple ways of reminding Bob.

Bob isn't always around and so the reminder method needs to be flexible.

We need email reminders so that if Bob is at a computer he can receive the reminder and we also need an SMS reminder so if Bob isn't at home he can immediately rush home to cuddle Whiskers.

Now because Whiskers is a cat and because he's fussy the time between cuddles could be longer than 15 minutes so we can't use lambda so we're going to use step functions.

Step functions work with a base entity called a state machine and the pet cuddle atron will use one state machine.

Inside the state machine are a number of states.

First we've got a wait state called timer and timer waits for a predefined amount of time.

The time period that you set until the next cuddle is required.

Then we have a choice state and the state machine is pretty flexible.

It allows you to decide on three methods of notification.

Email only notification, SMS only notification or both.

The choice state has three paths that it can direct progress down depending on which option is chosen.

The choices are three task states.

We've got email only, we have SMS only and we've got email and SMS and there are two lambda functions.

Email reminder and SMS reminder.

Depending on the choice taken one or both of these lambda functions are invoked as part of the state machine execution.

If the email only choice is taken then logically this only invokes the email reminder lambda and this uses the simple email service to send an email to Bob demanding a cuddle.

If the SMS only choice is taken then this performs the same action but for SMS only so Bob will receive a text message with whiskers cuddle based demands.

If the email and SMS choice is taken then this performs both actions.

It invokes both lambda functions so Bob receives both an email and an SMS reminder.

Now the back end of this application is provided by the step function service in the form of a state machine but the whole application end to end is actually implemented as a serverless application.

So Bob has a laptop and it downloads the client side web application from an S3 bucket.

So inside this S3 bucket we have HTML and JavaScript and the JavaScript lets Bob's browser connect to a managed API hosted by the API gateway.

The API gateway is what Bob's browser communicates with and this is backed up by a lambda function.

And the lambda function is the thing that behind the scenes provides the compute service necessary to interact with the JavaScript running on Bob's laptop.

And the combination of both of these allows Bob's laptop to initiate the execution of the state machine every time he sets a cuddle reminder.

So the state machine is actually invoked by Bob clicking on a button on a web page that's provided by this serverless application.

Now you'll see this when you open the pet cuddle atron application it will just be a HTML page that's loaded from an S3 bucket but it will ask you for a number of pieces of input.

You'll get asked for the number of seconds until the next cuddle as well as a custom message.

And depending on the notification method that you pick you'll need to enter either an email address or a phone number or both.

And when you've entered all of the required information based on which method of notification that you'll select you'll click on one of three buttons.

One for email only one for SMS only and one for both and clicking on that button generates an event.

This communicates with the API gateway.

It causes an invocation of the API Lambda function and the API Lambda function passes all of the information entered on this serverless web app all the way through to the state machine.

And the state machine begins its execution based on the options that you've selected it waits for a certain period of time and then it makes a choice based on your selected notification method.

And then it invokes one or both Lambda functions that will either send you an email and SMS or both.

And this is the application that you're going to implement in the pet cuddle atron demo lesson in this section of the course.

Now if this looks complicated don't worry because we'll be implementing this piece by piece bit by bit together.

I'll be around every step of the way to guide you on exactly how to implement this fairly complex architecture inside AWS.

I promise you by the end of the demo lesson it will make complete sense in summary step functions let you create state machines and state machines are long running serverless workflows.

They have a start and an end and in between they have states and states can be directional decision points or they can be tasks which actually perform things on behalf of the state machine.

And by using them you can build complex workflows which integrates with lots of different AWS services.

But at this point that's it for the theory so go ahead and complete this lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this video, I want to briefly talk about Amazon AppFlow at a high level.

So in this video, I'll be covering the basics.

If you need any other knowledge for the course that you're studying, then there will be additional videos.

If you only see this one, don't worry, it's everything that you'll need to know.

Now let's jump in and get started.

AppFlow is an interesting service in that if you worked in this space and had this specific problem, you'll immediately see the value that the product provides.

If not, you might not get the point.

AppFlow is a fully managed integration service.

Think of it like middleware.

It allows you to exchange data between applications using flows.

So applications are connected to using connectors and the main unit of configuration of the product is a flow.

Now a flow consists of a source connector and a destination connector and other optional components.

But at a high level, it's the job of the product to exchange data.

Now examples of this might be to sync data across applications or aggregate data from different sources together to avoid data silos within your organization.

By default, the service uses public endpoints which allows it to interact with public SaaS applications, but it can work using private link to access private sources.

Now it comes with functionality for connecting to many of the most popular applications by default, but you can use the custom connector SDK to build your own.

Now some examples where you might use the product are to sync contact records from Salesforce to Redshift for analysis, or to copy your support tickets from something like Zendesk into S3 for storage or analysis.

AppFlow is one of those services which can do a lot.

If you have a need for this type of functionality, you will immediately understand how awesome it is.

Now visually, this is how the architecture might look.

We start with a flow and into this, we configure source and destination connections.

In this case, Slack and Redshift.

Now connections store the configuration and credentials to access an application.

And it's important to understand that they're defined separately from flows so they can be reused across many different flows.

Now it's using connections with this example that the product knows how to connect to Slack and to Redshift and what authentication details to use for both of these applications.

Now next within the flow, we define source and destination field mappings as well as any optional data transformation configuration.

This is what in this example tells AppFlow what fields were interested in from Slack and where to write them in Redshift.

We're also able to define optional filtering and validation within the flow to control what data we want to copy and what if any checks should be performed en route.

And that at a high level is AppFlow.

It's designed to enable you to exchange data between applications in a managed way.

A basic architectural understanding is enough knowledge for most of the AWS exams.

And if you need to know more, I'll include additional videos.

If you only see this one, this is everything that you need to know.

And at this point, that's everything I'm going 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 back and in this lesson I want to cover the serverless architecture.

Serverless is a type of architecture which is relatively commonplace within AWS, mainly because AWS includes many products and services which support its use.

The key thing to understand about the serverless architecture, aside from the fact that there are really servers running behind the scenes, is that it's not one single thing.

Serverless is an architecture, but it's more a software architecture than a hardware architecture.

The aim with the serverless architecture and where its name comes from is that as a developer or an architect or an administrator, you're aiming to manage few, if any, servers.

Servers are things which carry overhead, so cost, administration and risk, and the serverless architecture aims to remove as much of that as possible.

In many ways, serverless takes the best bits from a few different architectures, mostly microservices and event-driven architectures.

Within serverless you break an application down into as many tiny pieces as possible, even beyond microservices, collections of small and specialized functions.

These functions start up, do one thing really, really well, and then they stop.

In AWS, logically, because of this, Lambda is used.

But there are other platforms such as Microsoft Azure, which has their own equivalent, namely Azure Functions.

From an architecture perspective, the actual technology which is used is less relevant.

These functions which make up your application, they run in stateless and ephemeral environments.

Why this matters is because if the application is architected to assume a clean and empty environment, then these functions can run anywhere.

Every time they run, they obtain the data that they need, they do something, and then optionally, they store the result persistently somehow, or they deliver that output to something else.

The reason why Lambda is cheap is because it's scalable.

Each environment is easy to provision, and each environment is the same.

So the serverless architecture uses this to its advantage.

Each function that runs does so in an ephemeral and stateless environment.

And another key concept within serverless is that generally everything is event-driven.

This means that nothing is running until it's required.

Any function code that your application uses is only running on hardware when it's processing a system or customer interaction, an event.

Serverless environments should use fast products such as Lambda for any general processing needs.

Lambda as a service is built based on execution duration, and functions only run when some form of execution is happening.

Because serverless is event-driven, it means that while not being used, a serverless architecture should be very close to zero cost until something in that environment generates an event.

So serverless environments generally have no persistent usage of compute within that system.

Now, where you need other systems beyond normal compute, a serverless environment should use where possible managed services.

It shouldn't reinvent the wheel.

Examples are using S3 for any persistent object storage, or DynamoDB, which we haven't covered yet for any persistent data storage, and third-party identity providers such as Google, Twitter, Facebook, or even corporate identities such as Active Directory instead of building your own.

Other services that AWS provides, such as Elastic Transcode, can be used to convert media files or manipulate these files in other ways.

With the serverless architecture, your aim should be to consume as a service whatever you can, code as little as possible, and use function as a service for any general-purpose compute needs, and then use all of those building blocks together to create your application.

Now, let's look at this visually, because I think an architecture diagram might make it easier to understand exactly what a serverless architecture looks like.

So let's step through a simple serverless architecture, and we're going to do so visually.

And I want your default position to be that unless we state otherwise, you're not using any self-managed compute, so no servers and no EC2 instances, unless we discuss otherwise.

So that should be your starting position.

And at each step throughout this architecture, I'll highlight exactly why the parts are serverless and why it matters.

Now, we're going to use a slightly more inclusive example.

This time, we're going to use PetTube.

There was an uproar about PetTube only being for cats, and so it's rebranded to be a little bit more inclusive.

So to start with, we've got Julie using her laptop, and she wants to upload some woofy holiday videos.

And so to do that, she browsers to an S3 bucket that's running as a static website for the PetTube application.

She downloads some HTML, and that HTML has some JavaScript included within it.

Now, one crucial part of the serverless architecture is that modern web browsers are capable of running client-side JavaScript inside the browser.

And this is what actually provides the front end for the PetTube application, JavaScript that's running in the browser of the user that's downloaded from a static website S3 bucket.

So at this point, the application has no self-managed compute that's being used.

We've simply downloaded HTML from an S3 bucket with some included JavaScript that's now running in Julie's web browser.

Now PetTube uses third-party identity providers for its authentication.

Like all good serverless applications, it doesn't use its own store of identity, its own store of users.

It's lower admin overhead, and also remember there's a limit on the number of IAM users that can exist inside one AWS account.

That's 5,000 IAM users per account.

And so if we used IAM users for authentication, then PetTube would be limited to 5,000 users, and each user of the application would need one additional account.

So one additional username and one additional password.

So instead of doing that, we use a third-party identity provider and one that our users are already likely to have an account inside.

So that reduces the number of accounts that our users are required to maintain.

So the JavaScript that's running in Julie's browser communicates with the third-party identity provider, and we're going to assume that we're using Google.

And you'll have seen the screen that's generated if you've ever logged into Gmail or anything that uses Gmail logins, but this could just as easily be Twitter, Facebook, or any other third-party identity provider.

The key thing to understand is that Julie logs into this identity provider.

It's this identity provider that validates that the user claiming to be Julie is in fact Julie, so it checks her username and password.

And if it's happy with the process or if it's happy with the username and password combination that Julie's provided, then it returns to Julie an identity token.

And this token proves that she's authenticated with the Google identity provider.

Now, AWS can't directly use third-party identities, and so the JavaScript that's running in Julie's browser communicates with an AWS service called Cognito.

And Cognito swaps this Google identity token for temporary AWS credentials, and these can be used to access AWS resources.

So the JavaScript in Julie's browser now has available some temporary AWS credentials that it can use to interact with AWS.

And so it uses these temporary credentials to upload a video of Woofy to an S3 bucket.

This is the original bucket of our application, the bucket where the master videos go that our customers upload.

Notice that so far in this process, no self-managed compute, no servers have been used to provision this service.

We've performed all of these activities without using any compute servers or compute instances that we need to manage or design as solutions architects.

It's all delivered by using managed services, so S3, Cognito, and the Google identity provider.

Now, when the Woofy video arrives inside the original's bucket, that bucket is configured to generate an event.

That event contains the details of the object which was uploaded, and it's set to send that event to and invoke a Lambda function to process that video.

That Lambda function takes in the event and it creates jobs within the elastic transcoder service, which is a managed service offered by AWS which can take in media and manipulate that media.

One of the things that it can do is to transcode the media, so generate media of different sizes from one master video file.

Multiple jobs get created, one for each size of video that's required.

The elastic transcoder gets the location of the original video as part of the initiation of the job and it loads in that video at the start of each job processing cycle.

So each job outputs an object to a transcoder bucket, so one object for each different size of the original video.

In addition, details on each of the new videos are added to a database, in this case DynamoDB.

Now again at this stage, notice that we still have no self-managed servers.

The only resources that are consumed are storage space in S3, DynamoDB, and any processing time used for the Lambda function and any elastic transcoder jobs.

With this architecture so far, we've allowed a customer to upload a master video, we've transcoded it into different video sizes, and at no point have we consumed any self-managed compute, no EC2 instances or no other long-running compute services.

It's all managed services or compute that's used in Julie's browser.

Now the last part of the architecture is where Julie, by clicking another part of the client site that's running inside her browser, can interact with another Lambda function, and we'll call this My Media, and this Lambda function will load data from the database, identify which objects in the transcode bucket are Julie's, and return URLs for Julie to access.

And this is how Julie can load up a web page which show all of the videos that she's uploaded to the PetTube application.

Now this is a simplified diagram, in reality it's a little bit more complex.

For example, API Gateway would generally be used between any client-side processing and the Lambda functions, but conceptually this is actually how it works.

We've got no self-managed servers, we've got no self-managed database servers, we've got little, if any, costs that are incurred for base usage.

It's a fully consumption-based model.

It consumes compute only when it's being used, so when events are generated, either from a system-side or a client-side, and it uses third-party services as much as possible.

Now there are many third-party services to choose from, and you can never expect to know them all end-to-end.

The key thing to understand about serverless is the way to do things, and I've covered that in this lesson.

Later in the section you'll experience how to implement a serverless application within the demo lesson called PetCuddleatron.

And this will show you how to implement a serverless application just like the one that's on screen.

It's slightly less complex, but it's one that uses many of the same architectural fundamentals, and it should start to really cement the theory that you're learning right now.

Now before we move on to this demo, there are a few more services that I need to cover, which the PetCuddleatron demo lesson will utilize.

So for now, that's it for this lesson.

Thanks for watching.

Go ahead and complete this video, and then when you're ready, I'll look forward to you joining me in the next.

Welcome back.

In this lesson, I want to cover CloudWatch events.

We've covered CloudWatch earlier in the course, which focused on metrics and monitoring.

We've also covered CloudWatch logs, which focused on the ingestion and management of logging data.

CloudWatch events delivers a near real-time stream of system events.

These events describe changes in AWS products and services.

When an instance is terminated, started or stopped, these generate an event.

When any AWS products and services which are supported by CloudWatch events perform actions, they generate events that the product has visibility of.

Events Bridge is the service which is replacing CloudWatch events.

It can perform all of the same bits of functionality that CloudWatch events can produce.

It's got a superset of its functionality.

In addition, Events Bridge can also handle events from third parties as well as custom applications.

They do both share the same basic underlying architecture, but AWS are now starting to encourage a migration from CloudWatch events over to Events Bridge.

We've got a lot of architecture to cover, so let's jump in and get started.

Both Events Bridge and CloudWatch events perform at a high level the same basic task.

They allow you to implement an architecture which can observe if X happens or if something happens at a certain time, so Y, then do Z.

X is a supported service which generates an event, so it's a producer of an event.

Y can be a certain time or time period, and this is specified using the Unix Cron format, which is a flexible format letting you specify one or more times when something should occur, and Z is a supported target service to deliver the event to.

Events Bridge is basically CloudWatch events version two.

It uses the same underlying APIs, and it has the same basic architecture, but AWS recommend that for any new deployments, you should use Events Bridge because it has a superset of the features offered by CloudWatch events.

Things created in one are visible in the other for now, but this could change in the future.

So as a general best practice, you should start using Events Bridge by default for any of the functions that you can use CloudWatch events for.

Now, both of these services actually operate using a default entity, which is known as an event bus, and both of them actually have a default event bus for a single AWS account.

A bus in this context is a stream of events which occur from any supported service inside that AWS account.

Now, in CloudWatch events, there is only one event bus available, so it's implicit.

It's not really exposed to the UI.

It just exists.

You interact with it, but because there's only one of them, it's not actually exposed as a visible thing.

You just look for events and then send these events to targets when you want something to occur.

So in CloudWatch events, there is only one event bus, and it's not exposed inside the UI.

In Event Bridge, you can create additional buses, either for your applications or third-party products and services, and you can interact with these buses in the same way as the account default event bus.

Now, with CloudWatch events and Event Bridge, you create rules, and these rules pattern match events which occur on the buses, and when they see an event which matches, they deliver that event to a target.

Alternatively, you also have schedule-based rules which are essentially pattern-matching rules but which match a certain date and time or ranges of dates and times.

So if you're familiar with the Unix Cron system, this is similar.

For a schedule rule, you define a Cron expression, and the rule executes whenever this matches and delivers this to a particular target.

So the rule matches an event, and it routes that event to one or more targets which you define on that rule.

And an example of one target is to invoke a specific Lambda function.

Now, architecturally, at the heart of Event Bridge is the default account event bus, which is a stream of events which are generated by supported services within the AWS account.

Now, EC2 is an example of a supported service, and let's say in this case, we've got Bob changing the state of an EC2 instance, and he's changing the state from stopped to running.

When the instance changes state, an event gets generated which runs through the event bus.

Event Bridge, which sits over the top of any event buses that it has exposure to, monitors all of the events which pass through this event bus.

Now, within Event Bridge or CloudWatch events, which I'm going to start calling just Event Bridge from now on because it makes it easier, but within Event Bridge, we have rules.

Now, rules are created, and these are linked to a specific event bus, and the default is the account default event bus.

The two types of rules are pattern matching rules, and these match particular patterns of the events themselves as they pass through the event bus.

We've also got scheduled rules which match particular cron-formatted times or ranges of times, and when this cron-formatted expression matches a particular time, the rule is executed, and in both of these cases, when a rule is executed, the rule delivers the particular event that it's matched through to one or more targets.

And of course, as I just mentioned, examples of these targets could be to invoke a lambda function.

Now, events themselves are just JSON structures, and the data in the event structure can be used by the targets.

So in the example of a state change of an EC2 instance, the lambda function will receive the event JSON data, which includes which instance has changed state, what state it's changed into, as well as other things like the date and time when the change occurred.

So that's a theory of both CloudWatch events and the event bridge, and both of these products are used as a central point for managing events generated inside an AWS account and controlling what to do with those events.

So at this point, that is everything that I wanted to cover.

Go ahead and complete this lesson, and then when you're ready, I look forward to you joining me in the next.

Welcome back and in part three of this series, I want to finish off and talk about some advanced elements of Lambda.

Now we've got a lot to cover, so let's jump in and get started.

First, I want to talk about the ways a Lambda function can be invoked.

We've got three different methods for invoking a Lambda function.

We've got synchronous invocation, asynchronous invocation, and invocation using event source mappings.

And I want to step through each of them visually so that you can understand in detail how they work because this is essential for the exam.

So let's start off with synchronous invocation of Lambda.

With this model, you might start off with a command line or API directly invoking a Lambda function.

The Lambda function is provided with some data and it executes that data.

Now all this time, the command line or API is waiting for a response because it's synchronous.

It needs to wait here until the Lambda function completes its execution.

So the Lambda function finishes and it returns that data, whether it's a success or a failure.

Now synchronous invocation also happens if Lambda is used indirectly via the API gateway, which is the use case for many serverless architectures.

So we might have some clients using a web application via API gateway and this proxies through to one or more Lambda functions.

Again, the Lambda function performs some processing all the while the client is waiting for a response within their web application.

And then when the Lambda function responds, this goes back via the API gateway and back through to the client.

The common factors with both of these approaches is that the client sends a request which invokes Lambda and the result be it a success or failure is returned during that initial request.

The client is waiting for any data to be returned.

Another implication of a synchronous invocation is that any errors or retries have to be handled within the client.

The Lambda function runs once, it returns something and then it stops.

If there's a problem or data isn't processed correctly, then the client needs to rerun that request.

And this happens at the client side.

So synchronous invocation is generally used when it's a human directly or indirectly invoking a Lambda function.

Next, let's look at asynchronous invocation.

And this is typically used when AWS services invoke Lambda functions on your behalf.

Let's use an example, an S3 bucket with S3 events enabled.

So we upload a new image of whiskers to this S3 bucket.

This causes an event to be generated and sent through to Lambda.

And this is an asynchronous invocation.

So S3 isn't waiting around for any kind of response.

It basically just forgets about it at this point.

Once it sent that event through to Lambda, it doesn't continue waiting.

It doesn't worry about this event at all.

Now maybe as part of processing this image, it's generating a thumbnail or maybe performing some kind of analysis and storing that data into DynamoDB.

But again, S3 isn't waiting around for any of this.

It's asynchronous.

Lambda is responsible for any reprocessing in the event that there's a failure.

And this reprocessing value is configurable between zero and two times.

Now a key requirement for this is that the function code needs to be idempotent.

And this is important.

If you've never heard this term before, let me explain.

Let's say that you had $10 in your bank account and I wanted to increase this value to $20.

Now there are two ways that I could do this if I operated the bank.

I could simply add $10 to your balance, increasing it from 10 to 20, or I could explicitly set the balance to 20.

Now if I set the balance to 20 and this operation failed at some undetermined point in this process, then I could simply rerun the process, safe in the knowledge that even running it again on your balance would only at worst set the value to $20 again.

This is known as an idempotent operation.

You can run it as many times as you want and the outcome will be the same.

Now if I performed the operation where I added $10 to your account and the operation failed, it could have failed before it added the $10 or after.

If it failed after and I rerun the operation, well now you'd have $30 and this is an example of something which is not idempotent.

When Lambda retries an operation it doesn't really provide any other information.

The function just reruns.

So logically in this example you would need to make sure that your function code isn't additive or subtractive.

It just needs to perform its intended task.

With this example it needs to set your balance to $20.

Generally when designing a Lambda function which is used in this way, the Lambda function needs to finish with a desired state.

It needs to make something true.

If you're using Lambda functions which are designed in a non-idempotent way, you can end up with some questionable results.

Now Lambda can be configured to send any events which it can't process after those automatic retries to a dead letter queue which can be used for diagnostic processing.

And a new feature of Lambda is the ability to create destinations.

So events processed by Lambda functions can be delivered to another destination such as SQS, SNS, another Lambda function and even EventBridge.

And separate destinations can be configured based on successful processing or failures.

So this is asynchronous invocation.

It's generally used by AWS services which are capable of generating events and sending those events to Lambda.

It means that Lambda can automatically reprocess failed events and the original source of the event isn't waiting for processing to complete.

But there is a third type of invocation.

The last type of invocation is known as Event Source Mapping.

And this is typically used on streams or queues which don't generate events.

So things where some kind of polling is required.

Let's look at an example.

Let's say that we have a Kinesis data stream and into this stream, a fleet of producer vans driving around scanning with LIDAR and imaging equipment are all producing data which is being put into a Kinesis stream.

Now Kinesis is a stream based product.

Generally consumers can read from a stream but it doesn't generate events when data is added.

So historically this wouldn't have been an ideal fit for Lambda which is an event driven service.

So what happens is that we have a hidden component called an event source mapping which is polling queues or streams looking for new data and getting back source batches.

So batches of source data from this data source.

Now these source batches are then broken up as required based on a batch size and sent into a Lambda function as event batches.

Now a single Lambda function invocation could in theory receive hundreds of events in a batch.

It depends on how long each event takes to process.

Remember Lambda has a 15 minute timeout so you need to carefully control this event batch size to ensure that the Lambda function doesn't terminate before completing this batch.

Now there's one really important thing that you need to understand about event source mapping.

With a synchronous invocation an event is delivered to Lambda from the source and Lambda doesn't need permissions to the source service unless it actually wants to read more data from that source.

For example, if an object is added to an S3 bucket then S3 generates and delivers an event which contains details of that event.

So which object was uploaded and perhaps some other metadata.

But unless you need to read additional data from S3 maybe to get the actual object well then the Lambda function doesn't need S3 permissions.

With event source mapping invocation the source service isn't delivering an event.

The event source mapping is reading from that source.

And so the event source mapping uses permissions from the Lambda execution role to access the source service.

And this is really important to know because it does come up in the exam.

So even if a Lambda function receives an event batch containing Kinesis data even though the Lambda function doesn't directly read from Kinesis the execution role needs Kinesis permissions because the event source mapping uses them on its behalf to retrieve that data.

Now any batches which consistently fail can be sent to an SQS queue or an SNS topic for further processing or analysis.

Now that's the third type of invocation.

This is event source mapping invocation.

And that's the method used when Lambda functions are processing SQS queues, Kinesis streams, DynamoDB streams and even Amazon managed streaming for Apache Kafka.

And this last one is something that we won't be covering within the course.

But it's important to know all of the different types of products that use event source mapping based invocation.

With that being said that's all of the three types of invocation I wanted to cover.

So let's move on to a different topic.

This time Lambda versions.

With Lambda functions it's possible to define specific versions of Lambda functions.

So you could have different versions of the given function for example, version one, version two and version three.

Now as it relates to Lambda, a version of a function is actually the code plus the configuration of that Lambda function.

So the resources and any environment variables in addition to any other configuration information.

Now when you publish a version, that version is immutable.

It never changes once it's published.

And it even has its own Amazon resource name.

So once you publish a version you can no longer change that version.

There's also the concept of dollar latest and dollar latest points at the latest version of a Lambda function.

Now this can obviously change as you publish later and later versions of the function.

So this is not immutable.

You can also create aliases.

So for example, dev stage and prod.

And these can point at a particular version of a Lambda function.

And these can be changed.

So these aliases are not immutable.

So generally with large scale deployments of Lambda you'd be producing Lambda function versions for all of the major changes.

And using aliases so that different components of your serverless application can point at those specific immutable version numbers.

So that's important to know for the exam.

So the last thing I want to talk about is Lambda startup times.

And to understand that you need to understand how Lambda functions are actually executed.

Lambda code runs inside a runtime environment.

And this is also referred to as an execution context.

Think of this as a small container which is allocated an amount of resource which runs your Lambda code.

When a Lambda function is first invoked, let's say by receiving an S3 event, this execution context needs to be created and configured.

And this takes time.

First the environment itself is created and this requires physical hardware.

Then any run times which are required are downloaded and installed.

Let's say this is for Python 3.8.

Then the deployment package is downloaded and then installed and this takes time.

Now this process is known as a cold start.

And all in this process can take hundreds of milliseconds or more, which can be significant if a Lambda function is performing a task which touches a human who is expecting a response.

Now if this is an S3 event, then maybe this extra time isn't such a big deal.

But you need to be aware that this cold start occurs because an execution context is being created and configured.

Any prerequisites are being downloaded and installed.

The deployment package is being downloaded and installed.

And that's all before the function itself can execute.

Now if the same Lambda function is invoked again without too much of a gap, then it's possible that Lambda will use the same execution context.

And this is known as a warm start.

It doesn't need to set up the environment or download the deployment package because all of that is already contained within the execution context.

This time the context just receives the event and immediately begins processing.

A warm start means the code can be running within milliseconds because there's no lengthy build process.

A Lambda function which invokes again fairly soon after a cold start can reuse an execution context.

But if too long a time period goes between invocations, then the context can be deleted which results in another cold start.

Also one function invocation runs at a time per context.

So if you need 20 invocations of a function at once, then this can result in 20 cold starts.

Now you can make this process more efficient.

You can actually use a feature known as provisioned concurrency where you can inform AWS in advance.

An execution context can be provisioned for you in advance for Lambda invocations.

You might use these when you know that you have periods of high load on a serverless application or if you're preparing for a new production release of a serverless application and want to pre-create all of these execution environments.

Now there are also other things that you can do to improve performance.

You can use the temp space to pre-download things within an execution context.

For example, maybe you're using some animal images as part of your processing.

Well, if another function uses the same execution context, then it too will have access to those same animal images without having to download them a second time.

Now you do need to be careful because your functions need to be able to cope with the environment being new and clean every time they can never assume the presence of anything.

From a code perspective, you can create other things like database connections outside of the Lambda function handler code.

So when you create a Lambda function, generally most things go within the Lambda function handler.

But if you create anything outside of the Lambda function handler, then these will be made available for any future function invocations in the same context.

So anything that you define within a Lambda function handler is limited to that one specific invocation of that Lambda function.

But for anything which you anticipate there being a potential for reuse, you can declare that outside of the Lambda function handler.

And in theory, that will be available for any other invocations of the Lambda function which occur within that same execution context.

But again, you need to make sure that your function doesn't require or expect that.

Every single time a function invokes, it should be absolutely fine with recreating everything.

You should by default assume that execution contexts are stateless and any invocation of a Lambda function is going to be operating in a completely freshly created environment.

But if you want to be efficient, your functions should also be able to reuse common aspects that persist through different function invocations.

Now again, these are all deep dive things that you need to be aware of for the exam.

I've covered a lot of these elements across all three parts of this Lambda deep dive mini series.

But at this point, that's everything I wanted to cover in part three.

And this is the last part of this mini series.

So thanks for watching.

Go ahead and complete this video.

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

Welcome back to part two of this lesson series going into a little bit more depth on Lambda.

In this part of the series I'm going to be talking about Lambda networking, Lambda permissions and Lambda monitoring.

Now this is a lot to cover in one lesson so let's jump in and get started.

Lambda has two networking modes and you need to be aware of both of them for the exam.

First we have public which is the default and then second we have VPC networking.

Now you need to understand the architecture of both of them so let's step through them in a little bit more detail.

For public networking we start with an AWS environment and inside it a single Lambda function.

Now this is part of a wider application let's say the Categorum Enterprise application running in a VPC which uses Aurora for the database, EC2 for compute and the Elastic file system for shared file storage.

Now this is the default configuration for Lambda where it's running in the public AWS network so Lambda using this configuration can access public space AWS services such as SQS and DynamoDB or internet-based services such as IMDB if the Lambda function wanted to fetch the latest details of cat themed movies and TV shows.

So Lambda running by default using public networking means that it has network connectivity to public space AWS services and the public internet.

It can connect to both of those from a networking perspective and as long as it has the required methods of authentication and authorization then it can access all of those services.

Now public networking offers the best performance for Lambda because no customer specific networking is required.

Lambda functions can run on shared hardware and networking with nothing specific to one particular customer but this does mean that any Lambda functions running with this default have no access to services running within a VPC unless those services are configured with public addressing as well as security rules to allow external access so this is a big limitation that you need to understand for the exam so the architecture on screen now this Lambda function could not access Aurora EC2 or the Elastic File system unless they had public addressing and the security was configured to allow that access.

So in this example without configuration changes the Lambda function could access public services but would have no access to anything running inside the VPC.

Now in most cases in my experience Lambda is used with this public networking model but there are situations where this isn't enough and for those situations Lambda can be configured to run inside a VPC.

Let's look at how.

This time we have the same architecture so a VPC running within AWS but this time the Lambda function is configured to run inside a private subnet at the bottom.

Now this is the same subnet where the Catergram Enterprise infrastructure is running from and for the exam specifically the key thing to understand about Lambda's running inside a VPC is that they obey all of the same rules as anything else running in a VPC because they're actually running within that VPC.

So to start with this means that Lambda functions running inside a VPC can freely access other VPC based resources assuming any network ACLs and security groups allow that access but the flip side of this means they can't access things outside of the VPC unless networking configuration exists within the VPC to allow this external access.

So by default with this architecture the Lambda function couldn't access DynamoDB or any internet based endpoints such as with this example IMDB.

Now if you face any exam questions or you need to design any solutions which involve Lambda functions running within a VPC then just treat them like anything else running in that VPC.

So this means that you could use a VPC endpoint for example a gateway endpoint to provide access to DynamoDB because the Lambda function is running within the VPC it could utilize a gateway endpoint to access DynamoDB or in the case that the Lambda function needed access to AWS public services or the internet you could deploy a NAT gateway in a public subnet and then attach an internet gateway to the VPC.

Remember Lambda running within a VPC behaves like any other VPC based service the same gateways and configurations are needed to allow VPC based Lambda functions to communicate with the AWS public zone and the public internet.

Now you also need to give your Lambda functions EC2 network permissions via the execution role which I'll cover very soon because the Lambda service needs to create network interfaces within your VPC it requires these permissions and this architecture of using network interfaces within a VPC is what I want to quickly cover now.

Now there used to be disadvantages to running Lambda in a VPC significant disadvantages and the reason was the networking architecture that Lambda used.

VPC based Lambda functions don't actually run within your VPC the way they work is similar to Fargate so we have AWS and there's a Lambda service VPC and a customer VPC.

Now let's keep things simple and say that we only have three Lambda functions.

Now the way that this historically worked is that each of these Lambda functions when invoked would create an elastic network interface within the customer VPC and traffic would flow between this service VPC and the customer VPC.

Now the problem is that configuring these elastic network interfaces on a per function per invocation basis would take time and add delay to the execution of the Lambda function code.

In addition this architecture doesn't scale well because parallel function executions or concurrency required additional elastic network interfaces and the more popular a system became the worse the problem became with larger systems you had more and more performance issues and more and more issues with keeping VPC capacity available for larger and larger numbers of ENIs.

Now luckily this is the old architecture this is the way that Lambda used to handle this private networking it's not how it works anymore.

With the new way instead of requiring an elastic network interface per function execution AWS analyze all of the functions running in a region in an account and build up a set of unique combinations of security groups and subnets.

So for every unique one of those one ENI is required in the VPC.

So if all your functions used a collection of subnets but the same security groups then one network interface would be required per subnet if they all used the same subnet and all used the same security group then all of your Lambda functions could use the single elastic network interface.

So a single connection between the Lambda Service VPC and your VPC is created for every unique combination of security groups and subnets used by your Lambda functions.

Now the network interfaces using this architecture are created when you configure the Lambda function and typically this might take 90 seconds but this is done once so when you create the function or when you update the network and configuration this network and configuration is created or updated and that means that it isn't required every single time a Lambda function is invoked so it doesn't delay your function invocations.

Now this means that you can use private networking at scale without increasing the number of elastic network interfaces required.

So where it used to be a bad idea performance-wise to use VPC-based lambdas this is no longer the case.

So that's networking so this is how you configure Lambda functions if you need them to have access to private VPC services and it's important that you understand both the public and VPC networking model especially for the exam because you will face questions on the exam about executing Lambda functions within a VPC.

Again one really important hint that I will provide is just treat Lambda functions running in a VPC like any other VPC-based resource and by now you should know how to architect a VPC so that services running in that VPC have access to everything that they need so just treat Lambda functions in the same way.

Now let's look at the security of Lambda functions.

When it comes to Lambda permissions there are actually two key parts of the permissions model that you need to understand.

One of them is pretty well known and that's covered at the associate level the other not so much.

Now let's start with a typical Lambda environment this is a runtime environment the thing where your Lambda functions execute within so this is running a runtime in this case Python 3.8 it's allocated some resources and the code loads and runs within this environment.

Now for this environment to access any AWS products and services it needs to be provided with an execution role this is a role which is assumed by Lambda and by doing so the code within the environment gains the permissions of that role based on the role's permissions policy so a role is created which has a trust policy which trusts Lambda and the permissions policy that that role has is used to generate the temporary credentials that the Lambda function uses to interact with other resources so in many ways this is just the same as an EC2 instance role so this governs what permissions the function receives which might be something like loading data from DynamoDB and storing output data into S3.

Now this is the most well known aspect of Lambda permissions but there is another part Lambda actually has resource policies now this in many ways is like a bucket policy on S3 it controls who can interact with a specific Lambda function it's this resource policy which can be used to allow external accounts to invoke a Lambda function or certain services to use a Lambda function such as SNS or S3.

The resource policy is something changed when you integrate other services with Lambda and you can manually change it via the CLI or the API unless something's changed between creating this lesson and when you're watching it it currently can't be changed using the console UI so this is only something which can be manipulated using the CLI or the API so that's how security works within a Lambda function now one more thing that I want to cover before finishing up with part two is logging so Lambda uses cloud watch, cloud watch logs and x-ray for various aspects of its logging and monitoring so any logging information generated from Lambda executions that goes into cloud watch logs so the output of Lambda functions any messages that you output to the log any errors details on the duration of the execution that's all stored into cloud watch logs any metrics so details such as invocation successes or failure numbers any retries anything to do with latency that's all stored in cloud watch so cloud watch is the thing that stores metrics and this is important to understand logging goes into cloud watch logs and any details on the number of indications successes or failures anything around metrics goes straight into cloud watch now lambdas can also be integrated into x-ray which I cover elsewhere in the course and this can be used to add distributed tracing capability so if you need to trace the path of a user or the path of a session through a serverless application which uses Lambda then you can use the x-ray service now I don't expect this to feature heavily on the exam but just remember the terms x-ray and distributed tracing because that might come in handy for one or two exam questions if these topics do crop up now one really important thing to remember for the exam is that for Lambda to be able to log into cloud watch logs to generate the output of any of the executions you need to give Lambda permissions via the execution role so there's actually a pre-built policy and role within aws specifically designed to give Lambda functions the basic permissions that they require to log information into cloud watch logs and one really common exam scenario is where you're trying to diagnose why a Lambda function is not working there's nothing in cloud watch logs and one possible answer is that it doesn't have the required permissions via the execution role now that's everything I wanted to cover in part two of this Lambda in-depth mini series so we've covered networking both public and private we've covered security and we've covered logging so go ahead and complete this lesson and when you're ready I look forward to you joining me in part three.

Welcome back and in this multi-part lesson mini series, I want to talk about AWS Lambda.

Lambda is a function as a service or a fast product.

This means that you provide specialized short running and focused code to Lambda and it takes care of running it and billing you only for what you consume.

So a Lambda function is a piece of code which Lambda runs and every Lambda function is using a supported runtime.

So an example of a supported runtime is Python 3.8.

So when you create a Lambda function, you need to define which runtime that piece of code uses.

Now, when you provide your code to Lambda, it's loaded into and executed within a runtime environment.

And this runtime environment is specifically created to run code using a certain runtime, a certain language.

So when you create a Lambda function that uses the Python 3.8 runtime, then the runtime environment that's created is itself specifically designed to run Python 3.8 code.

Now, when you create a Lambda function, you also define the amount of resource that a runtime environment is provided with.

So you directly allocate a certain amount of memory and based on that amount of memory, a certain amount of virtual CPU is allocated, but this is indirect.

You don't get to choose the amount of CPU.

This is based on the amount of memory.

Now, the key thing to understand about Lambda as a service, because it's a function as a service product, because it's designed for short running and focused functions, you only actually build for the duration that a function runs.

So based on the amount of resource allocated to an environment and based on the duration that that function runs for per invocation, that determines how much you'll build for the Lambda product.

So you'll build for the duration of function executions.

Now, Lambda is a key part of serverless architectures running within AWS.

And over this section of the course, you're going to get some experience of how you can use Lambda to create serverless or event-driven architectures.

Architecturally, the way that Lambda works is this.

You define a Lambda function.

Now, you can think of a Lambda function as a unit of configuration.

Yes, you can also use the term Lambda function to describe the actual code.

But when you think of a Lambda function, think of it as the code plus all the associated wrappings and configuration.

Your Lambda function at its most basic is a deployment package which Lambda executes.

So when you create a Lambda function, you define the language which the function is written in.

You provide Lambda with a deployment package and you set some resources.

And whenever the Lambda function is invoked, what actually happens is the deployment package is downloaded and executed within this runtime environment.

Now, Lambda supports lots of different runtimes.

Some of the common ones are various different versions of Python.

We also have Ruby.

We've got Java.

We've also got Go and there's also C# as well as various versions of Node.js.

Now, you can also create custom ones using Lambda layers.

And many of these are created by the community.

For the exam though, one really important point is that if you see or hear the term Docker, consider this to mean not Lambda.

So Docker is an anti-pattern for Lambda.

Now, Lambda does now support using Docker images, but this is distinct from the word Docker.

If you hear the term Docker in the exam, then it generally will be referring to traditional containerized computing.

So that's using a specific Docker image to spin up a container and use it in a containerized compute environment such as ECS.

Now, you can also use container images with Lambda.

Now, that's a different process.

That means that you're using your existing container build processes, the same ones that you use to create Docker images.

But instead, you're creating specific images designed to run inside the Lambda environment.

So don't confuse Docker container images and Docker with images used for Lambda.

They're two different things.

The only thing that they share is that you can use your existing build processes to build Lambda images.

Now, custom runtimes could allow languages such as Rust, which is a very popular community-based language to work within the product.

So if you search using Google or any other popular search engine, you'll be able to find lots of languages which have been added by the community using the Lambda layer functionality.

And I'll be talking about that elsewhere in the course.

Now, you select the runtime to use when creating the function, and this determines the components which are available inside the runtime environment.

So Python code, for instance, requires Python of a certain version to be installed in addition to various Python modules.

Conceptually, think about it like this.

Every time a Lambda function is invoked, which means to execute that function, a new runtime environment is created with all of the components that that Lambda function needs.

Let's say, for example, a Python 3.8-based Lambda function.

So the code loads, it's executed, and then it terminates.

Next time, a new clean environment is created, it does the same thing, and then it terminates.

Lambda functions are stateless, which means no data is left over from a previous invocation.

Every time a function is invoked, it's a brand new invocation, a brand new environment.

Now, I'm going to be talking about this in part 3 of this series, because this isn't always the case, but you have to assume that it is architecturally.

So your code running within Lambda needs to be able to work 100% of the time if it's a new environment.

Lambda runtime environments have no state.

Now, there are some situations where a function might be invoked multiple times within the same environment.

And I'll be talking about that in part 3 of this series.

But as a base level, a default, assume that every time a Lambda function is invoked, it's inside a brand new runtime environment.

Now, you also define the resources that Lambda functions use, and this determines how much resource the runtime environment gets.

Now, you directly define the memory.

And this is anywhere from 128 MB to 10 to 40 MB in one MB steps.

Now, you don't directly control the amount of virtual CPU.

This scales with the memory.

So 1769 MB of memory gives you one VCPU of allocation, and it's linear.

So the less memory means less virtual CPUs, and more memory means additional VCPU capacity.

The runtime environment also has some disk space allocation.

512 MB is mounted as forward slash TMP within the runtime environment.

This is the default amount, but it can scale to 10,240 MB.

Now, you can use this, but keep in mind, you have to assume that it's blank every single time a Lambda function is invoked.

This should only be viewed as temporary space.

Lambda functions can run for up to 900 seconds or 15 minutes.

And this is known as the function timeout.

This is important because for anything beyond 15 minutes, you can't use Lambda directly.

And that's a really important figure to know for the exam.

You know by now I'm not a fan of people memorizing facts and figures, but this is definitely one that you need to remember for the exam.

So 15 minutes is a critical amount of time for a Lambda function.

You can use other things, such as step functions, to create longer running workflows, but one invocation of one function has a maximum of 15 minutes or 900 seconds.

Now, we're going to be covering security in more detail in part two, as well as networking.

But the security for a Lambda function is controlled using execution roles.

And these are IAM roles, assumed by the Lambda function, which provides permissions to interact with other AWS products and services.

So any permissions which a Lambda function needs to be provided with are delivered by creating an execution role and attaching that to a specific Lambda function.

Now, just a few final things before we finish up some common uses of Lambda.

So Lambda forms a core part of the delivery of serverless applications within AWS.

And generally this uses products such as S3, API gateway, and Lambda.

So these three together are often used to deliver serverless applications.

Lambda can also be used for file processing, using S3, S3 events, and Lambda.

So a very common example that's used in training is watermarking images.

So have images uploaded to S3, generate an S3 event, invoke a Lambda function, which applies a watermark, and then terminates.

And you're only billed for the compute resources used during those Lambda function invocations.

You can also use Lambda for database triggers.

So this is using DynamoDB, as well as DynamoDB streams, and then Lambda.

So Lambda can be invoked any time data is inserted, modified, or deleted from a DynamoDB table with streams enabled.

And this is another powerful architecture.

You can also use Lambda to implement a form of serverless cron.

So you can use EventBridge or CloudWatch events to invoke Lambda functions at certain times of day, or certain days of week, to perform certain scripted activities.

And this is something that traditionally you would need to run on something like an EC2 instance, but using Lambda means that you're only billed for the amount of time that these functions are executing.

So this is another really common use case.

And then finally, you can perform real-time stream data processing.

So Lambda's can be configured to invoke whenever data is added to a Kinesis stream.

And this can be useful because Lambda is really scalable.

And so it can scale with the amount of data being streamed into a Kinesis stream.

And again, this is another really common architecture for any businesses that are streaming large quantities of data into AWS, and they require some form of real-time processing.

Now that's everything that I wanted to cover in part one of this series.

Remember, it's a three-part mini-series, part two and part three, are going to introduce some more advanced concepts.

Specifically, though, is that you'll need for the exam.

But at this point, go ahead, complete this lesson, and then 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 the previous architecture can be evolved by using queues.

A queue is a system which accepts messages.

Messages are sent onto a queue and messages can be received or polled off the queue.

In many queues there's ordering.

So in most cases messages are received off the queue in a 5.0 or first in, first out architecture.

Although it's worth noting that this isn't always the case.

Using a queue based decoupled architecture, CatTube would look something like this.

Bob would upload his newest video of whiskers laying on the beach to the upload component.

And once the upload is complete, instead of passing this directly onto the processing tier, it does something slightly different.

It stores the master 4k video inside an S3 bucket.

And it also adds a message to the queue, detailing where the video is located, as well as any other relevant information such as what sizes are required.

This message, because it's the first message in the queue, is architecturally at the front of the queue.

At this point the upload tier, because it's uploaded the master video to S3 and added a message to the queue, it's finished this particular transaction.

It doesn't talk directly to the processing tier and it doesn't know or care if it's actually functioning.

The key thing is that the upload tier doesn't expect an immediate answer from the processing tier.

The queue has decoupled the upload and processing components.

It's moved from a synchronous style of communication where the upload tier expects and needs an immediate answer and it needs to wait for that answer.

Instead, it uses asynchronous or async communications where the upload tier sends the message and it can either wait in the background or just continue doing other things while the processing tier does its job.

Now while this process is going on, the upload component is probably getting additional videos being uploaded and they're added to the queue along with the whiskers video processing job.

Other messages that are added to the queue are behind the whiskers job, because with this queue there is an order.

It's a 5.0 or first in, first out queue.

Now at the other side of the queue we have an auto scaling group which has been configured.

It has a minimum size of 0, a desired size of 0 and a maximum size of 1,337.

So currently it has no instances provisioned.

But it has auto scaling policies which provision or terminate instances based on what's called the queue length.

And the queue length is just the number of items in the queue.

Because there are messages on the queue added by the upload tier, the auto scaling group detects this and so the desired capacity is increased from 0 to 2.

And because of this, instances are provisioned by the auto scaling group.

And these instances start polling the queue and receive messages that are at the front of the queue.

Remember that these messages contain the data for the job, but they also contain the location of the S3 bucket and the location of the object in that bucket.

So once these jobs are received from the queue by these processing instances, they can also retrieve the master video from the S3 bucket.

Now these jobs are processed by the instances and then they're deleted from the queue and this leaves only one job in the queue.

At this point maybe the auto scaling group decides to scale back because of the shorter queue length.

So it reduces the desired capacity from 2 to 1.

And this process terminates one of the processing instances.

The instance that remains polls the queue and receives the one final message.

It completes processing of that message so it performs the transcoding on the videos and it leaves zero messages in the queue.

The auto scaling group realizes this, it scales back the desired capacity from 1 to 0 and that results in the termination of the last processing EC2 instance.

Using a queue architecture, so placing a queue in between two application tiers decouples those tiers.

One tier adds jobs to the queue and doesn't care about the health or the state of the other and another tier can read jobs from that queue and it doesn't care how they got there.

This is unlike the example on the previous screen where application load balancers were used between tiers.

While this did allow for high availability and scaling, the upload tier in the previous example still synchronously communicated with one instance of the processing tier.

This way using the queue architecture no communication happens directly.

The components are decoupled, the components can scale independently and freely and in this case the processing tier which uses a worker fleet architecture.

It can scale anywhere from zero to a near infinite number of instances based only on the length of the queue.

So the number of messages in the queue.

Now this is a really powerful architecture because of the asynchronous communications that it uses.

And it's an architecture that's commonly used in applications such as CatTube where customers upload things for processing and you want to ensure that you've got a worker fleet behind the scenes that can scale to perform that processing.

Now you might be asking why this matters at least in the topic of event driven architectures and I'm getting there, I promise.

If you continue breaking down a monolithic application into smaller and smaller pieces, you'll end up at a microservice architecture which is a collection of as the name suggests microservices.

And microservices do individual things very well.

In this example we have the upload microservice, the processing microservice and the store and manage microservice.

A full application such as CatTube might have hundreds or even thousands of these microservices.

They might be different services or there might just be lots of copies of the same service such as this example which is lucky because it's far easier to diagram.

The upload service is a producer, the processing node is a consumer and the data, store and manage microservice performs both.

Now logically producers produce data or they produce messages.

Consumers as the name suggests consume data or messages and then you've got microservices that can do both things.

Now the things that services produce and consume architecturally are events.

Cues can be used to communicate events as we saw with the previous example but larger microservices architectures can get complex pretty quickly.

With services needing to exchange data between partner microservices, if we do this with a queue architecture then logically we're going to have a lot of queues.

It works but it can be complicated.

Keep in mind a microservice is just a tiny self-sufficient application.

It has its own logic, its own store of data and its own input/output components.

Now if you hear the term event driven architecture I don't want you to be too apprehensive.

Event driven architectures are just a collection of event producers which might be components of your application which directly interact with customers or they might be parts of your infrastructure such as EC2 or they might be systems monitoring components.

They're bits of software which generate or produce events in reaction to something.

If a customer clicks submit that might be an event.

If an error occurs when packing a customer order or an error occurs during the upload of the whiskers holiday video that's an event.

Producers are things which produce events and the inverse of this are consumers.

Pieces of software which are ready and waiting for events to occur.

If they see an event which they care about they will do something with that event.

They will take an action.

It might be displaying something for a customer.

It might be to dispatch a human to resolve an order packing issue or it might be to retry an upload.

Components or services within an application can be both producers and consumers.

Sometimes a component might generate an event for example a failed upload and then consume events to force a retry of that upload.

Now the key thing to understand about event driven architectures is that neither the producers or the consumers are sat around waiting for things to occur.

They're not constantly consuming resources.

They're not running at 100% CPU load waiting for things to happen.

With producers events are generated when something happens when a button is clicked when an upload works or when it doesn't work.

These producers produce events.

Consumers are not waiting around for those events.

They have those events delivered and when they receive an event they take an action and then they stop.

They're not constantly consuming resources.

Now applications would be really complex if every software component or service needed to be aware of every other component.

If every application component required a queue between it and every other component to put events into and access them from it would be a really complex application architecture.

Best practice event driven architectures have what's called an event router.

A highly available central exchange point for events and the event router has what's known as an event bus and you can think of this like a constant flow of information.

When events are generated by producers they're added to this event bus and the router can deliver these to event consumers.

The WordPress system that we've used to date we've been running it on an EC2 instance and an EC2 instance is essentially a consistent allocation of resources.

Whether that WordPress is using low amounts of load or large amounts of load we're still going to be billed for that EC2 instance.

We're still consuming resources.

I want you to imagine a system with lots of small services all waiting for events.

If events are received the system springs into action it allocates resources and it scales components up as required.

It deals with those events and then it returns to the low or no resource usage which is the default state.

Event driven architectures only consume resources as and when required.

So with an event driven architecture there's generally nothing constantly running nothing waiting for things.

We're not constantly polling hoping for things to happen.

We have producers which generate events when something happens.

If you're browsing the Amazon.com website and you click on order that generates an event and actions are taken based on that event.

But the Amazon.com website is not constantly checking your browser each and every second to check if you've clicked submit on that order.

So producers generate events when something happens so when clicks happen when errors occur when criteria are met when uploads complete or any other actions.

So producers they generate event on things occurring and these events are delivered to consumers of those events and that generally happens using an event router.

An event router decides which consumers to deliver events to and when that occurs when these events are delivered to the consumers then actions are taken.

And then once the action is complete the system returns to waiting it goes into a dormant state and doesn't consume resources.

So in summary a mature event driven architecture it only consumes resources while handling events when events are not occurring it doesn't consume resources.

And this is one of the key components of a serverless architecture which I'll be talking about more later in this section.

Now I know that this has been a lot of theory but I promise you as you continue through the course it will really make sense why I introduce this theory in detail at this point in the course.

And it really will help you within the exam.

In the rest of this section we're going to be covering more AWS specific and practical things.

But they'll all rely on your knowledge of this evolution of systems architecture.

So thanks for watching this video.

At this point though you can go ahead finish off this video and when you're ready I'll look forward to you joining me in the next lesson.

Welcome back and in this first technical lesson of this section of the course, we'll be stepping through what an event-driven architecture is and comparing it to other architectures available within AWS.

As a solutions architect, this matters because you're the one who needs to design a solution using a specific architecture around a given set of business requirements.

So you need to have a good base level understanding of all of the different types of architectures available to you within AWS.

You can't build something unless you fully understand the architectures.

So let's jump in and get started because we've got a lot to cover.

Now to help illustrate how an event-driven architecture works, let's consider an example.

And the example that I want to use is a popular online video sharing platform that you've all probably heard of.

Yes, that's right, it's CatTube.

One of the popular ways that CatTube is used is for people to upload holiday videos of their cats.

So Bob uploads a 4k quality video of whiskers on holiday to CatTube.

Now at this point, CatTube begins some processing and it generates lots of different versions of that video at various different quality levels.

For example, 1080p, 720p and 480p.

Now this is only part of the application but it happens to be the most intensive in terms of resource usage.

The website also needs to display videos, manage playlists and channels, and store and retrieve data to and from a database.

Now there are a few ways that we could architect this solution.

Historically, the most popular systems architecture was known as a monolithic architecture.

Now think of this as a single black box with all of the components of the application within it.

So in this example, I'm just showing a subset but we've got the upload component where Bob uploads his collection of videos where whiskers is on holiday, the processing component which does the conversion of videos, and then we have the store and manage component which interacts with the underlying persistent storage.

Now this architecture has a number of considerations, a number of important things to keep in mind.

Because it's all one entity, it fails together as an entity.

If one component fails, it impacts the whole thing end to end.

If uploading fails, it could also affect processing as well as store and manage.

Logically, you know that they're separate things, you know that uploading is different than processing, which is different than store and manage.

But if they're all contained in a single monolithic architecture, one code base, one big monolithic component, then the failure of any part of that monolith can affect everything else.

The other thing to consider when talking about monoliths is they also scale together.

They're highly coupled.

All of the components generally expect to be on the same server directly connected and have the same code base.

You can't scale one without the other.

Generally with monolithic architectures, you need to vertically scale the system because everything expects to be running on the same piece of compute hardware.

And finally, and this is one of the most important aspects of monolithic architectures that you need to be aware of, they generally build together.

All of the components of a monolithic architecture are always running and because of that they always incur charges.

Even if the processing engine is doing nothing, even if no videos are being uploaded, the system capacity has to be enough to run all of them.

And so they always have allocated resources, even if they aren't consuming them.

So using a monolithic architecture tends to be one of the least cost effective ways to architect systems, ranging from small to enterprise scale.

Now we've seen earlier in the course how we can evolve a monolithic design into a tiered one.

With a tiered architecture, the monolith is broken apart.

What we have now is a collection of different tiers and each of these tiers can be on the same server or different servers.

With this architecture, the different components are still completely coupled together because each of the tiers connects to a single endpoint of another tier.

The upload tier needs to be able to send data directly at the processing tier and again this could be on the same server or a different server.

With the WordPress example that you looked at earlier in the course, we separated the database component of the monolithic application onto its own RDS instance and left the EC2 instance running the Apache web server and the WordPress application.

But both of those services still needed to communicate with each other.

They were very tightly coupled.

Now the immediate benefit of a tiered architecture versus a monolith is that these individual tiers can be vertically scaled independently.

Put simply, you can increase the size of the server that's running each of these application tiers.

What this means is that if the processing tier for example requires more CPU capacity, then it can be increased in size to cope with that additional load without having to increase the size of the upload or the store and manage tiers.

But this architecture can be evolved even more.

Instead of each tier directly connecting to each other tier, we can utilize load balances located between each of the tiers.

Remember in the previous section I mentioned internal load balances.

This is an example of when internal load balances are useful.

It means that in this example the upload tier is no longer communicating with a specific instance of the processing tier.

And it means that the store and manage tier is not communicating with a specific instance of the processing tier.

Both of them are going via a load balancer.

And if you remember from the section of the course where I talked about load balances, this means it's abstracted.

It allows for horizontal scaling, meaning additional processing tier instances can be added.

Communication occurs via the load balances, so the upload and store and manage tiers have no exposure to the architecture of the processing tier, whether it's one instance or a hundred.

This means that the processing tier is now able to be scaled horizontally by adding additional instances.

And it's now highly available.

If one instance fails, the load balancer just redistributes the connections across the working instances.

So by abstracting away from individual instance architecture for the individual tiers, using load balances now means we can scale each tier independently, either vertically or horizontally.

Now this architecture isn't perfect for two main reasons.

First, the tiers are still coupled.

The upload tier, for example, expects and requires the processing tier to exist and to respond.

While the load balancer means that we can have multiple instances for the processing tier, for example, the processing tier has to exist.

If it fails completely, then the upload tier itself will fail because the upload tier expects at least one instance of the processing tier to answer it.

If there's a backlog in processing, if the processing tier slows down and it starts to take longer to accept jobs for processing, then that can also impact the upload tier and the customer experience.

The other issue with this architecture is that even if there's no jobs to be processed, the processing tier has to have something running.

Otherwise, there'll be a failure when the upload tier attempts to add an upload job.

So it's not possible to scale the individual tiers of the application back down to zero because the communication is synchronous.

The upload tier expects to perform a synchronous communication with the processing tier.

It expects to ask for a job to be entered and it requires an answer.

So while the tiered architecture improves things, it doesn't solve all of the problems.

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 lesson I want to talk in a little bit of detail about gateway load balances.

Now these are a relatively new addition to the load balancer family and are designed for very specific sets of use cases which I'll cover in this lesson.

Now we have a lot of architectural theory to cover so let's jump in and get started straight away.

Now before we talk about gateway load balances, I want to step through the type of situation where you might choose to use one.

Consider this architecture, the Categorum Application Server in a public subnet communicating with the public internet.

Now what's missing here is some kind of inspection based security appliance, something which can check data for any exploits to protect our application server.

Now if this is an important application, which it is because it involves cats, we can improve the architecture, we can add a security appliance and this would be a transparent security device.

It would sit in the flow of traffic inbound and outbound transparently reviewing traffic as it enters the application from the public internet so protecting the application against any known exploits and then filtering any traffic on the way back out.

For example, detecting and preventing any information leakage.

Now this works well assuming that we don't really have to think about scaling.

The issue comes when we grow or shrink our application.

Remember AWS pushes the concept of elasticity where applications can grow and shrink based on increasing and decreasing load on a system.

When you need to deal with a growing and shrinking number of application instances and where this growth is extreme you need an appropriate number of security appliances and this can be complex and prone to failures.

Now this solution is tightly coupled where the application and security instances are tied together.

The failure of one can impact the other.

It doesn't scale well even in a single application environment and it's even more complex if you're trying to build multi-tenant applications.

It's this type of situation where you need to use some kind of security appliance at scale and have flexibility around network architecture when you might choose to use a gateway load balancer and over the remainder of this lesson I want to step through what they do, how they function and how to use them.

A gateway load balancer is a product which AWS have developed to help you run and scale third-party security appliances things such as firewalls, intrusion detection systems or intrusion prevention systems, even data analysis tools.

You might use these for example to perform inbound and outbound transparent traffic inspection or protection.

Now AWS have a lot of awesome networking products but there are many large businesses who use third-party security and networking products.

You might do this because you have existing skills on those products and want to use them inside AWS or you might have a formal requirement to use those products or a specific feature or set of features which only one specific vendor can deliver.

So in those cases you'll need to use a third-party appliance and to do that at scale in a manageable way you'll need to use a gateway load balancer.

At a high level a gateway load balancer has two major components.

First, gateway load balancer endpoints which run from a VPC where the traffic you want to monitor, filter or control originates from or is destined to.

So in the example I'll be using the VPC where the Category Application Instance is hosted.

Now gateway load balancer endpoints are much like interface endpoints within VPCs which you've experienced so far but with some key improvements which I'll talk about in a second.

The other component is the gateway load balancer or GWLB itself and this load balancers packets across multiple back-end instances and these are just normal EC2 instances running security software.

In order for this type of architecture to work the gateway load balancer needs to forward packets without any alteration.

The security appliance needs to review packets as they're sent or as they're received.

After all that's the whole point.

These packets have source and destination IP addresses which might be okay on the original network but which might not work on the network where the security appliances are hosted from.

And so gateway load balancers use a protocol called Geneva and this is a tunnelling protocol.

A tunnel is created between the gateway load balancer and the back-end instances so the security appliances.

Packets are encapsulated and sent through this tunnel to the appliances.

Now let's review this visually which should help you understand how all of the components fit together.

Let's say that we have a laptop and this is accessing the Categorum application.

Now I'm keeping this simple for now and not including any VPC boundaries.

I'll show you this in a moment.

So traffic leaves this source laptop and moves into a VPC through an internet gateway and arrives at a gateway load balancer endpoint.

So gateway load balancer endpoints this is like a normal VPC interface endpoint with one major difference.

It can be added to a route table as the next hop and this allows it to be part of traffic flows controlled by that route table.

So traffic via a route table is directed at this endpoint and then the traffic flows through to a gateway load balancer.

So gateway load balancers allow three and four devices similar in many ways to a network load balancer.

But it integrates with gateway load balancer endpoints and it encapsulates all traffic that it handles between it and the targets using the Geneva protocol.

And this means that packets are unaltered.

They have the same source IP destination IP source port destination port and contents as when they were created and sent.

This allows the security appliances to scan the packets review them for any security issues block them as required perform analysis or adjust them as needed.

And when finished the packets are returned over the same tunnel encapsulated back to the load balancer where the Geneva encapsulation is removed and then the packets move back to the gateway load balancer endpoint and through to the intended destination.

Now the benefits of this architecture are that gateway load balancers will load balance across security appliances so you can horizontally scale.

The gateway load balancer manages flow stickiness so one flow of data will always use one appliance and this is useful because it allows that appliance to monitor the state of flows through a system.

It provides abstraction.

It means that you can use multiple security appliances to provide resilience.

If one of them fails then packets are just moved over to another available security appliance.

So in this way it's much like other load balancers within AWS.

Now just before we finish up with this lesson I wanted to provide a little bit more of a detailed typical architecture where you might use a gateway load balancer.

So this is the category application.

It's running in a pair of private subnets at the bottom behind an application load balancer which is running in a pair of public subnets.

Off to the right we have a separate VPC running a set of security appliances inside an auto scaling group so this can grow and shrink based on load to the application.

Now what I want to do now is to step through traffic flow through this architecture and show you how the gateway load balancer architecture works to ensure we can scale this security platform.

So we start at the top with a client which is accessing the web application.

Now this flow is going to be arriving at the application load balancer which uses public addressing and so logically it first hits the internet gateway.

The internet gateway is configured with an ingress route table also known as a gateway route table which influences what happens as traffic arrives at the VPC.

In this case our packets are destined for the public IP that the application load balancer on the right is using.

The internet gateway first translates the destination public IP address onto the corresponding private IP of that application load balancer and this will be running inside the 10.16.96.0/20 subnet.

So this is the subnet where the application load balancer is running from.

So the third route is used because it's the most specific route for the 10.16.96.0/20 range and traffic is sent towards the gateway load balancer endpoint in the right availability zone.

Remember gateway load balancer endpoints are like interface endpoints but they can be the targets within routes.

So the gateway load balancer endpoint receives these packets and then moves these packets through to the gateway load balancer itself which is running in the security VPC.

At this point the packets still have the original IP addressing and normally this would be a problem since the security VPC might be using a different or maybe even conflicting IP range.

So while the source and destination addressing remains the same the packets are encapsulated using the Geneva protocol and sent through unaltered to the security appliance chosen by the gateway load balancer.

The exact nature of the analysis which takes place depends on the security appliance and that's one of the benefits of using a gateway load balancer.

It just allows third party appliances to be used in a scalable way.

It doesn't inflict a particular feature set on us as network engineers or architects.

So once the analysis has happened the packets are returned encapsulated to the gateway load balancer.

The encapsulation is stripped and returned via the endpoint to the Category VPC.

Since the original IP addressing is maintained the route table on the top public subnet is used which has a local route for the VPC side arrange.

This as the most specific route available is used and packets flow through to the application load balancer and from there through to the chosen application instance.

And of course this logic is decided upon by the application load balancer.

Now the return path uses the same logic data leaves the application instance in response to the initial communication from the laptop and so it will return via the application load balancer.

The load balancer is in a subnet which has a local route but the default route goes towards the gateway load balancer endpoint in the same availability zone.

Now since traffic is going back to the client device who originally accessed the Category application it will have a public IP version 4 destination IP address and so the default route will be used.

This means the packets will flow back to the gateway load balancer endpoint and then from there through to the gateway load balancer where they'll be encapsulated passed through to the appliances then back to the load balancer de-encapsulated and passed back to the gateway load balancer endpoint.

Once they're back at the gateway load balancer endpoint the subnet which the gateway load balancer endpoints are in has the internet gateway as the default route and so this will be used and traffic moves through the internet gateway where its source IP will be changed to the corresponding public one of the application load balancer and then the data will be sent on through to the original client device.

And that's it transparent inline network security done in a scalable resilient and abstracted way.

Now I'm going to be talking more about some of the more nuanced features in other lessons but for now that's the basics covered of gateway load balancers.

In terms of other architecture they share many elements with network and application load balancers including the target group architecture but they have a very specific purpose network security at scale.

Now with that being said that's everything which I wanted to cover in this video so go ahead and complete the lesson and then when you're ready I 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 brief lesson I want to cover two features of the Elastic Load Balancer series of products and those features are SSL offload and session stickiness.

Now you'll need to be aware of the architecture of both of these for the exam.

The implementation details aren't required, the theory of the architecture is what matters, so let's jump in and get started.

Now there are three ways that a load balancer can handle secure connections and these three ways are bridging, pass through and offload.

Each of these comes with their pros and their cons and for the exam and to be a good solutions architect you need to understand the architecture and the positives and negatives of them all.

So let's step through each of these in turn.

So first we've got bridging mode and this is actually the default mode of an application load balancer.

With bridging mode one or more clients makes one or more connections to a load balancer and that load balancer is configured so that its listener uses HTTPS and this means that SSL connections occur between the client and the load balancer.

So they're decrypted known as terminated on the load balancer itself and this means that the load balancer needs an SSL certificate which matches the domain name that the application uses.

And it also means in theory that AWS do have some level of access to that certificate and that's important if you have strong security frameworks that you need to stay inside of.

So if you're in a situation where you need to be really careful about where your certificates are stored then potentially you might have a problem with bridged mode.

Once the secure connection from the client has been terminated on the load balancer the load balancer makes second connections to the back end compute resources EC2 instances in this example.

Remember HTTPS is just HTTP with a secure wrapper.

So when the SSL connection comes from the client to the front facing the listener side of the load balancer it gets terminated which essentially means that the SSL wrapper is removed from the unencrypted HTTP which is inside.

So the load balancer has access to the HTTP which it can understand and use to make decisions.

So the important thing to understand is that an application load balancer in bridging mode can actually see the HTTP traffic.

It can take actions based on the contents of HTTP and this is the reason why this is the default mode for the application load balancer.

And it's also the reason why the application load balancer requires an SSL certificate because it needs to decrypt any data that's being encrypted by the client.

It needs to decrypt it first then interpret it then create new encrypted sessions between it and the back end EC2 instances.

Now this also means that the EC2 instances will need matching SSL certificates.

So certificates which match the domain name that the application is using.

So the elastic load balancer will re-encrypt the HTTP within a secure wrapper and deliver this to the EC2 instances which will use the SSL certificate to decrypt that encrypted connection.

So they both need the SSL certificates to be located on the EC2 instances as well as needing the compute to be able to perform those cryptographic operations.

So in bridging mode which is the default, every EC2 instance at the back end needs to perform cryptographic operations.

And for high volume applications the overhead of performing these operations can be significant.

So the positives of this method is that the elastic load balancer gets to see the unencrypted HTTP and can take actions based on what's contained in this plain text protocol.

The method does have negatives though because the certificate does need to be stored on the load balancer itself and that's a risk.

And then the EC2 instances also need a copy of that certificate which is an admin overhead and they need the compute to be able to perform the cryptographic operations.

So those are two pretty important negatives that can play a part on which connection method you select for any architectures that you design.

Now next we have SSL pass through and this architecture is very different.

With this method the client connects but the load balancer just passes that connection along to one of the back end instances.

It doesn't decrypt it at all.

The connection encryption is maintained between the client and the back end instances.

The instances still need to have the SSL certificates installed but the load balancer doesn't.

Specifically it's a network load balancer which is able to perform this style of connection architecture.

The load balancer is configured to listen using TCP.

So this is important.

It means that it can see the source and destination IP addresses and ports.

So it can make basic decisions about which instances send traffic to i.e. the process of performing the load balancing.

But it never touches the encryption.

The encrypted connection exists as one encrypted tunnel between the client all the way through to one of the back end instances.

Now using this method means that AWS never need to see the certificate that you use.

It's managed and controlled entirely by you.

You can even use a cloud HSM appliance which I'll talk about later in the course to make this even more secure.

The negative though is that you don't get to perform any load balancing based on the HTTP part because that's never decrypted.

It's never exposed to the network load balancer and the instances still need to have the certificates and still need to perform the cryptographic operations which users compute.

Now the last method that we have is SSL offload and with this architecture clients connect to the load balancer in the same way using HTTPS.

The connections use HTTPS and are terminated on the load balancer and so it needs an SSL certificate which matches the name that's used by the application.

But the load balancer is configured to connect to the back end instances using HTTP so the connections are never encrypted again.

What this means is that from a customer perspective data is encrypted between them and the load balancer.

So at all times while using the public internet data is encrypted but it transits from the load balancer to the EC2 instances in plain text form.

It means that while a certificate is required on the load balancer it's not needed on the EC2 instances.

The EC2 instances only need to handle HTTP traffic and because of that they don't need to perform any cryptographic operations which reduces the per instance overhead and also potentially means you can use smaller instances.

The downside is that data is in plain text form across AWS's network but if this isn't a problem then it's a very effective solution.

So now that we've talked about the different connection architectures now let's quickly talk about stickiness.

Connection stickiness is a pretty important concept to understand for anybody designing a scalable solution using load balancers.

Now let's look at an example architecture.

We have our customer Bob, a load balancer and a set of back end EC2 instances.

If we have no session stickiness then for any sessions which Bob or anyone else makes they're distributed across all of the back end instances based on fair balancing and any health checks.

So generally this means a fairly equal distribution of connections across all back end instances.

The problem with this approach though is that if the application doesn't handle sessions externally every time Bob lands on a new instance it would be like he's starting again.

He would need to log in again and fill his shopping cart again.

Applications need to be designed to handle state appropriately, an application which uses stateless EC2 instances where the state is handled in say DynamoDB can use this non-sticky architecture and operate without any problems.

But if the state is stored on a particular server then you can't have sessions being fully load balanced across all of the different servers because every time a connection moves to a different server it will impact the user experience.

Now there is an option available within Elastic Load Balancers called session stickiness and within an application load balancer this is enabled on a target group.

Now what this means is that if enabled the first time that a user makes a request the load balancer generates a cookie called AWSALB.

And this cookie has a duration which you define when enabling the feature and a valid duration is anywhere between 1 second and 7 days.

If you enable this option it means that every time a single user accesses this application the cookie is provided along with the request and it means that for this one particular cookie sessions will be sent always to the same back end instance.

So in this case all connections will go to EC2-2 for this one particular user.

Now this situation of sending sessions to the same server this will happen until one of two things occur.

The first thing is that if we have a server failure so in this example if EC2-2 fails then this one particular user will be moved over to a different EC2 instance.

And the second thing which can occur to change this session stickiness is that the cookie can expire.

As soon as the cookie expires and disappears the whole process will repeat over again and the user will receive a new cookie and be allocated a new back end instance.

Session stickiness is designed to allow an application to function using a load balancer if the state of the user session is stored on an individual server.

The problem with this method is that it can cause uneven load on back end servers because a single user even if he or she is causing significant amounts of load will only ever use one single server.

Where possible applications should be designed to use stateless servers.

So holding the session or user state somewhere else so not on the EC2 instance but somewhere else like DynamoDB.

And if you do that if you host the session externally it means that the EC2 instances are completely stateless and load balancing can be performed automatically by the load balancer without using cookies in a completely fair and balanced way.

So that's everything I wanted to cover about connection stickiness and that's now the end of this lesson.

I just wanted to quickly cover two pretty important techniques that you might need to be aware of for the exam.

So at this point go ahead and complete the video and when you're ready as always I'll look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk about auto-scaling groups and health checks.

Now this is going to be fairly brief but it's something that's really important for the exam.

So let's jump in and get started.

Auto-scaling groups assess the health of instances within that group using health checks.

And if an instance fails a health check then it's replaced within the auto-scaling group.

So this is a method of automatically healing the instances within the auto-scaling group.

Now there are three different types of health checks which can be used with auto-scaling groups.

We have EC2 which is the default.

We have ELB checks which can be enabled on an auto-scaling group.

And then we have custom health checks.

Now with EC2 checks which are the default any of these statuses is viewed as unhealthy.

So essentially anything but the instance running is viewed as unhealthy.

So if it's stopping, if it's stopped, terminated, if it's shutting down or if it's impaired meaning it doesn't have two out of two status checks then it's viewed as unhealthy.

We also have the option of using load balancer health checks and for an instance to be viewed as healthy when this option is used the instance needs to be both running and it needs to be passing the load balancer health check.

Now this is important because if you're using an application load balancer then these checks can be application aware.

So you can define a specific page of that application that can be used as a health check.

You can do text pattern matching and this can be checked using an application load balancer.

So when you integrate this with an auto-scaling group the checks that that auto-scaling group is capable of performing become much more application aware.

Finally we have custom health checks and this is where an external system can be integrated and mark instances as healthy or unhealthy.

So this allows you to extend the functionality of these auto-scaling group health checks by implementing a process specific to your business or using an external tool.

Now I also want to introduce the concept of a health check grace period.

So by default this is 300 seconds or 5 minutes and essentially this is a configurable value which needs to expire before health checks will take effect on a specific instance.

So in this particular case if you select 300 seconds then it means that a system has 5 minutes to launch the system, to perform any bootstrapping and then any application start-up procedures or configuration before it can fail a health check.

So this is really useful if you're performing bootstrapping with your EC2 instances which are launched by the auto-scaling group.

Now this is an important one because it does come up on the exam and it's often a cause of an auto-scaling group continuously provisioning and then terminating instances.

If you don't have a sufficiently long health check grace period then you can be in a situation where the health checks start taking effect before the applications have finished configuring and at that point it will be viewed as unhealthy, terminated and a new instance will be provisioned and that process will repeat over and over again.

So you need to know how long your application instances take to launch, bootstrap and then perform any configuration processes and that's how long you need to set your health check grace period to be.

Now that's everything I wanted to cover in this brief theory lesson.

I just wanted to make sure that you understand the options that you have available for health checks within auto-scaling groups.

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

Welcome back and in this lesson I want to quickly cover a pretty advanced feature of auto scaling groups and that's auto scaling group life cycle hooks.

So let's jump in and take a look at what these are and how they work.

So life cycle hooks allow you to configure custom actions which can occur during auto scaling group actions.

So you can define actions which occur either during instance launch transitions or instance terminate transitions.

So what this allows you to do is when an auto scaling group scales out or scales in it will either launch or terminate instances and normally this process is completely under the control of the auto scaling group.

So as soon as it makes a decision to provision or terminate an instance this process happens with no ability for you to influence the outcome.

What life cycle hooks do is when you create them instances are paused within the launch or terminate flow and they pause or wait in this state until one of two things happen.

Either a configurable timeout and when that timeout expires which by default is 3600 seconds they will either continue or abandon the auto scaling group action.

The alternative is whatever process that you perform you can explicitly resume the process using complete life cycle action once you've performed whichever activity you want to perform.

Now in addition to this life cycle hooks can either be integrated with EventBridge or SNS notifications which allow your systems to perform event driven processing based on the launch or termination of EC2 instances within an auto scaling group.

So let's look at how this looks visually.

So let's start with a simple auto scaling group.

If we configure instance launch and terminate hooks this is what it might look like.

So normally when an auto scaling group gets a scale out situation an instance will be launched and it starts off in the pending state.

When it completes it will move into the in service state but this gives us no opportunity to perform any custom activities.

What we could do is define a life cycle hook and hook into the instance launch transition.

So if we do hook into this transition the instance would move from pending to pending wait and it would wait in this state.

This allows us to perform a set of custom actions.

An example might be to load or index some data which might take some time and during this time the instance stays in this state.

Once done it will move from a pending wait state to a pending proceed state and from there it would move into the in service state.

So this is the process when configuring a life cycle hook for this part of an EC2 instances life cycle.

It's these extra steps the wait and proceed which allows the opportunity to run custom actions and the same happens in reverse if we define an instance terminate hook.

What would normally happen when a scaling event happens would be the instance would move from a terminating state to a terminated state and again we wouldn't have the ability to perform any custom actions.

Well what we could do is define a life cycle hook to hook into that instead the instance would move from terminating to terminating wait where it would wait for a timeout.

Now by default this is 3600 seconds and it would wait at this point or until we ran the complete life cycle action operation.

We could use this time period to maybe back up some data or logs or otherwise tidy up the instance prior to its termination and once the timeout expired or when we explicitly call complete life cycle action then it would move from terminating wait to terminating proceed and then finally through to the terminated state.

Now life cycle hooks can integrate as I mentioned previously with SNS for transition notifications and EventBridge can also be used to initiate other processes based on the hooks in an event-driven way.

Now that's everything I wanted to cover about life cycle hooks so at this point go ahead and complete this lesson and when When you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover in a little bit more detail something I've touched on earlier and that's Auto Scaling Group Scaling Polices.

So let's just jump in and get started.

One thing many students get confused over is whether scaling policies are required on an Auto Scaling Group.

Now you'll see in demos elsewhere in the course that this is not the case.

They can be created without any Auto Scaling Polices and they work just fine.

When created without any scaling policies it means that an Auto Scaling Group has static values for min size, max size and desired capacity.

Now if you hear the term manual scaling that actually refers to when you manually adjust these values.

Now this is useful in testing or urgent situations or when you need to hold capacity at a fixed number of instances for example as a cost control measure.

Now in addition to manual scaling we also have different types of dynamic scaling which allow you to scale the capacity of your Auto Scaling Group in response to changing demand.

So there are a few different types of dynamic scaling and I want to introduce them here and then cover them in a little bit more detail.

At a high level each of these adjusts the desired capacity of an Auto Scaling Group based on a certain criteria.

First we have simple scaling and with this one you define actions which occur when an alarm moves into an alarm state.

For example by adding one instance if CPU utilization is above 40% or removing one instance if CPU utilization is below 40%.

This helps infrastructure scale out and in based on demand.

The problem is that this scaling is inflexible.

It's adding or removing a static amount based on the state of an alarm.

So it's simple but it's not all that efficient.

Step scaling increases or decreases the desired capacity based on a set of scaling adjustments known as step adjustments that vary based on the size of the alarm breach.

So you can define upper and lower bounds.

For example you can pick a CPU level which you want say 50% and you can say that if the actual CPU is between 50 and 60% then do nothing.

If the CPU is between 60 and 70% then add one instance or if the CPU is between 70 and 80 add two instances and then finally the CPU is between 90 and 100% then add three instances and you can do the same in reverse.

The same step changes as CPU is below 50% only removing rather than adding instances.

Now generally step scaling is always better than simple because it allows you to adjust better to changing load patterns on the system.

Next we have target tracking which comes with a predefined set of metrics.

Currently this is CPU utilization, average network in, average network out and ALB request count per target.

Now the premise is simple enough you define an ideal value so the target that you want to track against for that metric for example you might say that you want 50% CPU on average.

The auto scaling group then calculates the scaling adjustment based on the metric and the target value all automatically.

The auto scaling group keeps the metric at the value that you want and it adjusts the capacity as required to make that happen so the further away the actual value of the metric is from your target value the more extreme the action either adding or removing compute.

Then lastly it's possible to scale based on an SQS queue and this is a common architecture for a workable where you can increase or decrease capacity based on approximate number of messages visible so as more messages are added to the queue the auto scaling group increases in capacity to process messages and then as the queue empties the group scales back to reduce costs.

Now one really common area of confusion is the difference between simple scaling and step scaling.

AWS recommends step scaling versus simple at this point in time but it's important to understand why so let's take a look visually.

Let's start with some simple scaling and I want to explain this using the same auto scaling group but at three points in time.

The auto scaling group is initially configured with a minimum of one, a maximum of four and a desired of one and that means right now we're going to have one out of a maximum of four instances provisioned and operational and let's also assume that the current average CPU is 10%.

Now with simple scaling we create or use an existing alarm as a guide.

Let's say that we decide to use the average CPU utilization so we create two different scaling rules.

The first which says that if average CPU is above 50% then add two instances and another which removes two instances if the CPU is below 50%.

With this type of scaling if the CPU suddenly jumped to say 60% then the top rule would apply and this rule would add two instances changing the desired capacity from one to three.

This value is still within the minimum of one and the maximum of four and so two additional instances would be provisioned with room for a fourth.

If the CPU usage dropped to say 10% then the second rule would apply and the desired capacity would be reduced by two or set to the minimum so in this case it would change from three to one.

Two instances would be terminated and the auto scaling group would be running with one instance and a capacity for three more as required.

Now this works but it's not very flexible.

Whatever the load whether it's 1% over what you want or 50% over two instances are added and the same is used in reverse.

Whether it's 1% below what you want or 50% below the same two instances are always removed so with simple scaling you're adding or removing the same amount no matter how extreme the increases and decreases in the metric that you're monitoring.

With step scaling it's more flexible so with step scaling you're still checking an alarm but for step scaling you can define rules with steps so you can define an alarm which alarms when the CPU is above 50% and one which alarms when the CPU is below 50% and you can create steps which adjust capacity based on how far away from that value it is.

So in this case if the CPU usage is between 50 and 59% do nothing between 60 and 69% add one between 70 and 79% add two and then between 80 and 100 add three and the same in reverse so between 40 and 49 do nothing between 30 and 39 remove one between 20 and 29 remove two and then between 0 and 19 remove three.

So let's say that we had an auto scaling group at six points in time so we start with the auto scaling group on the left and let's say that it has 5% load and let's say that we have the same minimum one maximum four as the previous example the policy is trying to remove three instances with this level of CPU but as the auto scaling group has the minimum of one the auto scaling group starts with one instance with a capacity for a further three as required.

If our application receives a massive amount of incoming load let's say that the CPU usage increases to 100% and this is an extreme example but based on the scaling policy this would add three instances taking us to the maximum value of four so our auto scaling group now has four instances running which is also the maximum value for that group.

Now at this point with the same amount of incoming load the increased number of instances is probably going to reduce the average CPU.

Let's say that it reduces it to 55% well this causes no change instances and neither added or removed because anything in the range of 40 to 59 means zero change.

Next say that the load on the system reduces so CPU drops to 5% and this removes three instances dropping the desired capacity down to one with the option for a further three instances as required.

Next the average CPU stays at 5 but the minimum of the auto scaling group is one so the number of instances stay the same even though the step scaling rule should attempt to remove three instances at this level so we always have the minimum number of instances as defined within the minimum value of the auto scaling group.

Now maybe we end the day with some additional load on the system let's say for example that the CPU usage goes to 60% and this adds one additional instance so you should be able to see by now that step scaling is great for variable load where you need to control how systems scale out and in.

It allows you to handle large increases and decreases in load much better than simple scaling so based on how extreme the increase or decrease is determines how many units of compute are added or removed it's not static like simple scaling and that's the main difference between simple and step the ability to scale in different ways based on how extreme the load changes are.

With that being said though that's everything I wanted to cover in this lesson 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 lesson I'm going to be covering EC2, auto scaling groups which is how we can configure EC2 to scale automatically based on demand placed on the system.

Auto scaling groups are generally used together with elastic load balances and launch templates to deliver elastic architectures.

Now we've got a lot to cover so let's jump in and get started.

Auto scaling groups do one thing.

They provide auto scaling for EC2.

Strictly speaking they can also be used to implement a self healing architecture as part of that scaling or in isolation.

Now auto scaling groups make use of configuration defined within launch templates or launch configurations and that's how they know what to provision.

An auto scaling group uses one launch configuration or one specific version of a launch template which is linked to it.

You can change which of those is associated but it's one of them at a time and so all instances launched using the auto scaling group are based on this single configuration definition either defined inside a specific version of a launch template or within a launch configuration.

Now an auto scaling group has three super important values associated with it.

We've got the minimum size, the desired capacity and the maximum size and these are often referred to as min, desired and max and can often be expressed as x, y or z.

For example 1, 2, 4 means 1 minimum, 2 desired and 4 maximum.

Now an auto scaling group has one foundational job which it performs.

It keeps the number of running EC2 instances the same as the desired capacity and it does this by provisioning or terminating instances.

So the desired capacity always has to be more than the minimum size and less than the maximum size.

If you have a desired capacity of 2 but only one running EC2 instance then the auto scaling group provisions a new instance.

If you have a desired capacity of 2 but have three running EC2 instances then the auto scaling group will terminate an instance to make these two values match.

Now you can keep an auto scaling group entirely manual so there's no automation and no intelligence.

You just update values and the auto scaling group performs the necessary scaling actions.

Normally though scaling policies are used together with auto scaling groups.

Scaling policies can update the desired capacity based on certain criteria for example CPU load and if the desired capacity is updated then as I've just mentioned it will provision or terminate instances and visually this is how it looks.

We have an auto scaling group and these run within a VPC across one or more subnets.

The configuration for EC2 instances is provided either using launch templates or launch configurations and then on the auto scaling group we specify a minimum value.

In this case 1 and this means there will always be at least one running EC2 instance.

In this case the cat pictures blog.

We can also set a desired capacity in this example 2 and this will add another instance if a desired capacity is set which is higher than the current number of instances.

If this is the case then instances are added.

Finally we could set the maximum size in this case to 4 which means that two additional instances could be provisioned but they won't immediately be because the desired capacity is only set to 2 and there are currently two running instances.

We could manually adjust the desired capacity up or down to add or remove instances which would automatically be built based on the launch template or launch configuration.

Alternatively we could use scaling policies to automate that process and scale in or out based on sets of criteria.

Architecturally auto scaling groups define where instances are launched.

They're linked to a VPC and subnets within that VPC are configured on the auto scaling group.

Whatever subnets are configured will be used to provision instances into.

When instances are provisioned there's an attempt to keep the number of instances within each availability zone even.

So in this case if the auto scaling group was configured with three subnets and the desired capacity was also set to three then it's probable each subnet would have one EC2 instance running within it but this isn't always the case.

The auto scaling group will try and level capacity where available.

Scaling policies are essentially rules.

Rules which you define which can adjust the values of an auto scaling group and there are three ways that you can scale auto scaling groups.

The first is not really a policy at all it's just to use manual scaling and I just talked about doing that.

This is where you manually adjust the values at any time and the auto scaling group handles any provisioning or termination that's required.

Next there's scheduled scaling which is great for sale periods where you can scale out the group when you know there's going to be additional demand or when you know a system won't be used so you can scale in outside of business hours.

Scheduled scaling adjusts the desired capacity based on schedules and this is useful for any known periods of high or low usage.

For the exam if you have known periods of usage then scheduled scaling is going to be a great potential answer.

Then we have dynamic scaling and there are three subtypes.

What they all have in common is they are rules which react to something and change the values on an auto scaling group.

The first is simple scaling and this well it's simple.

This is most commonly a pair of rules one to provision instances and one to terminate instances.

You define a rule based on a metric and an example of this is CPU utilization.

If the metric for example CPU utilization is above 50% then adjust the desired capacity by adding one and if the metric is below 50% then remove one from the desired capacity.

Using this method you can scale out meaning adding instances or scale in meaning terminating instances based on the value of a metric.

Now this metric isn't limited to CPU it can be many other metrics including memory or disk input output.

Some metrics need the cloud watch agent to be installed.

You can also use some metrics not on the EC2 instances.

For example maybe the length of an SQSQ which will cover elsewhere in the course or a custom performance metric within your application such as response time.

We also have stepped scaling which is similar but you define more detailed rules and this allows you to act depending on how out of normal the metric value is.

So maybe add one instance if the CPU usage is above 50% but if you have a sudden spike of load maybe add three if it's above 80% and the same could happen in reverse.

Step scaling allows you to react quicker the more extreme the change in conditions.

Step scaling is almost always preferable to simple except when your only priority is simplicity.

And then lastly we have target tracking and this takes a slightly different approach.

It lets you define an ideal amount of something say 40% aggregate CPU and then the group will scale as required to stay at that level provisioning or terminating instances to maintain that desired amount or that target amount.

Now not all metrics work for target tracking but some examples of ones that are supported are average CPU utilization, average network in, average network out and the one that's relevant to application load balances request count per target.

Now lastly there's a configuration on an auto scaling group called a cooldown period and this is a value in seconds.

It controls how long to wait at the end of a scaling action before doing another.

It allows auto scaling groups to wait and review chaotic changes to a metric and can avoid costs associated with constantly adding or removing instances.

Because remember there is a minimum billable period.

Since you'll build for at least the minimum time every time an instance is provisioned regardless of how long you use it for.

Now auto scaling groups also monitor the health of instances that they provision.

By default this uses the EC2 status checks.

So if an EC2 instance fails EC2 detects this passes this on to the auto scaling group and then the auto scaling group terminates the EC2 instance then it provisions a new EC2 instance in its place.

This is known as self healing and it will fix most problems isolated to a single instance.

The same would happen if we terminated an instance manually.

The auto scaling group would simply replace it.

Now there's a trick with EC2 and auto scaling groups.

If you create a launch template which can automatically build an instance then create an auto scaling group using that template.

Set the auto scaling group to use multiple subnets in different availability zones.

Then set the auto scaling group to use a minimum of one, a maximum of one and a desired of one.

Then you have simple instance recovery.

The instance will recover if it's terminated or if it fails.

And because auto scaling groups work across availability zones the instance can be reprovisioned in another availability zone if the original one fails.

It's cheap, simple and effective high availability.

Now auto scaling groups are really cool on their own but their real power comes from their ability to integrate with load balancers.

Take this example that Bob is browsing to the cat blog that we've been using so far and he's now connecting through a load balancer.

And the load balancer has a listener configured for the blog and points at a target group.

Instead of statically adding instances or other resources to the target group then you can use an auto scaling group configured to integrate with the target group.

As instances are provisioned within the auto scaling group then they're automatically added to the target group of that load balancer.

And then as instances are terminated by the auto scaling group then they're removed from that target group.

This is an example of elasticity because metrics which measure load on a system can be used to adjust the number of instances.

These instances are effectively added as load balancer targets and any users of the application because they access via the load balancer are abstracted away from the individual instances and they can use the capacity added in a very fluid way.

And what's even more cool is that the auto scaling group can be configured to use the load balancer health checks rather than EC2 status checks.

Application load balancer checks can be much richer.

They can monitor the state of HTTP or HTTPS requests.

And because of this they're application aware which simple status checks which EC2 provides are not.

Be careful though you need to use an appropriate load balancer health check.

If your application has some complex logic within it and you're only testing a static HTML page then the health check could respond as okay even though the application might be in a failed state.

And the inverse of this if your application uses databases and your health check checks a page with some database access requirements well if the database fails then all of your health checks could fail meaning all of your EC2 instances will be terminated and reprovisioned when the problem is with the database not the instances.

And so you have to be really careful when it comes to setting up health checks.

Now the next thing I want to talk about is scaling processes within an auto scaling group.

So you have a number of different processes or functions performed by the auto scaling group.

And these can be set to either be suspended or they can be resumed.

So first we've got launch and terminate and if launch is set to suspend then the auto scaling group won't scale out if any alarms or schedule actions take place.

And the inverse is if terminate is set to suspend then the auto scaling group will not terminate any instances.

We've also got add to load balancer and this controls whether any instances provisioned are added to the load balancer.

Next we've got alarm notification and this controls whether the auto scaling group will react to any cloud watch alarms.

We've also got az rebalance and this controls whether the auto scaling group attempts to redistribute instances across availability zones.

We've got health check and this controls whether instance health checks across the entire group are on or off.

We've also got replace unhealthy which controls whether the auto scaling group will replace any instances marked as unhealthy.

We've got scheduled actions which controls whether the auto scaling group will perform any scheduled actions or not.

And then in addition to those you can set a specific instance to either be standby or in service.

And this allows you to suspend any activities of the auto scaling group on a specific instance.

So this is really useful if you need to perform maintenance on one or more EC2 instances you can set them to standby and that means they won't be affected by anything that the auto scaling group does.

Now before we finish I just want to talk about a few final points and these are really useful for the exam.

Auto scaling groups are free.

The only costs are for the resources created by the auto scaling group and to avoid excessive costs use cooldowns within the auto scaling group to avoid rapid scaling.

To be cost effective you should also think about using more smaller instances because this means you have more granular control over the amount of compute and therefore costs that are incurred by your auto scaling group.

So if you have two larger instances and you need to add one that's going to cost you a lot more than if you have 20 smaller instances and only need to add one.

Smaller instances mean more granularity which means you can adjust the amount of compute in smaller steps and that makes it a more cost effective solution.

Now auto scaling groups are used together with application load balances for elasticity so the load balancer provides the level of abstraction away from the instances provisioned by the auto scaling group so together they're used to provision elastic architectures.

And lastly an auto scaling group controls the when and the where so when instances are launched and which subnets they're launched into.

Launch templates or launch configurations define the what so what instances are launched and what configuration those instances have.

Now at this point that's everything I wanted to cover in this lesson it's been a huge amount of theory for one lesson but these are really essential concepts that you need to understand for the exam.

So go ahead and complete this lesson and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover two features of EC2, launch configurations and launch templates.

Now they both perform a similar thing, but launch templates came after launch configurations and include extra features and capabilities.

Now I want this lesson to be fairly brief, launch configurations and launch templates are actually relatively easy to understand.

What we're going to be covering in the next lesson is auto scaling groups which utilize either launch configurations or launch templates.

So I'll try to keep this lesson as focused as possible, but let's jump in and get started.

Launch configurations and launch templates at a high level perform the same task.

They allow the configuration of EC2 instances to be defined in advance.

Their documents which let you configure things like the AMI to use, the instance type and size, the configuration of the storage which instances use, and the key pair which is used to connect to that instance.

They also let you define the networking configuration and security groups that an instance uses.

They let you configure the user data which is provided to the instance and the IAM role which is attached to the instance used to provide the instance with permissions.

Everything which you usually define at the point of launching an instance, you can define in launch configurations and launch templates.

Now both of these are not editable.

You define them once and that configuration is locked.

Launch templates as the newer of the two allow you to have versions, but for launch configurations versions aren't available.

Launch templates also have additional features or allow you to control features of the newer types of instances.

Things like T2 or T3 unlimited CPU options, placement groups, capacity reservations, and things like elastic graphics.

AWS recommend using launch templates at this point in time because they're a super set of launch configuration.

They provide all of the features that launch configuration provides and more.

Architecturally, launch templates also offer more utility.

Launch configurations have one use.

They're used as part of auto scaling groups which we'll be talking about later in this section.

Auto scaling groups offer automatic scaling for EC2 instances and launch configurations provide the configuration of those EC2 instances which will be launched by auto scaling groups.

And as a reminder, they're not editable nor do they have any versioning capability.

If you need to adjust the configuration inside a launch configuration, you need to create a new one and use that new launch configuration.

Now launch templates, they can also be used for the same thing.

So providing EC2 configuration which is used within auto scaling groups.

But in addition, they can also be used to launch EC2 instances directly from the console or the CLI.

So good old Bob can define his instance configuration in advance and use that when launching EC2 instances.

Now you'll get the opportunity to create and use launch templates in the series of demo lessons later in this section.

For now, I just wanted to cover all of the theory back to back so you can appreciate how it all fits together.

That's everything though that I wanted to cover in this lesson about launch configurations and launch templates.

In the next lesson, I'll be talking about auto scaling groups which are closely related.

Both of them work together to allow EC2 instances to scale in response to the incoming load on a system.

But for now, go ahead and finish this video and when you're ready, I look forward to speaking to you in the next.

Welcome back and in this lesson, I want to cover application and network load balances in a little bit more detail.

It's critical for the exam that you understand when to pick application load balances and when to pick network load balances.

They're both used for massively different situations.

Now we do have a lot to cover, so let's jump in and get started.

I want to start by talking about consolidation of load balances.

Historically, when using classic load balances, you connected instances directly to the load balancer or you integrated an auto scaling group directly with that load balancer, an architecture which looked something like this.

So a single domain name, categor.io using a single classic load balancer and this has attached a single SSL certificate for that domain and then an auto scaling group is attached to that and the classic load balancer distributes connections over those instances.

The problem is that this doesn't scale because classic load balancers don't support SNI and you can't have multiple SSL certificates per load balancer and so every single unique HTTPS application that you have requires its own classic load balancer and this is one of the many reasons that classic load balancers should be avoided.

With this example, we have Catergram and Dogagram and both of these are HTTPS applications and the only way to use these is to have two different classic load balancers.

Compare this to the same application architecture so both of these applications, Catergram and Dogagram, only this time using a single application load balancer.

So this is handling both applications, Catergram and Dogagram.

This time we can use listener based rules and I'll talk about what these do later in the lesson but each of these listener based rules can have an SSL certificate handling HTTPS for both domains.

Then we can have host based rules which direct incoming connections at multiple target groups which forward these on to multiple auto scaling groups.

This is a two to one consolidation so we've halved the number of load balancers required to deliver these two different applications.

But imagine how this would look if we had a hundred legacy applications and each of these used a classic load balancer.

Moving from version one to version two offers significant advantages and one of those is consolidation.

So now I just want to focus on some of the key points about application load balancers.

So these are things which are specific to the version two or application load balancer.

First, it's a true layer seven load balancer and it's configured to listen on either HTTP or HTTPS protocols.

So these are layer seven application protocols and an application load balancer understands both of these and can interpret information carried using both of those protocols.

Now the flip side to this is that the application load balancer can't understand any other layer seven protocols.

So things such as SMTP, SSH or any custom gaming protocols are not supported by a layer seven load balancer such as the application load balancer and that's important to understand.

Now additionally, the application load balancer has to listen using HTTP or HTTPS listeners.

It cannot be configured to directly listen using TCP, UDP or TLS.

And that does have some important limitations and considerations that you need to be aware of.

And I'll talk about that later on in this lesson.

Now because it's a layer seven load balancer, it can understand layer seven content.

So things like the type of the content, any cookies which are used by your application, custom headers, user location and application behavior.

The layer seven load balancer, so the application load balancer is able to inspect all of the layer seven application protocol information and make decisions based on that information.

And that's something that the network load balancer cannot do.

It has to be a layer seven load balancer so the application load balancer to understand all of these individual components.

Now an important consideration about the application load balancer is that any incoming connections, so HTTP or HTTPS, and remember HTTPS is just HTTP, which is transiting using SSL or TLS.

In all of these cases, whichever type of connection is used, it's terminated on the application load balancer.

And this means that you can't have an unbroken SSL connection from your customer through to your application instances.

It's always terminated on the load balancer and then a new connection is made from the load balancer through to the application.

This is important because this is the type of thing that matters to security teams.

And if your business operates in a fairly strict security environment, then this might well be very important.

And in some cases, it can exclude using an application load balancer.

So it can't do end-to-end unbroken SSL encryption between a client and your application instances.

And it also means that all application load balancers which use HTTPS must have SSL certificates installed on that load balancer.

Because the connection has to be terminated on the load balancer and then a new connection made to the instances.

Now application load balancers are also slower than network load balancers because there are additional levels of the networking stack which need to be processed.

So the more levels of the networking stack which are involved, the more complexity the slower the processing.

So if you're facing any exam questions which are really strict on performance, then you might want to look at network load balancers rather than application load balancers.

A benefit though that application load balancers offer is because they're layer seven, then they can evaluate the application health at layer seven.

So in addition to just testing for a successful network connection, they can actually make an application layer request to the application to ensure that it's functioning correctly.

Now application load balancers also have the concept of rules and rules direct connections which arrive at a listener.

So if you make a connection to a load balancer, what the load balancer does with that connection is determined by any rules and rules are processed in priority order.

You can have many rules which might affect a given set of traffic and they're processed in priority order.

And the last one to be processed is the default rule which is a catch all.

But you can add additional rules and each of these can have conditions.

Now things that you can have inside the conditions of a rule include checking for things like host headers, HTTP headers, HTTP request methods, path patterns, query strings and even source IP.

So these rules could take different actions depending on which domain name you're asking for, category or dogogram.

They can perform different actions based on which path you're looking for.

So images or API, they can even take different decisions based on query string and even make different decisions based on the source IP address of any customers connecting to that application load balancer.

Now rules can also have actions.

These are the things that the rules do with the traffic.

So they can forward that traffic through to a target group.

They can redirect traffic at something else.

So maybe another domain name.

They can provide a fixed HTTP response, a certain error code or a certain success code and they can even perform certain types of authentication.

So using open ID or using Cognito.

Now this is how it looks visually.

This is a simple application load balancer deployment, a single domain, category.io.

We've got one host based rule with an attached SSL certificate and the rule is using host header as a condition and forward as an action.

So it's forwarding any connections for Cognito.io to the target group for the Cognito application.

But what if you want additional functionality?

Well, let's take a look.

First, let's imagine that we want to use the same application load balancer for a corporate client who's trying to access Cognito.io.

Maybe users of Bowtie Incorporated who use the 1.3.3.7 IP address are attempting to access our load balancer and we want to present them with an alternative version of the application.

Well, we can easily handle that by defining a listener rule but this time the condition will be the source IP address of 1.3.3.7.

Now this rule would have an action to forward traffic at a separate target group, an auto scaling group which handles a second set of instances dedicated for this corporate client because the application load balancer is a layer seven device.

It can see inside the Htt protocol and make decisions based on anything within that protocol or anything up to layer seven.

Now it's worth pointing out in addition that because this is a layer seven load balancer, the connection from the load balancer to the instances for target group two will be a separate set of connections.

And that's why it's in a slightly different color of purple.

The HTTP connection from our enterprise users are terminated on the load balancer and there's a separate set of connections through to our application instances.

There's no option to pass through the encrypted connection to the instances.

It has to be terminated.

Now this might not matter but it's something that you need to know for the exam.

If you have to forward encrypted connections through to the instances without terminating them on the load balancer, then you need to use a network load balancer.

Now because it's a layer seven load balancer, you can also use rules which work on layer seven elements of the protocol.

You could route based on paths or anything else in the HTTP protocol such as headers.

And you can also redirect traffic from a HTTP level.

An example, let's say that this ALB was also handling traffic for DogoGram.

Well, you could define a rule which matched the DogoGram.io domain name and as an action instead of forwarding, you could configure a redirect towards catagram.io, the obviously superior website.

And these are just a small subset of the features which are available within the application load balancer because it's layer seven, you can pretty much perform routing decisions based on anything which you can observe at layer seven and that makes it a really flexible product.

Before we finish this lesson, let's take a quick look at network load balancers.

Network load balancers function at layer four.

So there are layer four device which means that they can interpret TCP, TLS and UDP protocols as well as TCP and UDP.

But the flip side of this is that they have no visibility or understanding of HTTP or HTTPS.

And this means that they can't interpret headers, they can't see or interpret cookies and they've got no concept of session stickiness from a HTTP perspective because that uses cookies which the network load balancer cannot interpret because that's a layer seven entity.

Now network load balancers are really, really, really fast.

They can handle millions of requests per second and have around 25% of the latency of application load balancers.

And again, this is because they don't have to deal with any of the computationally heavy upper layers of the networking stack.

They only have to deal with layer four.

This also means that they're ideal to deal with any non-HTTP or HTTPS protocols.

So examples might be SMTP email, SSH, game servers which don't use either of the web protocols and any financial applications which are not HTTP or HTTPS.

So if you see any exam questions which talk about things which aren't web or secure web and don't use HTTP or HTTPS, then you should probably default to network load balancers.

One of the downsides of not being aware of layer seven is that health checks which are performed by network load balancers only check ICMP and basic TCP handshaking.

So they're not application aware.

You can't do detailed health checking with network load balancers.

A benefit of network load balancers is that it can be allocated with static IP addresses which is really useful for white listing if you have any corporate clients.

So corporate clients can decide to white list the IPs of network load balancers and allow them to progress straight through their firewall.

And this is great for any strict security environments that you need to operate in.

Another benefit is that they can forward TCP straight through to instances.

Now, if you're familiar with the networking stack, how this works is that upper layers build on layers below them.

So because the network load balancer doesn't understand HTTP or HTTPS, then you can configure a listener to accept TCP only traffic and then forward that through to instances.

And what that means is that any of the layers that are built on top of TCP are not terminated on the load balancer.

And so they're not interrupted.

And this means that you can forward unbroken channels of encryption directly from your clients through to your application instances.

And this is a really important thing to remember for the exam.

So network load balancers and TCP listeners is how you can do unbroken end-to-end encryption.

Network load balancers are also used for private link to provide services to other VPCs.

And this is another really important thing to remember for the exam.

Now, just to finish up this lesson, I want to do a quick comparison of a number of facts that you can use to decide between network load balancing and application load balancing.

And I find it easier to remember the things which you should be using a network load balancer for.

And then if the scenario is none of those, then you can default to using an application load balancer.

So let's step through the reasons why you might choose to use a network load balancer.

Well, the first one is the one we've just discussed.

If you want to perform unbroken encryption between a client and your instances, then use network load balancers.

If you need to use static IPs for white listing, then again, network load balancers.

If you want the absolute best performance, so millions of requests per second and low latency, then again, network load balancers.

If you need to operate on protocols which are not HTTP or not HTTPS, then you need to use network load balancers.

And then finally, if you have any requirement which involves private link, then you need to use network load balancers.

And for anything else, default to using application load balancers because the additional functionality provided by these devices is often really valuable to most scenarios.

Now, with that being said, that's everything I wanted to cover about application load balancers and network load balancers for the exam.

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.

This time, we have a typical multi-tiered application.

We start with a VPC and inside that two availability zones.

On the left, we also have an Internet Facing Low Balancer.

Then we have a Web Instance Auto Scaling Group providing the front-end capability of the application.

Then we have another Low Balancer, this time an internal Low Balancer, with only private IP addresses allocated to the nodes.

Next, we have an Auto Scaling Group for the application instances.

These are used by the web servers for the application.

Then on the right, we have a pair of database instances.

In this case, let's assume they're both Aurora database instances.

So we have three tiers, Web, Application and Database.

Now, without Load Balancers, everything would be tied to everything else.

Our user, Bob, would have to communicate with a specific instance in the web tier if this failed or scaled, then Bob's experience would be disrupted.

The instance that Bob is connected to would itself connect to a specific instance in the application tier, and if that instance failed or scaled, then again, Bob's experience would be disrupted.

What we can do to improve this architecture is to put Load Balancers between the application tiers to abstract one tier from another.

And how this changes things is that Bob actually communicates with an ELB node, and this ELB node sends this connection through to a particular web server.

But Bob has no knowledge of which web server he's actually connected to because he's communicating via a Load Balancer.

If instances are added or removed, then he would be unaware of this fact because he's abstracted away from the physical infrastructure by the Load Balancer.

Now, the web instance that Bob is using, it would need to communicate with an instance of the application tier, and it would do this via an internal Load Balancer.

And again, this represents an abstraction of communication.

So in this case, the web instance that Bob is connected to isn't aware of the physical deployment of the application tier.

It's not aware of how many instances exist, nor which one it's actually communicating with.

And then at this point, to complete this architecture, the application server that's being used would use the database tier for any persistent data storage needs.

Now, without using Load Balancers with this architecture, all the tiers are tightly coupled together.

They need an awareness of each other.

Bob would be connecting to a specific instance in the web tier.

This would be connecting to a specific instance in the application tier.

And all of these tiers would need to have an awareness of each other.

Load Balancers remove some of this coupling.

They loosen the coupling.

And this allows the tiers to operate independently of each other because of this abstraction.

Crucially, it allows the tiers to scale independently of each other.

In this case, for example, it means that if the load on the application tier increased beyond the ability of two instances to service that load, then the application tier could grow independently of anything else, in this case scaling from two to four instances.

The web tier could continue using it with no disruption or reconfiguration because it's abstracted away from the physical layout of this tier, because it's communicating via a Load Balancer.

It has no awareness of what's happening within the application tier.

Now, we're going to talk about these architectural implications in depth later on in this section of the course.

But for now, I want you to be aware of the architectural fundamentals.

And one other fundamental that I want you to be completely comfortable with is cross zone load balancing.

And this is a really essential feature to understand.

So let's look at an example visually.

Bob accessing a WordPress blog, in this case, The Best Cats.

And we can assume because this is a really popular and well-architected application that it's going to be using a load balancer.

So Bob uses his device and browsers to the DNS name for the application, which is actually the DNS name of the load balancer.

We know now that a load balancer by default has at least one node per availability zone that it's configured for.

So in this example, we have a cut down version of the Animals for Life VPC, which is using two availability zones.

So in this case, an application load balancer will have a minimum of two nodes, one in each availability zone.

And the DNS name for the load balancer will direct any incoming requests equally across all of the nodes of the load balancer.

So in this example, we have two nodes, one in each availability zone.

Each of these nodes will receive a portion of incoming requests based on how many nodes there are.

For two nodes, it means that each node gets 100% divided by two, which represents 50% of the load that's directed at each of the load balancer nodes.

Now, this is a simple example.

In production situations, you might have more availability zones being used, and at higher volume, so higher throughput, you might have more nodes in each availability zone.

But this example keeps things simple.

So however much incoming load is directed at the load balancer DNS name, each of the load balancer nodes will receive 50% of that load.

Now, originally load balancers were restricted in terms of how they could distribute the connections that they received.

Initially, the way that it worked is that each load balancer node could only distribute connections to instances within the same availability zone.

Now, this might sound logical, but consider this architecture where we have four instances in availability zone A and one instance in availability zone B.

This would mean that the load balancer node in availability zone A would split its incoming connections across all instances in that availability zone, which is four ways.

And the node in availability zone B would also split its connections up between all the instances in the same availability zone.

But because there's only one, that would mean 100% of its connections to the single EC2 instance.

Now, with this historic limitation, it means that node A would get 50% of the overall connections and would further split this down four ways, which means each instance would be allocated 12.5% of the overall load.

Node B would also receive 50% of the overall load.

And normally it would split that down across all instances also in that same availability zone.

But because there's only one, that one instance would get 100% of that 50%.

So all of the instances in availability zone A would receive 12.5% of the overall load and the instance in availability zone B would receive 50% of the overall load.

So this represents a substantially uneven distribution of the incoming load because of this historic limitation of how load balancer nodes could distribute traffic.

And the fix for that was a feature known as cross zone load balancing.

Now, the name gives away what this does.

It simply allows every load balancer node to distribute any connections that it receives equally across all registered instances in all availability zones.

So in this case, it would mean that the node in availability zone A could distribute connections to the instance in AZB and the node in AZB could distribute connections to instances in AZA.

And this represents a much more even distribution of incoming load.

And this is known as cross zone load balancing, the ability to distribute or load balance across availability zones.

Now, this is a feature which originally was not enabled by default.

But if you're deploying an application load balancer, this comes enabled as standard.

But you still need to be aware of it for the exam because it's often posed as a question where you have a problem, an uneven distribution of load, and you need to fix it by knowing that this feature exists.

So it's really important that you understand it for the exam.

So before we finish up with this lesson, I just want to reconfirm the most important architectural points about elastic load balancers.

If there are only a few things that you take away from this lesson, these are the really important points.

Firstly, when you provision an elastic load balancer, you see it as one device which runs in two or more availability zones, specifically one subnet in each of those availability zones.

But what you're actually creating is one elastic load balancer node in one subnet in each availability zone that that load balancer is configured in.

You're also creating a DNS record for that load balancer which spreads the incoming requests over all of the active nodes for that load balancer.

Now you start with a certain number of nodes, let's say one node per availability zone, but it will scale automatically if additional load is placed on that load balancer.

Remember by default, cross-own load balancing means that nodes can distribute requests across to other availability zones, but historically this was disabled, meaning connections potentially would be relatively imbalanced.

But for application load balancers, cross-own load balancing is enabled by default.

Now load balancers come in two types.

Internet facing, which just means that the nodes are allocated with public IP version 4 addresses.

That's it.

It doesn't change where the load balancer is placed, it just influences the IP addressing for the nodes of that load balancer.

Internal load balancers are the same, only their nodes are only allocated private IP addresses.

Now one of the most important things to remember about load balancers is that an internet facing load balancer can communicate with public instances or private instances.

EC2 instances don't need public IP addressing to work with an internet facing load balancer.

An internet facing load balancer has public IP addresses on its nodes, it can accept connections from the public internet and balance these across both public and private EC2 instances.

That's really important to understand for the exam, so you don't actually need public instances to utilize an internet facing load balancer.

Now load balancers are configured via listener configuration, which as the name suggests controls what those load balancers listen to.

And again, I'll be covering this in much more detail later on in this section of the course.

And then lastly, remember the confusing part about load balancers.

They require eight or more free IP addresses per subnet that they get deployed into.

Strictly speaking, this means that a /28 subnet would be enough, but the AWS documentation suggests a /27 in order to allow scaling.

For now, that's everything that I wanted to cover, so go ahead and complete this lesson.

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

Welcome back and in this lesson, I want to talk about the architecture of elastic load balancers.

Now I'm going to be covering load balancers extensively in this part of the course.

So I want to use this lesson as a sort of foundation.

I'm going to cover the high level logical and physical architecture of the product and either refresh your memory on some things or introduce some of the finer points of load balancing for the first time.

And both of these are fine.

Now, before we start, it's the job of a load balancer to accept connections from customers and then to distribute those connections across any registered backend compute.

It means that the user is abstracted away from the physical infrastructure.

It means that the amount of infrastructure can change.

So increase or decrease in number without affecting customers.

And because the physical infrastructure is abstracted, it means that infrastructure can fail and be repaired, all of which is hidden from customers.

So with that quick refresher done, let's jump in and get started covering the architecture of elastic load balancers.

Now I'm going to be stepping through some of the key architectural points visually.

So let's start off with a VPC, which uses two availability zones, AZA and AZB.

And then in those availability zones, we've got a few subnets, two public and some private.

Now let's add a user, Bob, together with a pair of load balancers.

Now, as I just mentioned, it's the job of a load balancer to accept connections from a user base and then distribute those connections to backend services.

For this example, we're going to assume that those services are long running compute or EC2, but as you'll see later in this section, that doesn't have to be the case.

Elastic load balancers, specifically application load balancers, support many different types of compute services.

It's not only EC2.

Now, when you provision a load balancer, you have to decide on a few important configuration items.

The first, you need to pick whether you want to use IP version four only or dual stack.

And dual stack just means using IP version four and the newer IP version six.

You also need to pick the availability zones which the load balancer will use, specifically you're picking one subnet in two or more availability zones.

Now, this is really important because this leads in to the architecture of elastic load balancers, so how they actually work.

Based on the subnets that you pick inside availability zones, when you provision a load balancer, the product places into these subnets one or more load balancer nodes.

So what you see as a single load balancer object is actually made up of multiple nodes and these nodes live within the subnets that you pick.

So when you're provisioning a load balancer, you need to select which availability zones it goes into.

And the way you do this is by picking one and one only, subnet in each of those availability zones.

So in the example that's on screen now, I've picked to use the public subnet in availability zone A and availability zone B and so the product has deployed one or more load balancer nodes into each of those subnets.

Now when a load balancer is created, it actually gets created with a single DNS record.

It's an A record and this A record actually points at all of the elastic load balancer nodes that get created with the product.

So any connections that are made using the DNS name of the load balancer are actually made to the nodes of that load balancer.

The DNS name resolves to all of the individual nodes.

It means that any incoming requests are distributed equally across all of the nodes of the load balancer and these nodes are located in multiple availability zones and they scale within that availability zone.

And so they're highly available.

If one node fails, it's replaced.

If the incoming load to the load balancer increases, then additional nodes are provisioned inside each of the subnets that the load balancer is configured to use.

Now another choice that you need to make when creating a load balancer, and this is really important for the exam, is to decide whether that load balancer should be internet facing or whether it should be internal.

This choice, so whether to use internet facing or internal, controls the IP addressing for the load balancer nodes.

If you pick internet facing, then the nodes of that load balancer are given public addresses and private addresses.

If you pick internal, then the nodes only have private IP addresses.

So that's the only difference.

Otherwise, they're the same architecturally, they have the same nodes and the same load balancer features.

The only difference between internet facing and internal is whether the nodes are allocated public IP addresses.

Now the connections from our customers which arrive at the load balancer nodes, the configuration of how that's handled is done using a listener configuration.

As the name suggests, this configuration controls what the load balancer is listening to.

So what protocols and ports will be accepted at the listener or front side of the load balancer?

Now there's a dedicated lesson coming up later in this section which focuses specifically on the listener configuration.

At this point, I just wanted to introduce it.

So at this point, Bob has initiated connections to the DNS name associated with the load balancer.

And that means that he's made connections to load balancer nodes within our architecture.

Now at this point, the load balancer nodes can then make connections to instances that are registered with this load balancer.

And the load balancer doesn't care about whether those instances are public EC2 instances, so allocated with a public IP address or their private EC2 instances.

So instances which reside in a private subnet and only have private addressing.

I want to keep reiterating this because it's often a point of confusion for students who are new to load balancers.

An internet-facing load balancer, and remember this means that it has nodes that have public addresses so it can be connected to from the public internet, it can connect both to public and private EC2 instances.

Instances that are used do not have to be public.

Now this matters because in the exam when you face certain questions which talk about how many subnets or how many tiers are required for an application, it does test your knowledge that an internet-facing load balancer does not need private or public instances.

It can work with both of those.

The only requirement is that load balancer nodes can communicate with the back-end instances.

And this can happen whether the instances have allocated public addressing or whether they're private only instances.

The important thing is that if you want a load balancer to be reachable from the public internet, it has to be an internet-facing load balancer because logically it needs to be allocated with public addressing.

Now load balancers in order to function need eight or more free IP addresses in the subnets that they're deployed into.

Now strictly speaking, this means a /28 subnet, which provides a total of 16 IP addresses but minus the five reserved by AWS, this leaves 11 free per subnet.

But AWS suggests that you use a /27 or larger subnet to deploy an elastic load balancer in order that it can scale.

Keep in mind that strictly speaking, both a /28 and /27 subnets are both correct in their own ways to represent the minimum subnet size for a load balancer.

AWS do suggest in their documentation that you need a /27, but they also say you need a minimum of eight free IP addresses.

Now logically, a /28, which leaves 11 free, won't give you the room to deploy a load balancer and back end instances.

So in most cases, I try to remember /27 as the correct value for the minimum for a load balancer.

But if you do see any questions which show a /28 and don't show a /27, then /28 is probably the right answer.

Now internal load balancers are architecturally just like internet facing load balancers, except they only have private IPs allocated to their nodes.

And so internal load balancers are generally used to separate different tiers of applications.

So in this example, our user Bob connects via the internet facing load balancer to the web server.

And then this web server can connect to an application server via an internal load balancer.

And this allows us to separate application tiers and allow for independent scaling.

So let's look at this visually.

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'll look forward to you joining me in part two.

Welcome back and in this lesson I want to spend a few minutes just covering the evolution at the Elastic Load Balancer product.

It's important for the exam and real world usage that you understand its heritage and its current state.

Now this is going to be a super quick lesson because most of the detail I'm going to be covering in dedicated lessons which are coming up next in this section of the course.

So let's jump in and take a look.

Now there are currently three different types of Elastic Load Balancers available within AWS.

If you see the term ELB or Elastic Load Balancers then it refers to the whole family, all three of them.

Now the load balancers are split between version 1 and version 2.

You should avoid using the version 1 load balancer at this point and aim to migrate off them onto version 2 products which should be preferred for any new deployments.

There are no scenarios at this point where you would choose to use a version 1 load balancer versus one of the version 2 types.

Now the load balancer product started with the classic load balancer known as CLB which is the only version 1 load balancer and this was introduced in 2009.

So it's one of the older AWS products.

Now classic load balancers can load balance HTTP and HTTPS as well as lower level protocols but they aren't really layer 7 devices.

They don't really understand HTTP and they can't make decisions based on HTTP protocol features.

They lack much of the advanced functionality of the version 2 load balancers and they can be significantly more expensive to use.

One common limitation is that classic load balancers only support one SSL certificate per load balancer which means for larger deployments you might need hundreds or thousands of classic load balancers and these could be consolidated down to a single version 2 load balancer.

So I can't stress this enough for any questions or any real world situations you should default to not using classic load balancers.

Now this brings me on to the new version 2 load balancers.

The first is the application load balancer or ALB and these are truly layer 7 devices so application layer devices.

They support HTTP, HTTPS and the web socket protocols.

They're generally the type of load balancer that you'd pick for any scenarios which use any of these protocols.

There's also network load balancers or NLBs which are also version 2 devices but these support TCP, TLS which is a secure form of TCP and UDP protocols.

So network load balancers are the type of load balancer that you would pick for any applications which don't use HTTP or HTTPS.

For example if you wanted to load balance email servers or SSH servers or a game which used a custom protocol so didn't use HTTP or HTTPS then you would use a network load balancer.

In general version 2 load balancers are faster and support target groups and rules which allow you to use a single load balancer for multiple things or handle the load balancing different based on which customers are using it.

Now I'm going to be covering the capabilities of each of the version 2 load balancers separately as well as talking about rules but I wanted to introduce them now as a feature.

Now for the exam you really need to be able to pick between network load balancers or application load balancers for a specific situation so that's what I want to work on over the coming lessons.

For now though this has just been an introduction lesson that talks about the evolution of these products and that's everything that I wanted to cover in this lesson so go ahead complete lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back.

In this lesson, I want to talk about the regional and global AWS architecture.

So let's jump in and get started.

Now throughout this lesson, I want you to think about an application that you're familiar with, which is global.

And for this example, I'll be talking about Netflix, because this is an application that most people have at least heard of.

Now, Netflix can be thought of as a global application, but it's also a collection of smaller regional applications which make up the Netflix global platform.

So these are discrete blocks of infrastructure which operate independently and duplicated across different regions around the world.

As a solutions architect, when we're designing solutions, I find that there are three main types of architectures.

Small scale architectures which will only ever exist in one region or one country.

Then we have systems which also exist in one region or country, but where there's a DR requirement, so if that region fails for some reason, then it fails over to a second region.

And then lastly, we have systems that operate within multiple regions and need to operate through failure in one or more of those regions.

Now, depending on how you architect systems, there are a few major architectural components which will map on to AWS products and services.

So at a global level, first we have global service location and discovery.

So when you type Netflix.com into your browser, what happens?

How does your machine discover where to point at?

Next, we've got content delivery.

So how does the content or data for an application get to users globally?

Are their pockets of storage distributed globally or is it pulled from a central location?

Lastly, we've got global health checks and failover.

So detecting if infrastructure in one location is healthy or not and moving customers to another country as required.

So these are the global components.

Next, we have regional components starting with the regional entry point.

And then we have regional scaling and regional resilience and then the various application services and components.

So as we go through the rest of the course, we're going to be looking at specific architectures.

And as we do, I want you to think about them in terms of global and regional components, which parts can be used for global resilience and which parts are local only.

So let's take a look at this visually starting with the global elements.

So let's keep using Netflix as an example.

And let's say that we have a group of users who are starting to settle down for the evening and want to watch the latest episode of Ozarks.

So the Netflix client will use DNS for the initial service discovery.

Netflix will have configured the DNS to point at one or more service endpoints.

Let's keep things simple at this point and assume that there is a primary location for Netflix in a US region of AWS, maybe US East One.

And this will be used as the primary location.

And if this fails, then Australia will be used as a secondary.

Now, another valid configuration would be to send customers to their nearest location, in this case, sending our TV fans to Australia.

But in this case, let's just assume we have a primary and a secondary region.

So this is the DNS component of this architecture and Route 53 is the implementation within AWS.

Now, because of its flexibility, it can be configured to work in any number of ways.

The key thing for this global architecture, though, is that it has health checks.

So it can determine if the US region is healthy and direct all sessions to the US while this is the case, or direct sessions to Australia if there are problems with the primary region.

Now, regardless of where infrastructure is located, a content delivery network can be used at the global level.

This ensures that content is cached locally as close to customers as possible, and these cache locations are located globally, and they all pull content from the origin location as required.

So just to pause here briefly, this is a global perspective.

The function of the architecture at this level is to get customers through to a suitable infrastructure location, making sure any regional failures are isolated and sessions moved to alternative regions.

It attempts to direct customers at a local region, at least if the business has multiple locations, and lastly, it attempts to improve caching using a content delivery network such as CloudFront.

If this part of our architecture works well, customers will be directed towards a region that has infrastructure for our application, and let's assume this region is one of the US ones.

At this point, the traffic is entering one specific region of the AWS infrastructure.

Depending on the architecture, this might be entering into a VPC or using public space AWS services, but in either case, now we're architecturally zoomed in, and so we have to think about this architecture now in a regional sense.

The most effective way to think about systems architecture is a collection of regions making up a whole.

If you think about AWS products and services, very few of them are actually global.

Most of them run in a region, and many of those regions make up AWS.

Now it's efficient to think in this way, and it makes designing a large platform much easier.

For the remainder of this course, we're going to be covering architecture in depth, so how things work, how things integrate, and what features products provide.

Now the environments that you will design will generally have different tiers, and tiers in this context are high level groupings of functionality or different zones of your application.

Initially, communications from your customers will generally enter at the web tier.

Generally, this will be a regional based AWS service such as an application load balancer or API gateway, depending on the architecture that the application uses.

The purpose of the web tier is to act as an entry point for your regional based applications or application components.

It abstracts your customers away from the underlying infrastructure.

It means that the infrastructure behind it can scale or fail or change without impacting customers.

Now the functionality provided to the customer via the web tier is provided by the compute tier, using services such as EC2, Lambda, or containers which use the elastic container service.

So in this example, the load balancer will use EC2 to provide compute services through to our customers.

Now we'll talk throughout the course about the various different types of compute services which you can and should use for a given situation.

The compute tier though will consume storage services, another part of all AWS architectures, and this tier will use services such as EBS, which is the elastic block store, EFS, which is the elastic file system, and even S3 for things like media storage.

You'll also find that many global architectures utilize CloudFront, the global content delivery network within AWS, and CloudFront is capable of using S3 as an origin for media.

So Netflix might store movies and TV shows on S3 and these will be cached by CloudFront.

Now all of these tiers are separate components of an application and can consume services from each other and so CloudFront can directly access S3 in this case to fetch content for delivery to a global audience.

Now in addition to file storage, most environments require data storage and within AWS this is delivered using products like RDS, Aurora, DynamoDB and Redshift for data warehousing.

But in order to improve performance, most applications don't directly access the database.

Instead, they go via a caching layer, so products like ElastiCache for general caching or DynamoDB Accelerator known as DAX when using DynamoDB.

This way, reads to the database can be minimized.

Applications will instead consult the cache first and only if the data isn't present in the cache will the database be consulted and the contents of the cache updated.

Now caching is generally in memory, so it's cheap and fast.

Databases tend to be expensive based on the volume of data required versus cache and normal data storage.

So where possible, you need to offload reads from the database into the caching layer to improve performance and reduce costs.

Now lastly, AWS have a suite of products designed specifically to provide application services.

So things like Kinesis, Step Functions, SQS and SNS, all of which provide some type of functionality to applications, either simple functionality like email or notifications, or functionality which can change an application's architecture such as when you decouple components using queues.

Now as I mentioned at the start of this lesson, you're going to be learning about all of these components and how you can use them together to build platforms.

For now, just think of this as an introduction lesson.

I want you to get used to thinking of architectures from a global and regional perspective as well as understanding that application architecture is generally built using components from all of these different tiers.

So the web tier, the compute tier, caching, storage, the database tier and application services.

Now at this point, that's all of the theory that I wanted to go through.

Remember, this is just an introduction lesson.

So go ahead, finish this lesson and when you're ready, I'll look forward to you joining me in the next.