Welcome back.

I spent the last few lessons going through DNS, helping you, I hope, understand how the system works at an architectural level. In this lesson, I want to finish off and talk about the types of records which can be stored in DNS, and I'll try to keep it quick, so let's get started.

The first record type that I want to touch on are nameserver records or NS records. I've mentioned these in the previous lessons in this section on DNS. These are the record types which allow delegation to occur in DNS. So we've got the dot com zone, and that's managed by Verisign. This zone will have multiple nameserver records inside it for amazon.com. These nameserver records are how the dot com delegation happens for amazon.com, and they point at servers managed by the amazon.com team. These servers host the amazon.com zone. Inside this one are DNS records such as www, which is how you can access those records as part of DNS.

Now, of course, the same is true on the other side. The root zone has delegated management of dot com by having nameservers in the root zone point at the servers that host the dot com zone. So nameserver records are how delegation works end-to-end in DNS. Nameservers are hugely important.

Next up, we have a pair of record types that you will use a lot more often in DNS, and they're A records or AAAA records, and they actually do the same thing. Given a DNS zone, in this example, google.com, these types of records map host names to IP addresses. The difference is the type of IP address. For a given host, let's say www, an A record maps this onto an IP version four address. An AAAA record type is the same, but this maps the host onto an IP version six address. Generally, as an admin or a solutions architect, you will normally create two records with the same name. One will be an A record, and one will be an AAAA record. The client operating system and DNS software on that client can then pick the correct type of address that it wants, either AAAA, if it's capable of IP version six, or just a normal A record, if it's not capable of version six.

Now next up is the CNAME record type, which stands for canonical name. For a given zone, the CNAME record type lets you create the equivalent of DNS shortcuts, so host to host records. Let's say that we have an A record called server, which points at an IP version four address. It's fairly common that a given server performs multiple tasks. Maybe in this case, it provides ftp, mail, and web services. Creating three CNAMEs and pointing them all at the A server record means that they will all resolve to the same IP version four address. CNAMEs are used to reduce admin overhead. In this case, if the IP version four address of the server changes, it's just the single record to update, the A record, because the three CNAMEs reference that A record, they'll automatically get updated. Now, CNAMEs cannot point directly at an IP address, only other names, and you can expect to see that feature in the exam as a trick question.

Next is the MX record type, and this is hugely important for how the internet works, specifically how email on the internet works. Imagine if you're using your laptop via your email server and you want to send an email to hi@google.com. MX records are used as part of this process. Your email server needs to know which server to pass the email onto. So we start with the google.com zone. Inside this zone, we have an A record with the name mail, and this is pointing at an IP address. Now it's important to know from the offset that this could be called rabbits or apple or fluffy; the name isn't important to how email works using MX records. In this case, the A record is just called mail, but it doesn't matter.

Now also inside the google.com zone is a collection of MX records, in this example, two records. MX records have two main parts, a priority and a value, and I'll revisit the priority soon. For now, let's focus on the values. The value can be just a host, as with the top example. So mail here is just mail. That's just a host. If it's just a host and we can tell that by the fact that it's got no dot on the right, it's assumed to be part of the same zone that it's in. So mail here actually means mail.google.com. It's the mail host inside the google.com zone. If you include a dot on the right, this means it's a fully qualified domain name. And so it can either point to the host inside the same zone or something outside that zone, maybe Office 365 if Google decided Microsoft's mail product was better.

The way that MX records are used is that our email server looks at the two addresses on the mail, so hi@google.com, and it focuses on the domain, so google.com. It then does an MX query using DNS on google.com. This is the same process as any other record type, so it talks to the root first, then dot com, then google.com, and then it retrieves any MX records. In this case, two different records. Now, this is where the priority value is used to choose which record to use. Lower values for the priority field are actually higher priority. So in this example, mail is used first and then mail.other.domain is only used if mail isn't functional. If the priority is the same, then any of them could be selected. Whichever is used, the server gets the result of the query back and it uses this to connect to the mail server for google.com via SMTP and it uses this protocol to deliver the mail. So in summary, an MX record is how a server can find the mail server for a specific domain. MX records are used constantly. Whenever you send an email to a domain, the server that is sending the email on your behalf is using DNS to do an MX lookup and locate the mail server to use.

The last record type that I want to talk about is a TXT record, also known as a text record. Text records allow you to add arbitrary text to a domain. It's a way in which the DNS system can provide additional functionality. One common usage for a TXT record type is to prove domain ownership. Let's say for the Animals for Life domain, we want to add it to an email system, maybe Google Mail or Office 365 or Amazon WorkMail. Whatever system we use to host our email might ask us to add a text record to the domain, containing a certain piece of text data. So let's say that the random text that we need to add is "cats are the best." Then our administrator would add a record inside this domain with that text data. And once our admin has done that, the external party, so the Google email system, would query that text data, make sure that it matches the value that they're expecting. And if it does, that would prove that we own that domain and we can manage it. So text records are fairly important in proving domain ownership, and that's one of the most common use cases that you will use the text record type for. There are other uses for the text record type. It can be used to fight spam. So you can add certain information to a domain indicating which entities are authorized to send email on your behalf. If any email servers receive email from any other servers, then that's a good indication that that email is spam and not authorized.

So those are the record types that I want to cover. But there's one more concept that I need to discuss before we finish up. And that is DNS TTL or Time To Live. A TTL value is something that can be set on DNS records. It's a numeric value in seconds. Let's look at a visual example. We have a client looking to connect to amazon.com. And so it queries DNS using a resolver server that's hosted at its internet provider. That resolver server talks to the DNS root, which points at the dot com registry authoritative servers. And so the resolver queries those servers. Those authoritative servers for dot com provide the nameservers at the amazon.com zone, and so it goes ahead and queries that. That server hosts and is authoritative for the amazon.com zone, which has a record for www. And so it uses this record to get the IP address and connect to the server.

This process takes time. This walking the tree process, talking to the root, and then all of the levels to get the eventual result that you need, it is a lengthy process. Getting a result from the authoritative source, so the source that is trusted by DNS, this is known as an authoritative answer. So you get an authoritative answer by talking to a nameserver, which is authoritative for that particular domain. So if I query the nameserver for amazon.com and I'm querying the www record in amazon.com, then I get back what's known as an authoritative answer. And that is always preferred because it's always going to be accurate. It's the single source of truth.

But using TTL values, the administrator of amazon.com can indicate to others how long records can be cached for, what amount of time is appropriate. In this example, because the admin of amazon.com has set a 3,600 TTL value, which is in seconds, it means that the results of the query are stored at the resolver server for 3,600 seconds, which is one hour. If another client queries the same thing, which is pretty likely for amazon.com, then they will get back a non-authoritative answer. But that answer will be retrieved immediately because it's cached on the resolver server. The resolver server, remember, is hosted probably at our internet provider, and so it's much quicker to access that data.

So non-authoritative answers are often the same as authoritative answers. Normally things in DNS don't change, and when they don't change, non-authoritative and authoritative is the same thing. But TTL is important for when things change. If you migrate your email service and you have a high TTL value on your MX record, and you change to a provider with a different IP address, then email delivery might be delayed because old IP addresses for those MX records will be cached and they will be used. TTLs are a balance. Low values mean more queries against your nameservers. High values mean fewer queries, but also less control if you need to change records. You can change TTL values before projects and upgrades or you can leave them permanently low. Also, keep in mind that the resolver should obey TTL values, but that's not always the case. It could ignore them. That configuration can be changed locally by the admin at the resolver server. DNS is often the cause of project failures because of TTL values. If you're doing any work that involves changing any DNS records, it's always recommended to lower the TTL value well in advance of the work, sometimes days or weeks in advance, and this will make sure that you have fewer caching issues when you finally do change those records.

Okay, that's it. That's everything I wanted to cover in this lesson. I've covered the different DNS record types, as well as introduced you to the TTL concept, which is essential to understand if you want to avoid any DNS-related problems. Thanks for listening. Go ahead, complete this video and when you're ready, join me in the next.

Welcome back and in this demo lesson I'm going to step through how you can register a domain using Route 53. Now this is an optional step within the course. Worst case you should know how to perform the domain registration process within AWS and optionally you can use this domain within certain demos within the course to get a more real-world like experience.

To get started, as always, just make sure that you're logged in to the IAM admin user of the general AWS account which is the management account of the organization. Now make sure that you have the Northern Virginia region selected. While Route 53 is a global service, I want you to get into the habit of using the Northern Virginia region. Now we're going to be using the Route 53 product, so click in the search box at the top of the screen, type Route 53 and then click to move to the Route 53 console.

Now Route 53, at least in the context of this demo lesson, has two major areas. First is hosted zones and this is where you create or manage DNS zones within the product. Now DNS zones, as you'll learn elsewhere in the course, you can think of as databases which store your DNS records. When you create a hosted zone within Route 53, Route 53 will allocate four name servers to host this hosted zone. And that's important, you need to understand that every time you create a new hosted zone, Route 53 will allocate four different name servers to host that zone. Now the second area of Route 53 is registered domains, and it's in the registered domains area of the console where you can register a domain or transfer a domain in to Route 53.

Now we're going to register a domain, but before we do that, if you do see any notifications about trying out new versions of the console, then go ahead and click to try out that new version. Where possible, I always like to teach using the latest version of the console UI because it's going to be what you'll be using long-term. So in my case, I'm going to go ahead and click on, try out the new console, depending on when you're doing this demo, you may see this or not. In either case, you want to be using this version of the console UI. So if you are going to register a domain for this course, then you need to go ahead and click register domains.

The first step is to type the domain that you want into this box. Now, a case study that I use throughout the course is animals for life. So I'm going to go ahead and register a domain related to this case study. So if I type animalsforlive.com and press enter, it will search for the domain and tell us whether it's available. In this case, animalsforlive.com is not available. It's already been registered. In my case, I'm going to use an alternative, so I'm going to try and register animalsforlive.io. Now, I/O domains are one of the most expensive, so if you are registering a domain yourself, I would tend to advise you to look for one of the cheaper ones. I'm going to register this one and it is available.

Once I've verified that it is available and it's the one I want, we're gonna go ahead and click on select. We can verify the price of this domain for one year, in this case it's 71 US dollars, and then go ahead and click on proceed to check out. Now it's here where you can specify a duration for the domain registration. You can use the default of one year, or alternatively you can go ahead and pick a longer registration period. For this domain I'm going to choose one year and then you can choose whether you want to auto renew the domain after that initial period. In my case I'm going to leave this selected. You'll see a subtotal at the price and then you can click next to move on to the next step.

Now at this point you need to specify the contact type. In most cases you'll be putting a person or a company but there's also association, public body or reseller. You need to go ahead and fill in all of these details and they do need to be valid details, that's really important. If you are worried about privacy, most domains will allow you to turn on privacy protection, so any details that you enter here cannot be seen externally. Now obviously to keep my privacy intact, I'm going to go ahead and fill in all of these details and I'm going to hide the specifics and once I've entered them all, I'm going to go ahead and click on 'Next' and you should do the same. Again I've hidden my details on the bottom of the screen.

Route 53 does tell you that in addition to the domain registration cost there is a monthly cost for the hosted zone which will be created as part of this registration. So there is a small monthly cost for every hosted zone which you have hosted using Route 53 and every domain that you have will need one hosted zone. So I'm going to scroll down. Everything looks good, you'll need to agree to the terms and conditions and then click on submit. Now at this point the domain is registering and it will take some time to complete. You may receive a registration email which may include something that you need to do, clicking on a link or some other form of identity verification. You might not get that, but if you do get it, it's important that you do follow all of the steps contained within that email. And if you don't receive an email, you should check your spam folder, because if there are any actions to perform and you don't, it could result in the domain being disabled.

You can see the status of the domain registration by clicking on "requests" directly below "registered domains". The status will initially be listed as "in progress", and we need this to change to "successful". So pause the video, wait for this status to change, and then you're good to continue. Welcome back, in my case this took about 20 minutes to complete, but as you can see my domain is now registered. So if we go to registered domains you'll be able to see the domain name listed together with the expiration date, the auto renew status, and the status of the transfer lock. Now transfer lock is a security feature, it means the domain cannot be transferred away from route 53 without you disabling this lock.

Now we're able to see additional details on the domain if we click on the domain name. Now obviously I've hidden my contact information. If you click on the DNSsecKeys tab then it's here where you can configure DNSsec on the domain. We won't be doing anything with that at this stage. One of the important points I want to draw your attention to is the name servers. So I've registered animalsforlife.io and it's these name servers that will be entered into the Animals for Life record within the .io top level domain zone. So these servers are the ones that the DNS system will point at. These currently are set to four Route 53 name servers. And because we've registered the domain inside Route 53, this process is automatic. So a hosted zone is created, four name servers are allocated to host this hosted zone And then those four name servers are entered into our domain records in our top level domain zone.

This process end-to-end is all automatic. So the four name servers for the animalsforlife.io hosted zone. These are entered into the animalsforlife.io record within the .io top level domain zone. It's all automatic. So if we move to the hosted zone area of the console and then go inside AnimalsForLife.io and then expand the hosted zone details at the top These are the four name servers which are hosting this hosted zone And if you're paying attention You'll note these are the same four servers that are contained within the registered domains Area of the console and these are the same four servers which have been entered into the .io top level domain zone. Now if you ever delete and then recreate a hosted zone It's going to be allocated with four brand new name servers. These name servers will be different than the name servers for the zone which you deleted So if you delete and recreate a hosted zone You'll be given four brand new name servers. In order to stop any DNS problems you'll need to take these brand new name servers and update the items within the registered domains area of the console but again because you've registered the domain within route 53 this process has been handled for you end to end you won't need to worry about any of this unless you delete and recreate the host of zone.

Now that's everything you need to do at this point if you followed this process throughout this demo lesson you now have an operational domain within the global DNS infrastructure that's manageable within Route 53. Now as I mentioned earlier this is an optional step for the course if you do have a domain registered then you will have the opportunity to use it within various demo lessons within the course. If you don't, don't worry, none of this is mandatory you can do the rest of the course without having a domain. At this point though that is everything I wanted you to do in this demo lesson. 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 now that I've talked about the fundamentals of DNS from an abstract perspective, I want to bring this back to an AWS focus and talk about Route 53, which is AWS's managed DNS product.

Okay, let's jump in and get started with a high level product basics, and then I'll talk about the architecture. Route 53 provides two main services. First, it's a service in AWS, which allows you to register domains. And second, it can host zone files for you on managed name servers, which it provides. Now Route 53 is a global service with a single database. It's one of very few AWS services which operates as a single global service. And as such, you don't need to pick a region when using it from the console UI. The data that Route 53 stores or manages is distributed globally as a single set and it's replicated between regions. And so it's a globally resilient service. Route 53 can tolerate the failure of one or more regions and continue to operate without any problems. Now it's one of the most important AWS products. It needs to be able to scale, stay highly performant, whilst remaining reliable, and continue working through failure.

So let's look at exactly how Route 53 is architected and exactly what it does to provide these two main services. So the first service that I mentioned at the start of this lesson is that Route 53 allows you to register domains. And to do that, it has relationships with all of the major domain registries. Remember from the last lesson that these are the companies which manage the top level domains. They've been delegated this ability by IANA who manage the root zone for DNS. Now these registries, each manage one specific zone. One of them manages the .com zone and/or the .net zone, and another the .io zone, and so on.

In the next lesson, I'll be demoing how to register a domain that I'll be using for the course scenario. And that domain will be a .org domain. And so one of these relationships is with the .org registry, an organization called PIR. Now, when a domain is registered, a few things happen. First, Route 53 checks with the registry for that top level domain if the domain is available. For this example to keep it simple, let's just assume it is. Then Route 53 creates a zone file for the domain being registered. And remember a zone file is just a database which contains all of the DNS information for a particular domain. In this case, animals4life.org. As well as creating the zone file, Route 53 also allocates name service for this zone. So these are servers which Route 53 creates and manages which are distributed globally and there are generally four of these for one individual zone.

So it takes this zone file that it's created. And this is known as a hosted zone, using Route 53 terminology, and it puts that zone file onto these four managed name servers. And then as part of registering the domain it communicates with the .org registry. And this is PIR in this case, and liaising with that registry, it adds these name server records into the zone file for the .org top level domain. And the way that it does this is it uses name server records. So these name server records are how PIR delegate the admin of the domain tools. By adding the name server records to the org zone, they indicate that our four name servers are all authoritative for the domain. And that's how a domain is registered using Route 53.

It's not a complicated process when you simplify it right down. It's simply the process of creating a zone file, creating a number of managed name servers, putting that zone file on those servers, and then liaising with the registry for the top level domain, and getting a name server records added to the top level domain zone, which point back at these servers. Remember, DNS is just a system of delegation.

So next, let's quickly take a look at zones inside Route 53. So Route 53 provides DNS zones as well as hosting for those zones. It's basically DNS as a service. So it lets you create a manage zone files. And these zone files are called hosted zones in Route 53 terminology, because they're hosted on AWS managed name servers. So when a hosted zone is created, a number of servers are allocated and linked to that hosted zone. So they're essentially one and the same. From Route 53's perspective, every hosted zone also has a number of allocated managed name servers. Now a hosted zone can be public, which means that the data is accessible on the public internet. The name servers for a public hosted zone live logically in the AWS public zone. And this is accessible anywhere with the public internet connection. So they're part of the public DNS system.

A hosted zone could also be private which means that it's linked to one or more VPCs and only accessible from within those VPCs. And you might use this type of zone if you want to host sensitive DNS records that you don't want to be publicly accessible. A hosted zone hosts DNS records, which I'll be talking about in an upcoming lesson in much more detail because there are many different types of records. Inside Route 53, you'll see records referred to as record sets. Now there is a tiny difference, but for now you can think of them as the same thing.

Okay, so now it's time for a demo. I know that DNS has been a lot of theory. And so I wanted to show you a domain being registered and the domain that will be registered is the domain that I'll be using for the course scenario which is animals4life.org. So when you're ready to see that, go ahead, complete this video, and join me in the next.

Welcome to this lesson where I'm going to be talking about high availability (HA), fault tolerance (FT), and disaster recovery (DR). It's essential that you understand all three of these to be an effective solutions architect and I want to make sure that you understand all of them correctly. Many of the best architects and consultants that I've worked with have misunderstood exactly what HA and FT mean. The best outcome of this misunderstanding is that you waste business funds and put a project at risk. Worst case, you can literally put lives at risk. So, let's jump in and get started and I promise to keep it as brief as possible, but this really is something you need to fully understand.

Let's start with high availability. This is a term that most people think that they understand. Formally, the definition is that high availability aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period and I've highlighted the key parts of that definition. Most students that I initially teach have an assumption that making a system highly available means ensuring that the system never fails or that the user of a system never experiences any outages and that is not true. HA isn't aiming to stop failure, and it definitely doesn't mean that customers won't experience outages. A highly available system is one designed to be online and providing services as often as possible. It's a system designed so that when it fails, its components can be replaced or fixed as quickly as possible, often using automation to bring systems back into service. High availability is not about the user experience. If a system fails and a component is replaced and that disrupts service for a few seconds, that's okay. It's still highly available. High availability is about maximizing a system's online time and that's it.

Let me give you an example. Let's say we have a system which has a customer, Winnie. Winnie is a data scientist and uses a bespoke application to identify complex data trends. Now, this application runs on a single server, let's say inside AWS. The application probably has other users in addition to Winnie. It's an important application to the business. If it's down, the staff can't work. If they can't work, they don't generate value to the business and of course, this costs the business money. If we have a failure, it means that the system is now suffering an outage, it's not available. System availability is generally expressed in the form of a percentage of uptime. So we might have 99.9 or three nines and this means that we can only have 8.77 hours of downtime per year. Imagine only being able to take a system down for 8.77 hours a year, that's less than one hour per month. It gets worse though, some systems need even higher levels of availability. We've got 99.999% availability or five nines and this only allows for 5.26 minutes per year of downtime. That means for all outages during a year, you have 5.26 minutes. That includes identifying that there's an outage, identifying the cause, devising a solution, and implementing a fix. An outage in this context is defined as something which impacts that server, so impacts your users.

Now, fixing Winnie's application quickly can be done by swapping out the compute resource, probably a virtual server. Rather than using time to diagnose the issue, if you have a process ready to replace it, it can be fixed quickly and probably in an automated way, or you might improve this further by having two servers online constantly, one active and one standby. In the event of a failure, customers would move to the standby server with very close to zero downtime. But, and this is a key factor about high availability, when they migrate from the active server to the standby server, they might have to re-login or might have some small disruption. For high availability, user disruption, while not being ideal, is okay. It can happen because high availability is just about minimizing any outages.

Now, this might explain it a little better. This is a real-world example of something which has high availability built in. It's a four by four. If you were driving in the desert with a normal urban-grade car and it got a flat tire, would you have a spare? Would you have the tools ready to repair it as quickly as possible? In a desert, an outage or delay could have major impacts. It's risky and it could impact getting to your destination. So an example of high availability is to carry a spare wheel and the tools required to replace it. You would of course, need to spend time changing the tire, which is a disruption, but it could be done and it minimizes the time that you're out of action. If you don't have a spare tire, then you'd need to call for assistance, which would substantially increase the time you're out of action. So, high availability is about keeping a system operational. It's about fast or automatic recovery of issues. It's not about preventing user disruption. While that's a bonus, a highly available system can still have disruption to your user base when there is a failure.

Now, high availability has costs required to implement it. It needs some design decisions to be made in advance and it requires a certain level of automation. Sometimes, high availability needs redundant servers or redundant infrastructure to be in place ready to switch customers over to in the event of a disaster to minimize downtime.

Now, let's take this a step further and talk about fault tolerance and how it differs from high availability. When most people think of high availability, they're actually mixing it up with fault tolerance. Fault tolerance in some ways is very similar to high availability, but it is much more. Fault tolerance is defined as the property that enables a system to continue operating properly in the event of a failure of some of its components, so one or more faults within the system. Fault tolerance means that if a system has faults, and this could be one fault or multiple faults, then it should continue to operate properly, even while those faults are present and being fixed. It means it has to continue operating through a failure without impacting customers.

Imagine a scenario where we have somebody injured, so we've got Dr. Abbie and she's been told that she has an urgent case of an injured patient and we'll call this patient, Mike. Mike has been rushed to the hospital after injuring himself running. He's currently being prepped for a surgical procedure and is in the operating room and currently under general anesthetic. While he's unconscious, he's being monitored and this monitoring system indicates when to reduce or increase the levels of anesthetic that Mike gets. It's critical that this server is not to be interrupted ever. The system uses underlying infrastructure on-premises at the hospital. Now, in the event of a system failure, if it was just a highly available system, the server could be replaced or another server could be included in an active standby architecture. In either case, the swap between the servers would cause a system error, a disruption. However quick the fix, however small that disruption, in certain situations like this, any disruption can be life-threatening. This is an example of a situation where high availability isn't enough. Fault tolerance systems are designed to work through failure with no disruption. In this example, we might have the system's monitor communicating with two servers at the same time in an active, active configuration. The monitor is connected to both servers all of the time. So this is not just a simple fail-over configuration. If a server failed, it would drop down to just communicating with the remaining server and as long as one server remains active, the system is fully functional. Now, we could take this further adding a second monitoring system, itself with connections to both servers. That way, one monitor can fail, one server can fail and still the service would continue uninterrupted. We could even eliminate the human dependency in the system and add an extra surgeon, Dr. Abbie's twin.

Most people think that HA means operating through failure, it's not. HA is just about maximizing uptime. Fault tolerance is what means to operate through failure. Fault tolerance can be expensive because it's much more complex to implement versus high availability. High availability can be accomplished by having spare equipment, so standby, physical or virtual components. As long as you automate things and have these spare components ready to go, you can minimize outages. With fault tolerance, it's about more than that. You first need to minimize outages, which is the same as HA, but then you also need to design the system to be able to tolerate the failure, which means levels of redundancy and system components, which can route traffic and sessions around any failed components.

Now remember the example I used for high availability, the four by four in the desert. There are situations where we can't pull over to the side of the road and change a component. An example of this is a plane, which is in the air. A plane needs to operate through systems failure, so through an engine failure, for example. If an engine fails, the plane can't simply stop and effect repairs. So, a plane comes with more engines than it needs. It comes with duplicate electronic systems and duplicate hydraulic systems, so that when it has a problem, it just carries on running until it can safely land and effect repairs. AWS is no exception to this. Systems can be designed to only maximize uptime, which is high availability, or they can be designed for mission or life critical situations and so, designed to operate through that failure, which is fault tolerance.

As a solutions architect, you need to understand what your customer requires. A customer might say that they need HA or fault tolerance while not understanding the difference. Fault tolerance is harder to design, harder to implement and costs much more. Implementing fault tolerance when you really needed high availability simply means you're wasting money. It costs more, and it takes longer to implement. But the reverse, implementing high availability when you need fault tolerance, means that you're potentially putting life at risk. A highly available plane is less than ideal. Understand the difference, if you don't, it can be disastrous.

So, let's move on to the final concept, which is disaster recovery. The definition of disaster recovery is a set of policies, tools, and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. So, while high availability and fault tolerance are about designing systems to cope or operate through disaster, disaster recovery is about what to plan for and do when disaster occurs, which knocks out a system. So, if high availability and fault tolerance don't work, what then? What if your building catches fire, is flooded or explodes? Disaster recovery is a multiple-stage set of processes. So given a disaster, it's about what happens before, so the pre-planning and what happens afterwards, the DR process itself.

The worst time for any business is recovering in the event of a major disaster. In that type of environment, bad decisions are made, decisions based on shock, lack of sleep, and fear of how to recover. So, a good set of DR processes need to preplan for everything in advance. Build a set of processes and documentation, plan for staffing and physical issues when a disaster happens. If you have a business premises with some staff, then part of a good DR plan might be to have a standby premises ready and this standby premises can be used in the event of a disaster. That way, done in advance, your staff unaffected by the disaster, know exactly where to go. You might need space for IT systems or you might use a cloud platform, such as AWS as a backup location, but in any case, you need the idea of a backup premises or a backup location that's ready to go in the event of a disaster.

If you have local infrastructure, then make sure you have resilience. Make sure you have plans in place and ready during a disaster. This might be extra hardware sitting at the backup site ready to go, or it might be virtual machines or instances operating in a cloud environment ready when you need them. A good DR plan means taking regular backups, so this is essential. But the worst thing you can do is to store these backups at the same site as your systems, it's dangerous. If your main site is damaged, your primary data and your backups are damaged at the same time and that's a huge problem. You need to have plans in place for offsite backup storage. So, in the event of a disaster, the backups can be restored at the standby location. So, have the backups of your primary data offsite and ready to go and make sure that all of the staff know the location and the access requirements for these backups.

Effective DR planning isn't just about the tech though, it's about knowledge. Make sure that you have copies of all your processes available. All your logins to key systems need to be available for the staff to use when they're at this standby site. Do this in advance and it won't be a chaotic process when an issue inevitably occurs. Ideally, you want to run periodic DR testing to make sure that you have everything you need and then if you identify anything missing, you can refine your processes and run the test again. If high availability is a four-by-four, if fault tolerance are the resilient systems on large planes, then effective DR processes are pilot or passenger ejection systems. DR is designed to keep the crucial and non-replaceable parts of your system safe, so that when a disaster occurs, you don't lose anything irreplaceable and can rebuild after the disaster. Historically, disaster recovery was very manual. Because of cloud and automation, DR can now be largely automated, reducing the time for recovery and the potential for any errors.

As you go through the course, I'm going to help you understand how to implement high availability and fault tolerance systems in AWS using AWS products and services. So, you need to understand both of these terms really well and disaster recovery. So in summary, high availability is about minimizing any outages, so maximizing system availability. Fault tolerance extends this, building systems which operate through faults and failures. Don't confuse the two. Fault tolerance is much more complex and expensive. It takes a lot more time and effort to implement and manage. I'll help you as we go through the course by identifying how to implement systems which are highly available and how to implement systems which are fault tolerant. AWS provides products and services which help with both of those or just help with one or the other and you need to know the difference. Disaster recovery is how we recover. It's what we do when high availability and fault tolerance don't work and AWS also has many systems and features which help with disaster recovery and one of the things that the exam tests will be your knowledge of how quickly you can recover and how best to recover, given the various different products and services and I'll highlight all of this as we go through the course. At this point, that's everything I wanted to cover, so thanks for listening. Go ahead, complete this video and when you're ready, I'll see you in the next.

Welcome back. In this lesson, I'm going to be covering something that will make complete sense by the end of the course. I'm introducing it now because I want you to be thinking about it whenever we're talking about AWS products and services. The topic is the shared responsibility model. The easiest way to explain this is visually, so let's jump in.

Remember earlier in the course when I talked about the various different cloud service models? In each of these models, there were parts of the infrastructure stack that you were responsible for as the customer, and parts of the infrastructure stack that the vendor or provider were responsible for. With IaaS, for example, the company providing the IaaS product, so AWS in the case of EC2, they're responsible for the facilities, the AWS data centers, the infrastructure, so storage and networking, the servers, so EC2 hosts, and the hypervisor that allows physical hardware to be carved up into independent virtual machines. You as the customer manage the operating system, any containers, any run times, the data on the instance, the application, and any ways in which it interfaces with its customers. This is an example of a set of shared responsibilities. Part of the responsibilities lie with the vendor, and part lie with you as the customer.

The AWS shared responsibility model is like that, only applying to the wider cloud platform from a security perspective. It's AWS' way of making sure that it's clear and that you understand fully which elements you manage and which elements it manages. At a high level, AWS are responsible for the security of the cloud. You as a customer are responsible for the security in the cloud. Now let's explore this in a little bit more detail because it will help you throughout the course and definitely for the exam.

Now I've covered the AWS infrastructure at a high level in a previous lesson. AWS provides these to you as a service that you consume. So AWS are responsible for managing the security of the AWS regions, the Availability Zones, and the edge locations. So the hardware and security of the global infrastructure. You have no control over any of that and you don't need to worry about it. It's the "of the cloud" part, and so it's AWS' responsibility. The same holds true for the compute storage databases and networking which AWS also provide to you. AWS manage the security of those components. In addition, any software which assists in those services, AWS manage all of this part of the stack. So the hardware, the regions, the global network, the compute storage database, and networking services, and then any software that is used to provide that service, AWS manage that end-to-end.

If you consume a service from AWS, they handle the provisioning and the security of that thing. So take EC2 as an example. The region and the Availability Zone that the instance run in, that's AWS' responsibility. The compute, the storage, the underlying databases and networking for that service, from a security perspective, that's AWS' responsibility. The software, so the user interface, the hypervisor, that's handled by AWS. Now you accept responsibility for the operating system upwards. What does that include? It means things like the client-side data encryption, integrity and authentication; server-side encryption; network traffic protection. If your application encrypts its data, you manage that. If your server uses SSL certificates, you manage those. If you encrypt server-to-server communications, then you also handle that. You're also responsible for the operating system, networking, and any local firewall configuration. You're responsible for applications, identity and access management to things that you will need to implement, manage and control. And then any customer data. So any data that runs in this stack, you need to manage it, secure it, and ensure that it's backed up.

This might seem like a pretty abstract concept. You might be wondering, does it actually benefit you in the exam? I'd agree with you to a point. When I was doing my AWS studies, I actually didn't spend much time on the shared responsibility model. But what I found is when I sat the exam, I did feel as though it could have benefited me to start learning about it early on when I was first starting my studies. If you keep the shared responsibility in mind as we're going through the various different AWS products, you'll start building up an idea of which elements of that product AWS manage, and which elements you're responsible for. When it comes to deploying an EC2 instance into a VPC or using the Relational Database Service to deploy and manage a database inside a VPC, you need to know which elements of that you manage and which elements AWS manage.

I'll be referring back to this shared responsibility model fairly often as we go through the course, so you build up this overview of which elements you need to worry about and which are managed by AWS. If possible, I would suggest that you either print out the shared responsibility model and put it on your desk as you're studying, or just make sure you've got a copy that you can refer back to. It becomes important to understand it at this high level. I'm not going to use any more of your time on this topic. I just wanted to introduce it. I promise you that I'm not going to be wasting your time by talking about things which don't matter. This will come in handy. This is definitely something that will help you answer some questions.

That's all I wanted to cover for now. It's just a foundation, and I don't want to bore you with too much isolated theory. Try to keep this in mind as you go through the rest of the course. For now, this is the level of detail that you need. That's everything I wanted to cover. Go ahead, complete this lesson. When you're ready, move on to the next.

Welcome back and in this demo lesson you're going to get some experience interacting with CloudWatch. So you're going to create an EC2 instance, you're going to cause that instance to consume some CPU capacity and then you're going to monitor exactly how that looks within CloudWatch. Now to do this in your own environment you'll just need to make sure that you're logged into the general AWS account as the IAM admin user and as always make sure that you have the Northern Virginia region selected which is US-East-1. Once you've got those set correctly then click in the search box at the top and type EC2, find the EC2 service and then just go ahead and open that in a brand new tab.

Now we're going to skip through the instance creation process because you've done that in a previous demo lesson. So just go ahead and click on instances and then Launch Instance. Under Name, I just want you to put CloudWatch Test as the instance name. Then scroll down and then under the Amazon Machine image to use, go ahead and select Amazon Linux. We're going to pick the Amazon Linux 2023 version, so that's the most recent version of this AMI. It should be listed as Free Tier Eligible, so just make sure that's the case. We'll leave the architecture set to 64-bit x86 and scroll down. It should already be set to an instance type which is free tier eligible, in my case t2.micro. We'll be connecting to this instance using ec2 instance connect so we won't be using an SSH key pair. So in this drop down just click and then say proceed without a key pair. We won't need one because we won't be connecting with a local SSH client. Scroll down further still and under Network Settings click on Edit and just make sure that the default VPC is selected. There should only be one in this list but just make sure that it's set as default. Under Subnet we can leave this as No Preference because we don't need to set one. We will need to make sure that Auto Assign Public IP is set to Enable.

Under create security group for the name and for the description just go ahead and type CloudWatch SG so CloudWatch SG for both the security group name and the description now the default for security group rule should be fine because it allows SSH to connect from any source location and that's what we want scroll down further still and we'll be leaving storage as default remember this is set from the AMI that we pick. Now because this is a CloudWatch lesson, we're going to set something a little bit different. So expand Advanced Details and then scroll down and look for Detailed CloudWatch Monitoring. Now this does come at an additional cost, so you've got a couple of options. You can just watch me do this or you can do this demo without Detailed Monitoring enabled. And if you don't enable this, it will be entirely free, but you might need to wait a little bit longer for things to happen in the demo lesson so keep that in mind.

What I'm going to do is I'm going to enable detailed CloudWatch monitoring and if we click on info here we can see some details about exactly what that does and we can also open this in a new tab and explore what additional charges apply if we want to enable it. Now in this case I'm going to enable it you don't have to it's not a huge charge but I think for me demoing this to you it's good that I enable it you don't have to you might just have to wait a little bit longer for things to happen in the demo. Now once all of that set just scroll all the way down to the bottom and go ahead and click launch instance. Now this might take a few minutes to create we're first waiting for this success dialog and once that shows we can go ahead and click on view all instances. Go ahead and click refresh until you see the instance it will start off in a pending state with nothing listed under status check. After a few moments this will change status we'll see that it's in a running state and then we need to wait for this to change to two of two status checks before we continue. So go ahead and pause the video wait for your status check to update and once it does we're good to continue.

Okay so now this has changed to two out of two checks passed and that's good that's what we want so so it should display running on the instant state and then two out of two checks passed under status check. Once this is the case, go ahead and click in the search box at the top and just type CloudWatch, locate the CloudWatch service, and then open that in a brand new tab. This is the CloudWatch console, and it's here where we're going to create a CloudWatch alarm. Now if you see anything about a new UI or new features, you can just go ahead and close down that dialog. Once we're here, go ahead and click on Alarms on the left and then click on all alarms. This will show a list of all the alarms that you've configured within CloudWatch, and currently there aren't any. What we're going to do is to create an alarm. So click on create alarm, and then click on select metric. Once we're on this screen, scroll down, and we're going to be looking for an EC2 metric, because we need to find the CPU utilization metric, which is inside the EC2 namespace. In other words, it comes from the EC2 service. So go ahead and click on EC2, and then we're looking for per instance metrics. So click on per instance metrics, and this will show all of the EC2 instance metrics that we currently have. Now if I scroll through this list, what you'll see is that I have two different instance IDs, because I'm using this account to create all of these demo lessons. In my case, I see previous instances. Now if you're doing this in your account, if you go back to the EC2 Management Console, you can see your instance ID here. Just remember the last four digits of this instance ID, and then go back to the CloudWatch Console. If you have more than one instance listed in CloudWatch, look for the instance ID that ends with the four digits that you just noted down, and then from that list you need to identify CPU utilization. And so I'm going to check the box next to this metric. Now this is the metric that monitors, as the name suggests, CPU utilization on this specific instance ID, which is our CloudWatch test instance. If I scroll up, I'm able to see any data that's already been gathered for this specific instance. And as you can see, it's not a great deal at the moment because we've only just launched this instance. So I'm gonna go ahead and click on Select Metric, and then because we're creating an alarm, it's going to ask us for what metric and conditions we want to evaluate.

So I'm going to scroll down, and under Conditions, I'm going to pick Static, because I want this alarm to go into an alarm state when something happens to the CPU utilization. So I'm going to ask CloudWatch that whenever the CPU utilization is greater or equal to a specific value than to go into an alarm state. So that value is going to be 15%. So whenever the CPU utilization on this EC2 instance is greater or equal to 15%, then this alarm will go into the alarm state. So I'm gonna go ahead and click on Next. Now you can set this up so that if this alarm goes into an alarm state, it can notify you using SNS. Now that's useful if this is in production usage, but in this case we're not using it in production, so I'm going to go ahead and click on remove. Scroll down to the bottom, there's also other things that you could pick, so you could do an auto scaling action, an EC2 action, or a systems manager action. But we're going to be talking about these in much more detail as we move through the course. For now we're going to keep this simple, it's just going to be a basic alarm which goes into an alarm state or not. So click on next and then under alarm name I'm going to put CloudWatch test and then high CPU and you should do the same. So type that, click on next, scroll down to the bottom and create that alarm.

Now initially this alarm state will be insufficient data because CloudWatch hasn't yet gathered enough data on the CPU utilization to generate the state. That's fine because we've we've got another thing that we need to do first. So now move back to the EC2 console and we're going to connect into this instance using EC2 Instance Connect. Remember, that's the web-based way to get access to this instance. So over the top of the CloudWatch Test instance, right click and go to Connect. Make sure that EC2 Instance Connect is selected, so click that tab. You can leave everything as default and click on Connect and that will connect you to this EC2 instance. Now at this point, we need to install an application called stress on this EC2 instance. And stress is an application which will put artificial CPU load onto a system. And that's what we want to do in order to see how CloudWatch reacts. To install stress, we're going to run this command. And this next command will use the yum package manager to install the stress utility. So go ahead and run this command and then clear the screen again. Now the stress command can be run by typing stress and what we're going to do is do a double hyphen help just to get the help for this command. So what we're going to do is we're going to run stress and we're going to specify the number of CPUs to use and we want that number to be the same number of virtual CPUs that this instance has. Now a t2.micro has one virtual CPU and so the command that we need to run is stress space hyphen c space 1 and then space and then we're going to use hyphen t which is the timeout command and this specifies how long we want to run this for. So we're going to specify 3600 so hyphen t and then a space 3600 and this will run the stress for 3600 seconds and that's plenty for us to see how this affects the metrics which are being monitored by CloudWatch.

Now what I want to do before we do that is go back to the CloudWatch console. You might need to refresh if you haven't seen the state update yet. In my case it's already showing as okay. So this means that it's now got access to some data. So click on this alarm and you'll be able to see that currently the CPU started off at very low levels and then it spiked up and potentially in my case that's because we've just installed some software. But note here this red line which indicates the alarm level for this alarm. So if the CPU utilisation, which is in blue, exceeds this red line then this alarm will move from OK to ALARM. And that's what we want to simulate. So go back to the instance and press Enter to run this stress command. And that's going to begin placing high levels of CPU load on this instance and what we'll see over the next few minutes is CloudWatch will detect this additional CPU load and it will cause this alarm to go from OK into an alarm state. So move back to the CloudWatch console and just keep hitting refresh until you see a change in the alarm state. Again this might take a few minutes. What I suggest you do is pause the video and wait for your alarm to change away from OK and then you're good to continue.

Now in my case this only took a few minutes and as you can see the CPU load reported by this alarm in CloudWatch went from this value here and spiked all the way up to this value which is well above the 15% of the alarm threshold. So the alarm changed from OK to IN alarm based on this excessive CPU and if we keep monitoring this over time you'll see that this trend continues because this CPU is under extremely high load because it's been artificially simulated using the stress utility. Now if we go back to this EC2 instance and press ctrl and C at the same time this will exit out of the stress utility and at this point the artificial CPU load has been removed and the instance will gradually move back down to its normal levels which is very close to zero. So again what you'll see is this may take a few minutes to be reflected inside CloudWatch. So keep refreshing this once you've cancelled the stress utility and wait for the reported CPU utilization to move back down below the alarm value. Again that might take a few minutes so go ahead and pause the video and wait for this blue line to move back under the red line and once it does you should see that the alarm state changes from in alarm to OK again.

In my case it took a few minutes for the blue line to move below the alarm threshold and then a few more minutes afterwards for the alarm to change from in alarm to OK. But as you can see at this point that's exactly what's happened once the CPU usage goes below the configured threshold value then the alarm changes back to an OK state. And at this point that's everything that I wanted to cover in this demo lesson on CloudWatch. CloudWatch is a topic that I'm going to be going into much more detail later on in the course. This has just been a really brief introduction to the product and how it interacts with EC2. Now at this point the only thing left is to clear up the account and put it back into the same state as it was at the start of this lesson. So to do that go ahead and click on All Alarms, select the CloudWatch Test High CPU Alarm that you created, click on the actions dropdown, select delete, and then confirm that deletion. Then go back to EC2, go to the instances overview, right click on the CloudWatch test instance, making sure that it is the correct instance, so CloudWatch test, and then select terminate instance and confirm that termination. Now that's going to move through a few states, it will start with shutting down, and you need to wait until that instance is in a terminated state. Go ahead and pause the video and wait for your instance to change into terminated.

Okay so once your instance has terminated on the menu on the left scroll down go to security groups select the CloudWatch SG security group making sure that you do pick the correct one so CloudWatch SG click on actions scroll down delete security groups and click on delete and at that point the account is back in the same state as it was at the start of this demo lesson. So thanks for watching this video. I hope you gained some experience of the CloudWatch product and again we're going to be talking about it in much more detail later in the course. At this point though go ahead and complete this video 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 CloudWatch, a core product inside AWS used for operational management and monitoring. CloudWatch performs three main jobs: it collects and manages operational data, monitors metrics, and performs actions based on these metrics.

CloudWatch collects and manages operational data generated by an environment, including performance details, nominal operations, and logging data. It can be considered three products in one: CloudWatch, CloudWatch Logs, and CloudWatch Events.

Firstly, CloudWatch allows the collection, monitoring, and actions based on metrics related to AWS products, applications, or on-premises systems. Metrics include data such as CPU utilization, disk space usage, or website traffic. CloudWatch can gather metrics from AWS, on-premises environments, or other cloud platforms using a public internet connection. Some metrics are gathered natively by CloudWatch, while others require the CloudWatch Agent, especially for monitoring non-AWS environments or specific processes on AWS instances.

CloudWatch provides a user interface, command line interface, or API to access and manage this data. The second part of CloudWatch, CloudWatch Logs, handles the collection, monitoring, and actions based on logging data from various sources like Windows event logs, web server logs, and more. For custom logs or non-AWS systems, the CloudWatch Agent is also needed.

The third part is CloudWatch Events, which functions as an event hub. It generates events based on AWS service actions (e.g., starting or stopping an EC2 instance) and can also create scheduled events for specific times or days.

The core concepts of CloudWatch include namespaces, metrics, datapoints, and dimensions. A namespace is a container for monitoring data, helping to organize and separate different areas of data. AWS uses a reserved namespace format (e.g., AWS/EC2 for EC2 metrics), while you can create custom namespaces for your data. Metrics are collections of related data points in a time-ordered structure, such as CPU utilization. Each datapoint includes a timestamp and value. Dimensions, which are name-value pairs, help separate and identify data within a metric, like distinguishing datapoints from different EC2 instances.

CloudWatch also uses alarms to take actions based on metrics. Alarms can be in an OK state (indicating no issues), an ALARM state (indicating a problem), or an INSUFFICIENT_DATA state (indicating not enough data to assess). Actions could include notifications or more complex responses. You’ve already seen an example of this with the billing alarm created at the start of the course.

In the next demo lesson, we’ll provision an EC2 instance, let it run, and then create an alarm to monitor CPU usage, providing practical exposure to how CloudWatch works.

Thanks for watching. Complete this video and join me in the demo when you’re ready.

Welcome back. In this demo lesson, I want to quickly demonstrate how to use CloudFormation to create some simple resources. So before we start, just make sure you're logged in to the general AWS account and that you've got the Northern Virginia region selected. Once you've got that, just move across to the CloudFormation console.

So this is the CloudFormation console, and as I discussed in the previous lesson, it works around the concepts of stacks and templates. To get started with CloudFormation, we need to create a stack. When you create a stack, you can use a sample template, and there are lots of different sample templates that AWS makes available. You can create a template in the Designer or upload a ready-made template, and that's what I'm going to do. Now, I've provided a template for you to use, linked to this lesson. So go ahead and click on that link to download the sample template file.

Once you've downloaded it, you'll need to select 'Upload a template file' and then choose 'File'. Locate the template file that you just downloaded; it should be called 'ec2instance.yaml'. Select that and click on 'Open'. Whenever you upload a template to CloudFormation, it's actually uploading the template directly to an S3 bucket that it creates automatically. This is why, when you're using AWS, you may notice lots of buckets with the prefix CF that get created in a region automatically. You can always go ahead and delete these if you want to keep things tidy, but that's where they come from.

Now, before we upload this, I want to move across to my code editor and step through exactly what this template does. The template uses three of the main components that I've talked about previously. The first one is parameters. There are two parameters for the template: latest AMI and SSH and web location. Let's quickly talk about the latest AMI ID because this is an important one. The type of this parameter is a special type that's actually a really useful feature. What this allows us to do is rather than having to explicitly provide an AMI ID, we can say that we want the latest AMI for a given distribution. In this case, I'm asking for the latest AMI ID for Amazon Linux 2023 in whichever region you apply this template in. By using this style of parameter, the latest AMI ID gets set to the AMI of the latest version of this operating system.

The final parameter that this template uses is SSH and web location, which is where we can just specify an IP address range that we want to be able to access this EC2 instance. So that's parameters—nothing special, and you'll get more exposure to these as we go through the course. Now we've also got outputs, and outputs are things that are set when the template has been applied successfully. When a stack creates, when it finishes that process, it will have some outputs. I've created outputs so that we get the instance ID, the availability zone that the instance uses—remember EC2 is an AZ service. It’ll also provide the public DNS name for the instance, as well as the public IP address. The way that it sets those is by using what's known as a CloudFormation function.

So this is ref, and this is going to reference another part of the CloudFormation template. In this case, it's going to reference a logical resource, the EC2 instance resource. Now, get attribute or get att is another function that's a more capable version of ref. With get attribute, you still refer to another thing inside the template, but you can pick from different data that that thing generates. An EC2 instance, by default, the default thing that you can reference is the instance ID, but it also provides additional information: which availability zone it's in, its DNS name, and its public IP. I’ll make sure to include a link in the lesson that details all of the resources that CloudFormation can create, as well as all of the outputs that they generate.

The main component of course of this template is the resources component. It creates a number of resources. The bottom two, you don’t have to worry about for now. I’ve included them so I can demonstrate the Session Manager capability of AWS. I'll be talking about that much more later in the course, but what I'm doing is creating an instance role and an instance role profile. You won't know what these are yet, but I’ll be talking about them later in the course. For now, just ignore them. The main two components that we're creating are an EC2 instance and a security group for that instance.

We’re creating a security group that allows two things into this instance: port 22, which is SSH, and port 80, which is HTTP. So it’s allowing two different types of traffic into whatever the security group is attached to. Then we’re creating the EC2 instance itself. We’ve got the EC2 instance, which is a logical resource, the type being AWS::EC2::Instance, and then the properties for that logical resource, such as the configuration for the instance. We’re setting the type and size of the instance, t2.micro, which will keep it inside the free tier. We’re setting the AMI image ID to use, and it's referencing the parameter, and if you recall, that automatically sets the latest AMI ID. We’re setting the security group, which is referencing the logical resource that we create below, so it creates this security group and then uses it on the instance. Finally, we’re setting the instance profile. Now, that’s related to these two things that I’m not talking about at the bottom. It just sets the instance profile, so it gives us the permission to use Session Manager, which I’ll demonstrate shortly after we implement this.

There’s nothing too complex about that, and I promise you by the end of the course, and as you get more exposure to CloudFormation, this will make a lot more sense. For now, I just want to use it to illustrate the power of CloudFormation. So I’m going to move back to the console. Before I do this, I’m going to go to services and just open EC2 in a new tab. Once you’ve done that, return to CloudFormation and click on next. We’ll need to name the stack. I’m just going to call it CFN demo one for CloudFormation demo one. Here’s how the parameters are presented to us in the UI. The latest AMI ID is set by default to this value because, if we look at the parameters, it’s got this default value for this parameter. Then SSH and web location also has a default value which is set in the template, and that’s why it’s set in the UI. Leave these two values as default. Once you’ve done that, click on next.

I’ll be talking more about all of these advanced options later on in the course when I talk about CloudFormation. For now, we’re not going to use any of these, so click on next. On this screen, we need to scroll down to the bottom and check this capabilities box. For certain resources that you can create within CloudFormation, CloudFormation views them as high-risk. In this case, we're creating an identity, an IAM role. Don't worry, I'll be talking a lot more about what an IAM role is in the next section of the course. Because it's an identity, because it's changing something that provides access to AWS, CloudFormation wants us to explicitly acknowledge that we’re to create this resource. So it’s prompting us for this capability to create this resource. Check this box, it’s fine, and then click on submit. The stack creation process will begin and the status will show create in progress.

This process might take a few minutes. You’re able to click on refresh here, so this icon on the top right, and this will refresh the list of events. As CloudFormation is creating each physical resource that matches the logical resources in the template, it’s going to create a new event. For each resource, you’ll see a create in progress event when the creation process starts, and then you’ll see another one create complete when it creates successfully. If there are any errors in the template, you might see red text, which will tell you the nature of that error. But because this is a CloudFormation template that I’ve created, there’ll be no errors. After a number of minutes, the stack itself will move from Create in Progress to Create Complete.

I refreshed a couple more times and we can see that the Session Manager instance profiles moved into the Create Complete status and straight after that it started to create the EC2 instance. We’ve got this additional event line saying Create in Progress, and the resource creation has been initiated. We’re almost at the end of the process now; the EC2 instance is going to be the last thing that the stack will create. At this point, just go ahead and pause the video and wait until both the EC2 instance and the stack itself move into Create Complete. Once both of those move into Create Complete, then you can resume the video and we’re good to continue.

Another refresh, and we can see that the EC2 instance has now moved into a Create Complete status. Another refresh and the entire stack, CFN demo 1, is now in the create complete state, which means that the creation process has been completed and for every logical resource in the template, it’s created a physical resource. I can click on the outputs tab and see a list of all the outputs that are generated from the stack. You’ll note how they perfectly match the outputs that are listed inside the template. We’ve got instance ID, AZ, public DNS, and public IP. These are exactly the same as the outputs listed inside the CloudFormation template. You’ll see that these have corresponding values: the instance ID, the public DNS of the instance, and the public IP version 4 address of the instance.

If I click on the resources tab, we’ll be able to see a list of the logical resources defined in the template, along with their corresponding physical resource IDs. For the EC2 instance logical resource, it’s created an instance with this ID. If you click on this physical ID, it will take you to the actual resource inside AWS, in this case, the EC2 instance. Now, before we look at this instance, I’m going to click back on CloudFormation and just click on the stacks clickable link at the top there. Note how I’ve got one stack, which is CFN demo one. I could actually go ahead and click on create stack and create stack with new resources and apply the same template again, and it would create another EC2 instance. That’s one of the powerful features of CloudFormation. You can use the same template and apply it multiple times to create the same set of consistent infrastructure.

I could also take this template because it's portable, and because it automatically selects the AMI to use, I could apply it in a different region and it would have the same effect. But I’m not going to do that. I’m going to keep things simple for now and move back to the EC2 tab. Now, the one thing I want to demonstrate before I finish up with this lesson is Session Manager. This is an alternative to having to use the key pair and SSH to connect to the instance. What I’m able to do is right-click and hit Connect, and instead of using a standalone SSH client, I can select to use Session Manager. I’ll select that and hit Connect, and that will open a new tab and connect me to this instance without having to use that key pair.

Now, it connects me using a different shell than I'm used to, so if I type bash, which is the shell that you normally have when you log into an EC2 instance, that should look familiar. I’m able to run normal Linux commands like df -k to list all of the different volumes on the server, or dmesg to get a list of informational outputs for the server. This particular one does need admin permission, so I’ll need to rerun this with sudo and then dmesg. These are all commands that I could run in just the same way if I was connected to the instance using an SSH client and the key pair. Session Manager is just a better way to do it, but it requires certain permissions to be given to the instance. That’s done with an instance role that I’ll be talking all about later on in the course. That is the reason why my CloudFormation template has these two logical resources, because these give the instance the permission to be able to be connected to using Session Manager. It makes it a lot easier to manage EC2 instances.

So that’s been a demo of how easy it is to create an EC2 instance using CloudFormation. Throughout the course, we'll be using more and more complex examples of CloudFormation. I’ll be using that to show you how powerful the tool is. For now, it’s a really simple example, but it should show how much quicker it is to create this instance using CloudFormation than it was to do it manually. To finish up this lesson, I’m going to move back to the CloudFormation console. I’m going to select this CloudFormation stack and click on Delete. I need to confirm that I want to do this because it’s telling me that deleting this stack will delete all of the stack resources.

What happens when I do this is that the stack deletes all of the logical resources that it has, and then it deletes all of the corresponding physical resources. This is another benefit of CloudFormation in that it cleans up after itself. If you create a stack and that creates resources, when you delete that stack, it cleans up by deleting those resources. So if I click on Delete Stack Now, which I will do, it starts a delete process, and that’s going to go ahead and remove the EC2 instance that it created. If I select this stack now, I can watch it do that. I can click on Events, and it will tell me exactly what it’s doing. It’s starting off by deleting the EC2 instance. If I move back to the EC2 console and just hit Refresh, we can see how the instance state has moved from running to shutting down.

Eventually, once the shutdown is completed, it will terminate that instance. It’ll delete the storage, it will stop using the CPU and memory resources. At that point, the account won’t have any more charges. It wouldn’t have done anyway because this demo has been completely within the free tier allocation because I was using a t2.micro instance. But there we go. We can see the instance state has now moved to terminated. Go back to CloudFormation and just refresh this. We’ll see that it’s completed the deletion of all the other resources and then finished off by deleting the stack itself. So that’s the demonstration of CloudFormation. To reaffirm the benefits, it allows us to do automated, consistent provisioning. We can apply the same template and always get the same results. It’s completely automated, repeatable, and portable. Well-designed templates can be used in any AWS region. It’s just a tool that really does allow us to manage infrastructure effectively inside AWS.

Welcome back, and in this lesson, I want to talk about AWS CloudFormation. I'm going to be brief because learning CloudFormation is something which will happen throughout the course, as we'll be using it to automate certain things. Before we dive in, I'll introduce the concepts you'll need and give you a chance to experience a simple practical example.

CloudFormation is a tool which lets you create, update, and delete infrastructure in AWS in a consistent and repeatable way using templates. Rather than creating and updating resources manually, you create a template, and CloudFormation will do the rest on your behalf.

At its base, CloudFormation uses templates. You can use a template to create AWS infrastructure using CloudFormation. You can also update a template and reapply it, which causes CloudFormation to update the infrastructure, and eventually, you can use CloudFormation to delete that same infrastructure. A CloudFormation template is written either in YAML or JSON. Depending on your experience, you might be familiar with one or both of these. If you haven't touched YAML or JSON before, don't worry. They achieve the same thing, and it's easy to convert between them. You might get to pick which one to use when writing templates, or your business might have a preference. It's mostly a matter of personal preference. Most people in the AWS space like one and dislike the other, though very few people like both. I am one of those who likes both. I started my AWS career using JSON but have come to appreciate the extra functionality that YAML offers. However, YAML can be easier to make mistakes with because it uses white spaces to indicate which parts belong to which other parts. Since spaces are not always visible, it can be a problem for less experienced engineers or architects. If I have to pick one, I'll use YAML. So for the rest of this lesson, I'll focus on YAML.

I want to quickly step through what makes a template, the components of a template, and then discuss the architecture of CloudFormation before moving on to a demo. All templates have a list of resources, at least one. The resources section of a CloudFormation template tells CloudFormation what to do. If resources are added, CloudFormation creates them. If resources are updated, CloudFormation updates them. If resources are removed from a template and that template is reapplied, then physical resources are removed. The resources section of a template is the only mandatory part of a CloudFormation template, which makes sense because without resources, the template wouldn't do anything. The simple template that we'll use in the demo lesson immediately following this one has resources defined in it, and we'll step through those and evaluate exactly what they do.

Next is the description section. This is a free text field that lets the author of the template add a description, as the name suggests. Generally, you would use this to provide details about what the template does, what resources get changed, and the cost of the template. Anything that you want users to know can be included in the description. The only restriction to be aware of is if you have both a description and an AWSTemplateFormatVersion, then the description needs to immediately follow the template format version. The template format version isn't mandatory, but if you use both, the description must directly follow the template format version. This has been used as a trick question in many AWS exams, so it pays to be aware of this restriction. The template format version allows AWS to extend standards over time. If it's omitted, the value is assumed.

The metadata in the template is the next part I want to discuss. It has many functions, including some advanced ones. For example, metadata can control how different elements in the CloudFormation template are presented through the console UI. You can specify groupings, control the order, and add descriptions and labels, which helps in managing how the UI presents the template. Generally, the bigger your template and the wider the audience, the more likely it is to have a metadata section. Metadata serves other purposes, which I'll cover later in the course.

The parameters section of a template allows you to add fields that prompt the user for more information. When applying the template from the console UI, you'll see boxes to type in or select from dropdowns. This can be used to specify things like the size of the instance to create, the name of something, or the number of availability zones to use. Parameters can have settings for valid entries and default values. You'll gain more experience with this as we progress through the course and use CloudFormation templates.

The next section is mappings, which is another optional section of the CloudFormation template and something we won't use as much, especially when starting with CloudFormation. It allows you to create lookup tables. For example, you can create a mappings table called RegionAndInstanceTypeToAMI, which selects a specific Amazon Machine Image based on the region and environment type (e.g., test or prod). This is something you'll get experience with as the course continues, but I wanted to introduce it at this point.

Next, let's talk about conditions. Conditions allow decision-making in the template, enabling certain things to occur only if a condition is met. Using conditions involves a two-step process. Step one is to create the condition. For instance, if a parameter is equal to "prod" (i.e., if the template is being used to create prod resources), then you create a condition called CreateProdResources. If the parameter "environment type" is set to "prod," the condition CreateProdResources will be true. Step two is using this condition within resources in the CloudFormation template. For example, a resource called Prodcatgifserver will only be created if the condition CreateProdResources is true. This will only be true if the "environment type" parameter is set to "prod" rather than "test." If it's set to "test," that resource won't be created.

Finally, outputs are a way for the template to present outputs based on what's being created, updated, or deleted once the template is finished. For example, outputs might return the instance ID of an EC2 instance that's been created, or if the template creates a WordPress blog, it could return the admin or setup address for that blog.

So, how exactly does CloudFormation use templates? CloudFormation starts with a template. A template contains resources and other elements you'll become familiar with as we use CloudFormation more. Let's take a simple example—a template that creates an EC2 instance. Resources inside a CloudFormation template are called logical resources. In this case, the logical resource is called "instance," with a type of AWS::EC2::Instance. The type tells CloudFormation what to create. Logical resources generally also have properties that CloudFormation uses to configure the resources in a specific way.

When you provide a template to CloudFormation, it creates a stack, which contains all the logical resources defined in the template. A stack is a living and active representation of a template. One template could create one stack, or several stacks, or anywhere in between. A stack is created when you tell CloudFormation to do something with that template.

For any logical resources in the stack, CloudFormation makes a corresponding physical resource in your AWS account. For example, if the stack contains a logical resource called "instance," which defines an EC2 instance, the physical resource is the actual EC2 instance created by CloudFormation. It's CloudFormation's job to keep the logical and physical resources in sync. When you use a template to create a stack, CloudFormation scans the template, creates a stack with logical resources, and then creates matching physical resources.

You can also update a template and use it to update the stack. When you do this, the stack's logical resources will change—new ones may be added, existing ones updated or deleted. CloudFormation performs the same actions on the physical resources, adding, updating, or removing them as necessary. If you delete a stack, its logical resources are deleted, leading CloudFormation to delete the matching physical resources.

CloudFormation is a powerful tool that allows you to automate infrastructure. For instance, if you host WordPress blogs, you can use one template to create multiple deployments rather than setting up each site individually. CloudFormation can also be part of change management, allowing you to store templates in source code repositories, make changes, get approval, and apply them as needed. It can also be used for one-off deployments.

Throughout this course, I'll be using CloudFormation to help you implement various things in demo lessons. If a demo lesson requires certain products to function, I might provide a CloudFormation template to set up the base infrastructure. Alternatively, you can use the template to implement the entire demo end-to-end. CloudFormation is super powerful, and you'll get plenty of exposure to it throughout the course.

Now, that's all the theory I wanted to cover. The next lesson will be a demo where you'll use CloudFormation to create an EC2 instance. Remember in the EC2 demo lesson, where you created an EC2 instance? In the next demo lesson, you'll create a similar EC2 instance using CloudFormation, demonstrating how much quicker and easier it is to automate infrastructure tasks with CloudFormation. So go ahead, complete this video, and when you're ready, join me in the next lesson where we'll demo CloudFormation.

Welcome back and in this demo lesson, I just want you to get some experience working with S3.

In this demo lesson you're going to create an S3 bucket which is going to be used for a campaign within the Animals for Life organization.

You're going to get the chance to create the bucket, interact with the bucket, upload some objects to that bucket and then finally interact with those objects.

Now to get started you'll need to make sure that you're logged in to the IAM

admin user within the general AWS account. By this point in the course you

should have a general account and a production account and you need to make

sure that you're logged in to the general AWS account. As always make sure

that you're also using the Northern Virginia region which is US-East-1.

Now assuming that you do have that configuration next you need to move to

the S3 console and there are a couple of ways that you can do that you can type

S3 into this find services box if you've previously used the service it will be

listed under the recently visited services and then finally at the top

here you can click on the services drop-down and either type S3 into the

all services box here or locate it in the list of services and click to move

to the S3 console so I'm going to go ahead and type S3 and then click to move

to the console. Now when you first arrive at the S3 console you'll be presented

with a list of buckets within this AWS account. I want to draw specific

attention to the fact that with S3 you do not have to choose a region with the

region drop-down. When you create buckets within S3 you have to pick the region

that that bucket is created in but because S3 uses a global namespace you

don't have to select a region when using the console. So on this list you will see

any buckets in any regions within this one single AWS account. You don't have to

pick the region in advance. So let's go ahead and create an S3 bucket and to do

that logically enough we click on create bucket. Now to create a bucket you need

to specify a name and we're creating this bucket for a koala campaign for the

Animals for Life organization. So we're going to start with Koala Campaign.

Now because bucket names do need to be unique we can't just leave it at Koala Campaign

we need to add some random numbers at the end. This is just to make sure that

the name that you pick is different than the name that I pick and different than

the name that every other student uses. So just put some numbers after this name.

I'm going to pick 1-3-3-3-3-3-7. Now there are some rules around bucket

naming names need to be between 3 and 63 characters they can only consist of

lowercase letters numbers dots and hyphens they need to begin and end with a

letter or number they can't be formatted like an IP address and they can't begin

with X and N and of course they need to be entirely unique now there are some

specific restrictions or specific rules for naming buckets if you want to use

certain S3 features. Later in the course I'll be talking about static website

hosting within S3 and I'll be showing you how you can use a custom domain name

with an S3 bucket so you can get a domain name to host for example a blog

or a static website and you can use S3 to host that website and if you want to

do that then you need to name the bucket name the same as the DNS name that

you'll be using to access that bucket. But at this point this is just an

introductory demo so we can leave this as just a standard name. So use Koala

campaign with some random numbers at the end and that should be good. Now when

you're creating a bucket you need to specify a region and this is the region

that this bucket will be placed in. Now I'm going to use US-East-1

as a default throughout this course and so I do recommend that you pick that to

create the bucket in. Now if you have any existing buckets within your account and

you want to copy the settings from those buckets and this will of course just

save you some time when setting up the bucket then you can click on choose

bucket and copy the settings from another bucket in your account. Now

because we're starting this from fresh and we don't have any existing buckets we

can't use this option. So we need to scroll down and just review what options

we have. For now we're going to skip past object ownership because this is a

feature that I'll be discussing in much more detail later in the course. I can't

really explain this until you have some experience of how the permissions model

works with S3 so I'll be talking about it in the S3 section of the course. Now

the first thing that you need to pick when you're creating buckets is this

bucket settings for block public access. So all S3 buckets by default are

private. Nobody has permissions to this bucket apart from the account that

creates the bucket. So in this particular case we're creating it inside the

general AWS account and so only the general AWS account and the account root

user of that account have permissions. Now because we've granted the IAM admin

user full admin permissions then it too has access to this bucket but by default

nothing else can have access. Now you can make a bucket completely public. You can

grant access for all users to that bucket including unauthenticated or

anonymous users. Now that's a security risk because potentially you might have

sensitive data within that bucket. This is a fail-safe. This means that even if

you grant completely public access to a bucket then this will block that access.

And I'm going to be talking about this in much more detail later in the course

But you need to know that this exists if we untick this option for example

Even though we are now not blocking all public access

You still need to grant access to this bucket

So all this option does is prevent you granting public access if you disable it

It does not mean that the bucket is public. It just means that you can grant public access to this bucket

So for this demonstration, we're going to go ahead and untick this option

Now if you do untick this you'll need to scroll down and check this box just to acknowledge that you understand

Exactly what you're doing

So this is a safety feature of s3 that if you're going to remove this fail-safe check then you need to accept responsibility

It means that if you do mistakenly grant public access to the bucket then potentially information can be exposed.

Now I'm not going to explain any of these other options because I cover all of them in the S3 section of the course.

So I'm going to skip past bucket versioning and tags,

default encryption, and I'm not going to be covering any of these advanced settings.

Instead, let's just go ahead and click on create bucket.

At this point you might get an error that a bucket with the same name already exists, and that's fine.

Remember S3 bucket names need to be globally unique

And there's obviously a lot of koala campaigns happening in the wild. If you do get the error

Then just feel free to add extra digits of random to the bucket name

Then scroll all the way down to the bottom and create the bucket. Once the bucket's created

You'll see it in the list of buckets

So there's a column for the name a column for the region

So you'll be able to see which region this bucket is in

It will give you an overview of the access that this bucket has so because we unchecked the block public access

Then it informs us that objects can be public again

Just to stress this does not mean they are public because s3 buckets are private by default

This is just telling us that they can be public

Lastly, we also have the creation date which tells us when the bucket was created.

So now let's just go ahead and click on the bucket to move inside so we can see additional information.

Now one thing that I do want to draw your attention to is the Amazon resource name or ARN for this bucket.

All resources in AWS have a unique identifier, the ARN or Amazon resource name.

So this is the ARN for the bucket that we've just created

ARNs have a consistent format. They start with ARN for Amazon resource name

Then they have the partition for most

AWS resources in most regions this will always say AWS

Then you have the service name in this case S3

Then you have some other values which I'll be talking about later in the course and you can omit those with certain

services by just putting double colons. These for example might be the region or the account number.

Now for services where resources are not globally unique

then obviously you need to specify the region and the account number in order for this name to be globally unique.

But because S3 buckets by default have to be globally unique

then we don't have to specify in the ARN either

the region or the account number. As long as we have the S3 service and the bucket name, we know that this uniquely

references a resource and that's the key thing about ARNs. ARNs

uniquely reference one resource within

AWS. You always know if you have one ARN that it references one particular resource within AWS.

Now you can use wildcards to reference multiple resources,

but as a basis it has to reference at least one.

Now let's just click on the objects tab here

and this will give us an overview of all of the objects

which are in this bucket.

You have a number of tabs here that you can step through.

We've got a properties tab where you can enable

bucket versioning, tags, encryption, logging,

CloudTrail data events, event notifications,

transfer acceleration, object lock, request to pays,

and static website hosting.

and we'll be talking about all of those features in detail

within the S3 section of the course.

We'll also be covering permissions in that section

because you can be very granular

with the permissions of S3 buckets.

You can see some metrics about the bucket.

So this uses CloudWatch,

which we'll be talking about in detail

elsewhere in the course.

You're also able to access management functionality.

Again, we'll be talking about all of this

later in the course.

And then finally you're able to create access points.

Now access points are some advanced functionality and so we'll be covering this later in the course.

For now I just want you to get some experience of uploading some objects and interacting with them.

Now there's a link attached to this lesson which you'll need to go ahead and click and that will download a zip file.

Go ahead and extract that zip file and it will create a folder.

And then once you've extracted that into a folder we're good to continue.

Now the easiest way at this point to upload some objects is to make sure that you've got the objects tab selected

and then click on upload.

Now you're able to upload both files and folders to this S3 bucket.

So let's start off by uploading some files.

So click on add files.

Now at this point locate and go inside the folder that you extracted a few moments ago

and you'll see that there are three image files.

We've got koala_nom1.jpg, koala_nom2.jpg and koala_zzz.jpg

Now go ahead and select all three of these JPEG files and click on open.

You'll see that you have three files in total queued for upload

and you'll be provided with an estimate of the amount of space that these files will consume.

Now scrolling down you're told the destination where you'll be uploading these objects to

So this is the S3 bucket that we've created and this will be different for you.

This will be your bucket name.

Now we haven't enabled versioning on this bucket.

This is a feature which I'll be covering in the S3 section of the course, but

because we don't have versioning enabled, it means that if we do upload files with

the same name, then potentially we're going to overwrite other objects in that bucket.

So we have to accept the risk because we don't have versioning enabled.

We could overwrite objects if we re-upload ones with the same name.

In this case that's fine because we're not uploading anything important

and regardless this bucket is empty so we can't overwrite anything.

You have the option of enabling versioning where you can just acknowledge the risk.

Then we can scroll down further still. We need to pick the storage class for the objects.

This defaults to standard and I haven't covered storage classes in the course yet.

I'll be doing that within the S3 section, so we're going to accept the default

and then we're going to skip past all of these options.

I'll be covering these later in the course and just go ahead and click on Upload.

And this will upload all of those three objects to the S3 bucket.

You'll be told whether the upload has been successful or whether it's failed.

In our case, it's succeeded.

So we can go ahead and click on Close to close down this dialogue.

Now when we scroll down, we'll see an overview of the objects within this bucket.

In our case we only have the three, Koala Nom1, Koala Nom2 and KoalaZZZ.jpg

We can also create folders within S3. Now of course because S3 is a flat structure

This isn't actually creating a folder. It's just creating a file which emulates a folder

So if we create a folder and let's call this folder archive and then click on create folder

It's not actually creating a folder called archive what it's doing is creating an object with this name

so archive forward slash

Now if we click on this archive folder and go inside it we can upload objects into this folder

So let's go ahead and do that click on upload

Go to add files and then just pick one of these files. Let's go with koala

zz.jpg so select that one and click on open and just click on upload. Now what

we've done is we've uploaded an object into what we see as a folder in this s3

bucket. If we click on close what this has actually done is it's created an

object which is called archive/koalazz.jpg. S3 doesn't really have

folders. Folders are emulated using prefixes and that's important to know as

you move through the course. Now if we click this at the top to go back to the

main bucket and we're going to go ahead and open one of these objects. So let's

pick one of these objects let's use koala_nom1.jpg. This opens an overview

screen for this particular object and where we see this object URL just go

ahead and right-click and open that in a new tab. When you open that in a new tab

you'll be presented with an access denied error. The reason for that is

you're trying to access this object with no authentication. You're accessing the

object as an unauthenticated user and as I mentioned earlier all S3 objects and

all S3 buckets are private by default and that's why you get this access

denied you won't be able to access this object without authenticating to AWS and

using that identity to access an object. That's of course unless you grant public

access to this object which we haven't done and we won't be doing in this

lesson. So if we close down that tab and instead click on open you might have to

bypass a pop-up blocker but this time it will open this object and that's because

we're including authentication in the URL at the top here. So when you click on

the open button it's opening the object as you it's not opening it as an

unauthenticated identity so that's important because you have access to

this bucket you can open the objects using this open button. The same is true

for the other objects so if we go back to the bucket let's pick koala nom2

Then click on the open button and again we'll see a koala having some food.

Go back to the bucket and then let's try koala ZZZ.

So click on the object, click on open again and now we can see a koala having a well deserved

rest after his lunch.

Now that's everything I wanted to cover in this demo lesson.

It's just been a really high level introduction into how to interact with S3 using the console

UI.

be covering S3 in detail later in the course, I just wanted this demo lesson to

be a very brief introduction. Now what we need to do before we finish this demo

lesson is to go back to the main S3 console and we need to tidy up by

deleting this bucket. So deleting buckets within S3 is a two-step process. First we

need to empty the bucket. So go ahead and select the bucket and click on empty.

You'll need to either type or copy and paste permanently delete into the box

and then click on empty and that will remove any objects within the bucket.

Assuming that's successful go ahead and click on exit and with the bucket still

selected click on delete and then once you've clicked on delete you'll need to

copy and paste or type the name of the bucket and finally click on delete

bucket to confirm that deletion process and that will delete the bucket and your

account will be back in the same state as it was at the start of this demo

lesson. Now at this point I hope this has been useful it's just been a really

basic introduction to S3 and don't worry you'll be getting plenty more theory and

practical exposure to the product in the S3 section of the course. For now just go

ahead and complete this video and when you're ready I look forward to you

joining me in the next.

Welcome back. In this lesson, I want to introduce another core AWS service, the simple storage service known as S3. If you use AWS in production, you need to understand S3. This lesson will give you the very basics because I'll be deep diving into a specific S3 section later in the course, and the product will feature constantly as we go. Pretty much every other AWS service has some kind of interaction with S3. So let's jump in and get started.

S3 is a global storage platform. It's global because it runs from all of the AWS regions and can be accessed from anywhere with an internet connection. It's a public service. It's regional based because your data is stored in a specific AWS region at rest. So when it's not being used, it's stored in a specific region. And it never leaves that region unless you explicitly configure it to. S3 is regionally resilient, meaning the data is replicated across availability zones in that region. S3 can tolerate the failure of an AZ, and it also has some ability to replicate data between regions, but more on that in the S3 section of the course.

Now S3 might initially appear confusing. If you utilize it from the UI, you appear not to have to select a region. Instead, you select the region when you create things inside S3, which I'll talk about soon. S3 is a public service, so it can be accessed from anywhere as long as you have an internet connection. The service itself runs from the AWS public zone. It can cope with unlimited data amounts and it's designed for multi-user usage of that data. So millions of users could be accessing cute cat pictures added by the Animals for Life Rescue Officers. S3 is perfect for hosting large amounts of data. So think movies or audio distribution, large scale photo storage like stock images, large textual data or big data sets. It could be just as easily used for millions or billions of IOT devices or to store images for a blog. It scales from nothing to near unlimited levels.

Now S3 is economical, it's a great value service for storing and allowing access to data. And it can be accessed using a variety of methods. There's the GUI, you can use the command line, the AWS APIs or even standard methods such as HTTP. I want you to think of S3 as the default storage service in AWS. It should be your default starting point unless your requirement isn't delivered by S3. And I'll talk more about the limitations and use cases later in this lesson.

S3 has two main things that it delivers: Objects and Buckets. Objects are the data the S3 stores, your cat picture, the latest episode of Game of Thrones, which you have stored legally, of course, or it could be large scale datasets showing the migration of the koala population in Australia after a major bushfire. Buckets are containers for objects. It's buckets and objects that I want to cover in this lesson as an introduction to the service.

So first, let's talk about objects. An object in S3 is made up of two main components and some associated metadata. First, there is the object key. And for now you can think of the object key, similar to a file name. The key identifies the object in a bucket. So if you know the object key and the bucket, then you can uniquely access the object, assuming that you have permissions. Remember by default, even for public services, there is no access in AWS initially, except for the account root user.

Now, the other main component of an object is its value. And the value is the data or the contents of the object. In this case, a sequence of binary data, which represents a koala in his house. In this course, I want to avoid suggesting that you remember pointless values. Sometimes though, there are things that you do need to commit to memory. And this is one of those times. The value of an object, in essence, how large the object is, can range from zero bytes up to five terabytes in size. So you can have an empty object or you can have one that is a huge five TB. This is one of the reasons why S3 is so scalable and so useful in a wide range of situations because of this range of sizes for objects.

Now, the other components of an object, aren't that important to know at this stage, but just so you hear the terms that I'll use later, objects also have a version ID, metadata, some access control, as well as sub resources. Now don't worry about what they do for now, I'll be covering them all later. For this lesson, just try to commit to memory what an object is, what components it has and the size range for an object.

So now that we've talked about objects, let's move on and look at buckets. Buckets are created in a specific AWS region. And let's use Sydney or ap-southeast-2 as an example. This has two main impacts. Firstly, your data that's inside a bucket has a primary home region. And it never leaves that region, unless you as an architect or one of your system admins configures that data to leave that region. That means that S3 has stable and controlled data sovereignty. By creating a bucket in a region, you can control what laws and rules apply to that data. What it also means is that the blast radius of a failure is that region.

Now this might be a new term. What I mean by blast radius is that if a major failure occurs, say a natural disaster or a large scale data corruption, the effect of that will be contained within the region. Now a bucket is identified by its name, the bucket name in this case, koala data. A bucket name needs to be globally unique. So that's across all regions and all accounts of AWS. If I pick a bucket name, in this case, koala data, nobody else can use it in any AWS account. Now making a point of stressing this as it often comes up in the exam. Most AWS things are often unique in a region or unique in your account. For example, I can have an IAM user called Fred and you can also have an IAM user called Fred. Buckets though are different, with buckets, the name has to be totally unique, and that's across all regions and all AWS accounts. I've seen it come up in the exam a few times. So this is definitely a point to remember.

Now buckets can hold an unlimited number of objects. And because objects can range from zero to five TB in size, that essentially means that a bucket can hold from zero to unlimited bytes of data. It's an infinitely scalable storage system. Now one of the most important things that I want to say in this lesson is that as an object storage system, an S3 bucket has no complex structure. It's flat, it has flat structure. All objects stored within the bucket at the same level. So this isn't like a file system where you can truly have files within folders, within folders. Everything is stored in the bucket at the root level.

But, if you do a listing on an S3 bucket, you will see what you think are folders. Even the UI presents this as folders. But it is important for you to know at this stage that that's not how it actually is. Imagine a bucket where you see three image files, koala one, two and three dot JPEG. The first thing is that inside S3, there's no concept of file type based on the name. These are just three objects where the object key is koala1.JPEG, koala2.JPEG and koala3.JPEG. Now folders in S3 are represented when we have object names that are structured like these. So the objects have a key, a forward slash old forward slash koala one, two and three dot JPEG. When we create object names like this, then S3 presents them in the UI as a folder called old. So because we've got object names that begin with slash old, then S3 presents this as a folder called old. And then inside that folder, we've got koala one, two, and three dot JPEG.

Now nine out of 10 times, this detail doesn't matter, but I want to make sure that you understand how it actually works. Folders are often referred to as prefixes in S3 because they're part of the object names. They prefix the object names. As you move through the various stages of your AWS learnings, this is gonna make more and more sense. And I'm gonna demonstrate this in the next lesson, which is a demo lesson.

Now to summarize buckets are just containers, they're stored in a region, and for S3, they're generally where a lot of permissions and options are set. So remember that buckets are generally the default place where you should go to, to configure the way the S3 works.

Now, I want to cover a few summary items and then step through some patterns and anti-patterns for S3, before we move to the demo. But first an exam powerup. These are things that you should try to remember and they will really help in the exam. First bucket names are globally unique. Remember that one because it will really help in the exam. I've seen a lot of times where AWS have included trick questions, which test your knowledge of this one. If you get any errors, you can't create a bucket a lot of the time it's because somebody else already has that bucket name.

Now bucket names do have some restrictions. They need to be between three and 63 characters, all lower case and no underscores. They have to start with a lowercase letter or a number, and they can't be formatted like IP addresses. So you can't have one.one.one.one as your bucket name. Now there are some limits in terms of buckets. Now limits are often things that you don't need to remember for the exam, but this is one of the things that you do. There is a limit of a hundred buckets that you can have in an AWS account. So this is not per region, it's for the entire account. There's a soft limit of 100 and a hard limit so you can increase all the way up to this hard limit using support requests, and this hard limit is a thousand.

Now this matters for architectural reasons. It's not just an arbitrary number. If you're designing a system which uses S3 and users of that system store data inside S3, you can implement a solution that has one bucket per user if you have anywhere near this number of users. So if you have anywhere from a hundred to a thousand users or more of a system, then you're not gonna be able to have one bucket per user because you'll hit this hard limit. You tend to find this in the exam quite often, it'll ask you how to structure a system, which has potentially thousands of users. What you can do is take a single bucket and divide it up using prefixes, so those folders that aren't really folders, and then in that way, you can have multiple users using one bucket. Remember the 100/1000, it's a 100 soft limit and a 1000 hard limit.

You aren't limited in terms of objects in a bucket, you can have zero to an infinite number of objects in a bucket. And each object can range in size from zero bytes to five TB in size. And then finally, in terms of the object structure, an object consists of a key, which is its name and then the value, which is the data. And there are other elements to an object which I'll discuss later in the course, but for now, just remember the two main components, the key and the value. Now, all of these points are worth noting down, maybe make them into a set of flashcards and you can use them later on during your studies.

S3 is pretty straightforward and that there tend to be a number of things that it's really good at and a fairly small set of things that it's not suitable for. So let's take a look. S3 is an object storage system. It's not a file storage system, and it's not a block storage system, which are the other main types. What this means is that if you have a requirement where you're accessing the whole of these entities, so the whole of an object, so an image, an audio file, and you're doing all of that at once, then it's a candidate for object storage. If you have a Window server which needs to access a network file system, then it's not S3 that needs to be file-based storage. S3 has no file system, it's flat. So you can't browse to an S3 bucket like you would a file share in Windows. Likewise, it's not block storage, which means you can't mount it as a mount point or a volume on the Linux or Windows. When you're dealing with virtual machines or instances, you mount block storage to them. Block storage is basically virtual hard disks. In EC2, you have EBS, which is block storage. Block storage is generally limited to one thing accessing it at a time, one instance in the case of EBS. S3 doesn't have that single user limitation and it's not block storage, but that means you can't mount it as a drive.

S3 is great for large scale data storage or distribution. Many examples I'll show you throughout the course will fit into that category. And it's also good for offloading things. If you have a blog with lots of posts and lots of images or audio or movies, instead of storing that data on an expensive compute instance, you can move it to an S3 bucket and configure your blog software to point your users at S3 directly. You can often shrink your instance by offloading data onto S3. And don't worry, I'll be demoing this later in the course. Finally, S3 should be your default thought for any input to AWS services or output from AWS services. Most services which consume data and or output data can have S3 as an option to take data from or put data to when it's finished. So if you're faced with any exam questions and there's a number of options on where to store data, S3 should be your default. There are plenty of AWS services which can output large quantities of data or ingest large quantities of data. And most of the time, it's S3, which is an ideal storage platform for that service.

Okay time for a quick demo. And in this demo, we're just gonna run through the process of creating a simple S3 bucket, uploading some objects to that bucket, and demonstrating exactly how the folder functionality works inside S3. And I'm also gonna demonstrate a number of elements of how access and permissions work with S3. So go ahead and complete this video, and when you're ready join me in the next, which is gonna be a demo of S3.

Welcome back, this is part two of this lesson where we continue immediately from the end of part one. In my case, it took about three minutes for the status check to change to "two out of two checks passed," indicating we're good to continue. AWS runs several checks on an EC2 instance as the final stage of the provisioning process, so ensure an instance has passed these checks before proceeding. You can see the instance has been provisioned into US-East-1C, with its own public IP version 4 address and public IP version 4 DNS name for internet access. Additional details such as the security group name, key name, and launch time are also available. Clicking on the instance reveals more detailed information in the bottom pane across various tabs like Details, Security, Networking, Storage, Status Checks, and Monitoring. To connect to the terminal of this EC2 instance, right-click the instance, select "connect," and choose one of the connection methods. EC2 Instance Connect allows access via a web browser. For this lesson, we focus on connecting using a local SSH client. Ensure you have the local SSH client and the A4L.PEM key file downloaded earlier. In your terminal, navigate to the folder containing the key file and adjust the file's permissions using the chmod 400 command. If on Windows, follow the detailed steps linked in the lesson to correct permissions. After setting permissions, use the provided SSH connection command to connect to the EC2 instance. This command uses the key pair to authenticate your connection. AWS stores the public part of the key pair on the EC2 instance, while you have the private part, allowing secure access. Throughout the course, we will use various methods to connect to EC2 instances, including local SSH clients, Instance Connect, and Session Manager. For Windows EC2 instances, we'll use Remote Desktop, which is beyond the scope of this lesson. To finish up, terminate the instance by selecting it, right-clicking, and choosing "terminate instance." Additionally, delete the security group created for this instance by navigating to the security groups, selecting it, and deleting it once the instance is terminated. Complete these steps and then proceed to the next lesson.

Welcome to this demo lesson where you'll create your first EC2 instance as part of this course. This lesson falls under the AWS Free Tier, so assuming you're using a new account created for this course, there won't be any charges. Ensure you're logged into the general AWS account and have the Northern Virginia region (US-East-1) selected. Once there, navigate to the EC2 console by typing "EC2" in the search box, finding the EC2 service, and clicking to access the console. At the dashboard, the first step is to create an SSH key pair, essential for accessing the EC2 instance. If you don’t already have one, scroll down the left menu, click on Keypairs under Network and Security, and create a key pair. Remember, you'll only have one opportunity to download your part of the key pair, so keep it safe. Name it "A4L" (Animals for Life), choose the key pair type and private key file format based on your operating system (PEM for Mac OS/Linux or modern Windows, PPK for older Windows/using PuTTY), and save it to your default download location.

Next, return to the dashboard to begin creating your EC2 instance. Click on "Instances" to see all launched instances (you shouldn't have any yet), then click "Launch Instances" to go to the launch instance console. Name the instance "my first EC2 instance" and select the Amazon Machine Image (AMI) for the operating system—use Amazon Linux 2023 for this demo, as it’s free tier eligible. Leave all defaults and choose the instance type, ensuring it’s a free tier eligible type like t2.micro. Select the SSH key pair "A4L" you created earlier.

Configure network settings by selecting the default VPC and ensure the option to auto-assign a public IP is enabled for internet access. Create a new Security Group named "my_first_instance_sg" to allow SSH from anywhere, understanding you'll need the key pair for access. Configure storage, leaving the default 8GIB GP3 root volume, and expand advanced details if necessary for later use. Launch the EC2 instance and wait for the creation process, which may take a few moments. Refresh to see the instance status change from pending to running, and wait for the status check to complete. This concludes part one of the lesson. Take a break and join part two to continue from here.

Welcome back. In this lesson, we will introduce an essential AWS service, the Elastic Compute Cloud (EC2). EC2 is a critical service you need to understand for the AWS exam and for designing real-world AWS solutions, as it is the default compute service within AWS. EC2 provides access to virtual machines known as instances. When deploying compute resources that require an operating system, runtime environment, database dependencies, applications, and application interfaces, EC2 is the service to use. It should be the starting point for any compute requirement in AWS.

Let's review some important features of EC2 before discussing architectural points. EC2 is an Infrastructure as a Service (IaaS), providing access to virtual machines called EC2 instances. As an IaaS, the unit of consumption is the instance, which is an operating system configured with allocated resources. EC2 is a private AWS service, meaning it runs in the private AWS zone by default. An EC2 instance is configured to launch into a single VPC subnet, set during instance launch, and requires configuration for public access if needed.

With the default VPC, public access configuration is handled automatically. For custom VPCs, you need to manage this configuration. An EC2 instance's availability zone (AZ) resilience means that if the AZ fails, the instance will likely fail too. Understanding this is crucial for the course and the exam. When launching an instance, you can choose from various sizes and capabilities, influencing the resources and additional features like GPUs, advanced storage, or networking. Some configurations can be changed post-launch.

As a consumer of EC2, you manage the operating system and upward in the infrastructure stack, while AWS handles virtualization, physical hardware, networking, storage, and facilities. EC2 offers on-demand billing, either by the second or hour, depending on the instance's software, charging only for consumed resources. Instance charges include CPU and memory consumption, storage usage, and extras for any commercial software.

EC2 instances can use different storage types, including local host storage and Elastic Block Store (EBS), a network storage service. An EC2 instance's state, such as running, stopped, or terminated, indicates its condition. Running instances consume resources and generate charges, while stopped instances do not incur CPU, memory, or networking costs but still generate storage charges. Terminated instances stop all resource usage and delete allocated storage, making this action irreversible.

An Amazon Machine Image (AMI) is an image of an EC2 instance used to create or derived from an instance. AMIs contain attached permissions, determining which accounts can use them. They can be public, owner-accessible, or explicitly shared with specific AWS accounts. AMIs include the boot volume and a block device mapping, linking volumes to the device IDs expected by the operating system.

In the next lesson, we will connect to EC2 instances. Windows instances use the Remote Desktop Protocol (RDP) on port 3389, while Linux instances use the SSH protocol on port 22, authenticated with an SSH key pair. When creating an EC2 instance, you select a key pair, download the private key, and AWS retains the public key. For Windows instances, the private key retrieves the local administrator password for RDP access. For Linux instances, the private and public key match enables SSH connection.

Next, we will demonstrate creating an EC2 instance in the default VPC, assigning a public IPv4 address, and connecting using the discussed methods. Finish this video and join me in the demo lesson when ready.

Welcome back. In this lesson, I want to introduce Virtual Private Clouds known as VPCs. A VPC is the service you will use to create private networks inside AWS that other private services will run from. VPCs are also the service which is used to connect your AWS private networks to your on-premises networks when creating a hybrid environment, or it's the service which lets you connect to other cloud platforms when you're creating a multi-cloud deployment. You will encounter numerous networking and VPC-related questions in the exam, so understanding this service is crucial. This lesson provides a basic introduction, and detailed information will follow later in the course.

Let's begin with key points. A VPC is a virtual network within AWS, created within an AWS account and a specific region. VPCs are regional services, meaning they are resilient within a region and operate across multiple availability zones. By default, a VPC is private and isolated, allowing communication only within the same VPC unless configured otherwise. There are two types of VPCs: default VPCs and custom VPCs. Each region can have one default VPC, which AWS creates automatically, and you can have multiple custom VPCs. Custom VPCs require detailed configuration and are entirely private by default.

Custom VPCs are used in most serious AWS deployments because of their flexibility in configuration, size, structure, and connectivity with other VPCs, cloud platforms, and on-premises networks. In contrast, default VPCs are pre-configured by AWS with limited flexibility. This lesson focuses on VPC architecture and the default VPC, while custom VPCs will be covered in depth later.

VPCs are created within an AWS account and region, such as us-east-1. A region can have multiple custom VPCs, isolated by default unless configured to allow communication. VPCs are resilient, subdivided into subnets located in different availability zones. A default VPC has a set CIDR range of 172.31.0.0/16, which is the same across all regions. Custom VPCs can have multiple CIDR ranges. A VPC's resilience comes from its subnets, each in one availability zone. If an availability zone fails, subnets in other zones continue to operate.

Key facts about the default VPC include: only one per region, can be deleted and recreated, and has a fixed CIDR range of 172.31.0.0/16. Default VPCs have a predictable structure and come with pre-configured resources like an internet gateway, a default security group, and a network ACL. By default, anything placed in the default VPC subnets is assigned a public IP version four address, making them accessible from the public zone.

To see the default VPC in action, you can use the AWS Console. In a freshly created AWS account, the default VPC will be present with its CIDR range of 172.31.0.0/16 and subnets in each availability zone of the region. The number of subnets varies by region. You can delete the default VPC and recreate it from the console without support tickets, maintaining the same static structure.

This lesson provided an overview of the default VPC and its consistent structure. Soon, the course will shift focus to custom VPCs, which are best practice for production environments. The course scenario involving the Animals for Life Organization will illustrate why the default VPC is unsuitable. For now, mark this video as complete, and join me in the next lesson when you're ready.

Welcome back. In this lesson, I'll be discussing how AWS has designed its global infrastructure. While AWS is a global cloud platform, it's actually a collection of smaller groupings of infrastructure connected by a global high-speed network. As solutions architects, we can leverage this to design resilient and highly available systems.

I'll introduce the infrastructure concepts of an AWS region, an AWS edge location, and an AWS availability zone. I'll also cover the different ways a service can be resilient: globally resilient, regionally resilient, and zone resilient. By the end of this lesson, you'll understand what all of that means. Let's get started.

At a global level, AWS has created its infrastructure platform as a collection of individual infrastructures located worldwide. The two types of deployment at this global level are AWS regions and AWS edge locations. A region in AWS doesn't directly map onto a continent or a country. It's an area selected by AWS with a full deployment of AWS infrastructure, including compute services, storage, database products, AI, analytics, and more.

AWS continuously adds regions. At the time of creating this lesson, these include Northern Virginia, Ohio, California, and Oregon in the US, Frankfurt, Ireland, London, and Paris in Europe, and Sao Paulo in South America, among others. Some countries have one region, while larger nations have multiple, depending on customer requirements and size. Regions are geographically spread, enabling solutions architects to design systems that can withstand global-level disasters.

When interacting with most AWS services, you are interacting with a specific region. For example, Amazon's Elastic Compute Cloud in Northern Virginia is separate from Elastic Compute Cloud in Sydney. AWS can only deploy regions as fast as business and local planning allow, so you might not always have a region in the same town or city as your customers. Therefore, AWS also provides edge locations. Edge locations are much smaller than regions and generally only have content distribution services and some types of edge computing. They are located in many more places than regions, useful for companies like Netflix that need to store content close to their customers for low latency and high-speed distribution.

Regions and edge locations are commonly used together. A large company like Netflix might run its infrastructure from multiple regions worldwide, but its content could be stored in many edge locations for faster delivery. For example, in Australia, there is an AWS region in Sydney. If a Netflix customer in Melbourne wants to stream a show, it could be streamed from an edge location in Melbourne, providing faster transfer and lower latency.

AWS has a site to visualize the global AWS network, showing far fewer regions than edge locations, all connected by high-speed networking links. As we go through the course, I'll teach you how to use this private AWS networking for efficient systems deployment in AWS.

Regions are presented within the AWS Console. For instance, in the EC2 area of the console, you must select a region. However, global services like IAM or Route 53 don't require region selection. Some services are individual deployments in each region, while others operate globally.

Regions have three main benefits for solutions architects. Firstly, each region is geographically separate, meaning that a problem in one region wouldn't affect others. This isolation provides fault tolerance and stability. Secondly, selecting a region provides geopolitical or governance separation, meaning your infrastructure is subject to the laws and regulations of the region it’s in. AWS commits that data placed in one region won't leave that region unless configured otherwise. Lastly, regions allow location control, enabling you to tune your architecture for performance by placing infrastructure close to your customers.

Inside regions are availability zones (AZs), which are isolated infrastructure components within a region. Each region has multiple AZs, which can be two, three, four, five, or even six. In Sydney, there are three: ap-southeast-2a, 2b, and 2c. AZs are isolated compute, storage, networking, power, and facilities within a region. If an AZ fails, services in other AZs within the region remain functional. Solutions architects can design systems to distribute components across multiple AZs for resilience.

An availability zone could be one data center or part of multiple data centers, and AWS does not provide visibility into what constitutes an AZ. Services can be placed across multiple AZs to make them resilient.

Finally, let's define the resilience of an AWS service. There are three resilience levels: globally resilient, regionally resilient, and AZ resilient. Globally resilient services operate worldwide with a single database, replicating data across multiple regions. Examples include IAM and Route 53. Regionally resilient services operate in a single region with data replicated across multiple AZs in that region, such as RDS databases. AZ resilient services run from a single AZ, and if that AZ fails, the service fails.

As solutions architects, understanding the resilience level of each AWS service is crucial. This knowledge will help you answer exam questions and become an effective solutions architect.

These concepts are simple but fundamental. Ensure you understand what a region, edge location, and AZ are, and how services are globally, regionally, or AZ resilient. If needed, rewatch this video. When you're ready, I'll see you in the next lesson.

Welcome back. In this lesson, I want to cover the architecture of public AWS services and private AWS services. This is foundational to how AWS works, from a networking and security perspective. The differences might seem tiny, but understanding them fully will help you grasp more complex network and security products or architectures throughout your studies.

AWS services can be categorized into two main types: public services and private services. If you don’t have much AWS experience, you might assume that a public service is accessible to everyone, and a private service isn't. However, when you hear the terms AWS private service and AWS public service, it’s referring to networking only. A public service is accessed using public endpoints, such as S3, which can be accessed from anywhere with an internet connection. A private AWS service runs within a VPC, so only things within that VPC, or connected to that VPC, can access the service. For both, there are permissions as well as networking. Even though S3 is a public service, by default, an identity other than the account root user has no authorization to access that resource. So, permissions and networking are two different considerations when talking about access to a service. For this lesson, it's the networking which matters.

When thinking about any sort of public cloud environment, most people instinctively think of two parts: the internet and private network. The internet is where internet-based services operate, like online stores, Gmail, and online games. If you're at home playing an online game or watching training videos, you’re connecting to the internet via an internet service provider. So this is the internet zone. Then we have the private network. If you’re watching this video from home, your home network is an example of a private network. Only things directly connected to a network port within your house or people with your WiFi password can operate in your personal, private network zone.

AWS also has private zones called Virtual Private Clouds (VPCs). These are isolated, so VPCs can't communicate with each other unless you allow it, and nothing from the internet can reach these private networks unless you configure it. Services like EC2 instances can be placed into these private zones and, just like with your home network, it can only access the internet, and the internet can only access it if you allow and configure it.

Many people think AWS is architected with just two network zones: the internet and private zones. But there's actually a third zone: the AWS public zone, which runs between the public internet and the AWS private zone networks. This is not on the public internet but connected to it. The distinction might seem irrelevant, but it matters as you learn more about advanced AWS networking. The AWS public zone is where AWS public services operate, like S3.

To summarize, there are three different network zones: the public internet, the AWS private zone (where VPCs run), and the AWS public zone (where AWS public services operate). If you access AWS public services from anywhere with a public internet connection, your communication uses the public internet for transit to and from this AWS public zone. This is why you can access AWS public services from anywhere with an internet connection because the internet is used to carry packets from you to the AWS public zone and back again.

Later in the course, I will cover how you can configure virtual or physical connections between on-premises networks and AWS VPCs, allowing private networks to connect together if you allow it. You can also create and attach an internet gateway to a VPC, allowing private-zone resources to access the public internet if they have a public IP address. This also allows access to public AWS services like S3 without touching the public internet, communicating through the AWS public zone.

Private resources, such as EC2 instances, can be given a public IP address, allowing them to be accessed from the public internet. Architecturally, this projects the EC2 instance into the public zone, enabling communication with the public internet. Understanding the three different network zones—the public internet, the AWS public zone, and the AWS private zone—is crucial for doing well in the real world and in specific exams. These three network zones become critical as you learn more advanced networking features of AWS.

That’s everything for this lesson. Complete the video, and when you’re ready, I’ll look forward to you joining me in the next lesson.

GraphViz Solve failed to execute PosixPath('dot')